Einführung in Webdienste

In diesem Leitfaden wird veranschaulicht, wie Verschiedene Webdiensttechnologien verwendet werden. Zu den behandelten Themen gehört die Kommunikation mit REST-Diensten, SOAP-Diensten und Windows Communication Foundation-Diensten.

Um ordnungsgemäß zu funktionieren, sind viele mobile Anwendungen von der Cloud abhängig, sodass die Integration von Webdiensten in mobile Anwendungen ein gängiges Szenario ist. Die Xamarin-Plattform unterstützt die Nutzung verschiedener Webdiensttechnologien und umfasst integrierte und Drittanbieterunterstützung für die Nutzung von RESTful-, ASMX- und Windows Communication Foundation-Diensten (WCF).

Für Kunden, die Xamarin.Forms verwenden, finden Sie in der Dokumentation zu Xamarin.Forms-Webdiensten vollständige Beispiele für die Verwendung jeder dieser Technologien.

Wichtig

In iOS 9 erzwingt App Transport Security (ATS) sichere Verbindungen zwischen Internetressourcen (z. B. dem Back-End-Server der App) und der App, wodurch die versehentliche Offenlegung vertraulicher Informationen verhindert wird. Da ATS in Apps, die für iOS 9 erstellt wurden, standardmäßig aktiviert ist, unterliegen alle Verbindungen den ATS-Sicherheitsanforderungen. Wenn Verbindungen diese Anforderungen nicht erfüllen, schlagen sie mit einer Ausnahme fehl.

Sie können ATS deaktivieren, wenn es nicht möglich ist, das Protokoll und die HTTPS sichere Kommunikation für Internetressourcen zu verwenden. Dies kann durch Aktualisieren der Datei Info.plist der App erreicht werden. Weitere Informationen finden Sie unter App Transport Security.

REST

Representational State Transfer (REST) ist ein Architekturstil zum Erstellen von Webdiensten. REST-Anforderungen werden über HTTP mit den gleichen HTTP-Verben ausgeführt, die Webbrowser verwenden, um Webseiten abzurufen und Daten an Server zu senden. Es gibt folgende Verben:

  • GET: Dieser Vorgang wird verwendet, um Daten aus dem Webdienst abzurufen.
  • POST: Dieser Vorgang wird verwendet, um ein neues Datenelement im Webdienst zu erstellen.
  • PUT: Dieser Vorgang wird verwendet, um ein Datenelement im Webdienst zu aktualisieren.
  • PATCH: Dieser Vorgang wird verwendet, um ein Datenelement im Webdienst zu aktualisieren, indem eine Reihe von Anweisungen zur Änderung des Elements beschrieben wird. Dieses Verb wird in der Beispielanwendung nicht verwendet.
  • DELETE: Dieser Vorgang wird verwendet, um ein Datenelement im Webdienst zu löschen.

Webdienst-APIs, die dem REST-Standard entsprechen, werden als RESTful-APIs bezeichnet und wie folgt definiert:

  • Ein Basis-URI.
  • HTTP-Methoden wie GET, POST, PUT, PATCH oder DELETE.
  • Ein Medientyp für die Daten, z. B. JavaScript Object Notation (JSON).

Die Einfachheit von REST hat dazu beigetragen, dass es die primäre Methode für den Zugriff auf Webdienste in mobilen Anwendungen ist.

Verbrauch von REST-Diensten

Es gibt eine Reihe von Bibliotheken und Klassen, die zum Nutzen von REST-Diensten verwendet werden können, und in den folgenden Unterabschnitten werden diese behandelt. Weitere Informationen zum Verwenden eines REST-Diensts finden Sie unter Verwenden eines RESTful-Webdiensts.

HttpClient

Die Microsoft HTTP-Clientbibliotheken stellen die HttpClient -Klasse bereit, die zum Senden und Empfangen von Anforderungen über HTTP verwendet wird. Sie bietet Funktionen zum Senden von HTTP-Anforderungen und zum Empfangen von HTTP-Antworten von einer URI-identifizierten Ressource. Jede Anforderung wird als asynchroner Vorgang gesendet. Weitere Informationen zu asynchronen Vorgängen finden Sie unter Übersicht über den asynchronen Support.

Die HttpResponseMessage -Klasse stellt eine HTTP-Antwortnachricht dar, die vom Webdienst empfangen wird, nachdem eine HTTP-Anforderung gestellt wurde. Sie enthält Informationen zur Antwort, einschließlich des status Codes, Headern und Textkörpers. Die HttpContent -Klasse stellt die HTTP-Text- und Inhaltsheader dar, z. B Content-Type . und Content-Encoding. Der Inhalt kann mit einer der ReadAs Methoden gelesen werden, z ReadAsStringAsync . B. und ReadAsByteArrayAsync, abhängig vom Format der Daten.

Weitere Informationen zur HttpClient -Klasse finden Sie unter Erstellen des HTTPClient-Objekts.

HTTPWebRequest

Das Aufrufen von Webdiensten mit HTTPWebRequest umfasst Folgendes:

  • Das Erstellen der Anforderung instance für einen bestimmten URI.
  • Festlegen verschiedener HTTP-Eigenschaften für die Anforderung instance.
  • Ruft eine HttpWebResponse aus der Anforderung ab.
  • Auslesen von Daten aus der Antwort.

Der folgende Code ruft beispielsweise Daten aus dem Webdienst der U.S. National Library of Medicine ab:

var rxcui = "198440";
var request = HttpWebRequest.Create(string.Format(@"https://rxnav.nlm.nih.gov/REST/RxTerms/rxcui/{0}/allinfo", rxcui));
request.ContentType = "application/json";
request.Method = "GET";

using (HttpWebResponse response = request.GetResponse() as HttpWebResponse)
{
  if (response.StatusCode != HttpStatusCode.OK)
     Console.Out.WriteLine("Error fetching data. Server returned status code: {0}", response.StatusCode);
  using (StreamReader reader = new StreamReader(response.GetResponseStream()))
  {
               var content = reader.ReadToEnd();
               if(string.IsNullOrWhiteSpace(content)) {
                       Console.Out.WriteLine("Response contained empty body...");
               }
               else {
                       Console.Out.WriteLine("Response Body: \r\n {0}", content);
               }

               Assert.NotNull(content);
  }
}

Im obigen Beispiel wird ein HttpWebRequest erstellt, das als JSON formatierte Daten zurückgibt. Die Daten werden in einem HttpWebResponsezurückgegeben, von dem ein StreamReader abgerufen werden kann, um die Daten zu lesen.

RestSharp

Ein weiterer Ansatz zum Nutzen von REST-Diensten ist die Verwendung der RestSharp-Bibliothek . RestSharp kapselt HTTP-Anforderungen, einschließlich Unterstützung für das Abrufen von Ergebnissen entweder als roher Zeichenfolgeninhalt oder als deserialisiertes C#-Objekt. Der folgende Code stellt beispielsweise eine Anforderung an den U.S. National Library of Medicine-Webdienst und ruft die Ergebnisse als JSON-formatierte Zeichenfolge ab:

var request = new RestRequest(string.Format("{0}/allinfo", rxcui));
request.RequestFormat = DataFormat.Json;
var response = Client.Execute(request);
if(string.IsNullOrWhiteSpace(response.Content) || response.StatusCode != System.Net.HttpStatusCode.OK) {
       return null;
}
rxTerm = DeserializeRxTerm(response.Content);

DeserializeRxTerm ist eine Methode, die die rohe JSON-Zeichenfolge aus der RestSharp.RestResponse.Content -Eigenschaft übernimmt und sie in ein C#-Objekt konvertiert. Das Deserialisieren von Daten, die von Webdiensten zurückgegeben werden, wird weiter unten in diesem Artikel erläutert.

NSUrlConnection

Neben Klassen, die in der Mono-Basisklassenbibliothek (BCL) verfügbar sind, z HttpWebRequest. B. , und C#-Bibliotheken von Drittanbietern, z. B. RestSharp, sind auch plattformspezifische Klassen für die Nutzung von Webdiensten verfügbar. In iOS können beispielsweise die NSUrlConnection Klassen und NSMutableUrlRequest verwendet werden.

Das folgende Codebeispiel zeigt, wie Sie den U.S. National Library of Medicine-Webdienst mithilfe von iOS-Klassen aufrufen:

var rxcui = "198440";
var request = new NSMutableUrlRequest(new NSUrl(string.Format("https://rxnav.nlm.nih.gov/REST/RxTerms/rxcui/{0}/allinfo", rxcui)),
       NSUrlRequestCachePolicy.ReloadRevalidatingCacheData, 20);
request["Accept"] = "application/json";

var connectionDelegate = new RxTermNSURLConnectionDelegate();
var connection = new NSUrlConnection(request, connectionDelegate);
connection.Start();

public class RxTermNSURLConnectionDelegate : NSUrlConnectionDelegate
{
       StringBuilder _ResponseBuilder;
       public bool IsFinishedLoading { get; set; }
       public string ResponseContent { get; set; }

       public RxTermNSURLConnectionDelegate()
               : base()
       {
               _ResponseBuilder = new StringBuilder();
       }

       public override void ReceivedData(NSUrlConnection connection, NSData data)
       {
               if(data != null) {
                       _ResponseBuilder.Append(data.ToString());
               }
       }
       public override void FinishedLoading(NSUrlConnection connection)
       {
               IsFinishedLoading = true;
               ResponseContent = _ResponseBuilder.ToString();
       }
}

Im Allgemeinen sollten plattformspezifische Klassen für die Nutzung von Webdiensten auf Szenarien beschränkt sein, in denen nativer Code nach C# portiert wird. Wenn möglich, sollte der Webdienstzugriffscode portabel sein, sodass er plattformübergreifend freigegeben werden kann.

ServiceStack

Eine weitere Option zum Aufrufen von Webdiensten ist die Service Stack-Bibliothek . Der folgende Code zeigt beispielsweise, wie Sie die Service Stack-Methode IServiceClient.GetAsync verwenden, um eine Dienstanforderung ausstellen zu können:

client.GetAsync<CustomersResponse>("",
          (response) => {
               foreach(var c in response.Customers) {
                       Console.WriteLine(c.CompanyName);
               }
       },
       (response, ex) => {
               Console.WriteLine(ex.Message);
       });

Wichtig

Während Tools wie ServiceStack und RestSharp das Aufrufen und Nutzen von REST-Diensten erleichtern, ist es manchmal nicht trivial, XML oder JSON zu nutzen, die nicht den Standardmäßigen DataContract-Serialisierungskonventionen entsprechen. Rufen Sie bei Bedarf die Anforderung auf, und verarbeiten Sie die entsprechende Serialisierung explizit mithilfe der unten erläuterten ServiceStack.Text-Bibliothek.

Verwenden von RESTful-Daten

RESTful-Webdienste verwenden in der Regel JSON-Nachrichten, um Daten an den Client zurückzugeben. JSON ist ein textbasiertes Datenaustauschformat, das kompakte Nutzlasten erzeugt, was zu geringeren Bandbreitenanforderungen beim Senden von Daten führt. In diesem Abschnitt werden Mechanismen zum Verwenden von RESTful-Antworten in JSON und Plain-Old-XML (POX) untersucht.

System.JSON

Die Xamarin-Plattform wird sofort mit Unterstützung für JSON ausgeliefert. Mit einem JsonObjectkönnen Ergebnisse abgerufen werden, wie im folgenden Codebeispiel gezeigt:

var obj = JsonObject.Parse(json);
var properties = obj["rxtermsProperties"];
term.BrandName = properties["brandName"];
term.DisplayName = properties["displayName"];
term.Synonym = properties["synonym"];
term.FullName = properties["fullName"];
term.FullGenericName = properties["fullGenericName"];
term.Strength = properties["strength"];

Es ist jedoch wichtig zu beachten, dass die System.Json Tools die gesamte Daten in den Arbeitsspeicher laden.

JSON.NET

Die NewtonSoft JSON.NET-Bibliothek ist eine weit verbreitete Bibliothek zum Serialisieren und Deserialisieren von JSON-Nachrichten. Das folgende Codebeispiel zeigt, wie Sie JSON.NET verwenden, um eine JSON-Nachricht in ein C#-Objekt zu deserialisieren:

var term = new RxTerm();
var properties = JObject.Parse(json)["rxtermsProperties"];
term.BrandName = properties["brandName"].Value<string>();
term.DisplayName = properties["displayName"].Value<string>();
term.Synonym = properties["synonym"].Value<string>();;
term.FullName = properties["fullName"].Value<string>();;
term.FullGenericName = properties["fullGenericName"].Value<string>();;
term.Strength = properties["strength"].Value<string>();
term.RxCUI = properties["rxcui"].Value<string>();

ServiceStack.Text

ServiceStack.Text ist eine JSON-Serialisierungsbibliothek, die für die Arbeit mit der ServiceStack-Bibliothek entwickelt wurde. Das folgende Codebeispiel zeigt, wie JSON mit einem ServiceStack.Text.JsonObjectanalysiert wird:

var result = JsonObject.Parse(json).Object("rxtermsProperties")
       .ConvertTo(x => new RxTerm {
               BrandName = x.Get("brandName"),
               DisplayName = x.Get("displayName"),
               Synonym = x.Get("synonym"),
               FullName = x.Get("fullName"),
               FullGenericName = x.Get("fullGenericName"),
               Strength = x.Get("strength"),
               RxTermDoseForm = x.Get("rxtermsDoseForm"),
               Route = x.Get("route"),
               RxCUI = x.Get("rxcui"),
               RxNormDoseForm = x.Get("rxnormDoseForm"),
       });

System.Xml.Linq

Im Fall der Nutzung eines XML-basierten REST-Webdiensts können LINQ to XML verwendet werden, um den XML-Code zu analysieren und ein C#-Objekt inline aufzufüllen, wie im folgenden Codebeispiel veranschaulicht:

var doc = XDocument.Parse(xml);
var result = doc.Root.Descendants("rxtermsProperties")
.Select(x=> new RxTerm()
       {
               BrandName = x.Element("brandName").Value,
               DisplayName = x.Element("displayName").Value,
               Synonym = x.Element("synonym").Value,
               FullName = x.Element("fullName").Value,
               FullGenericName = x.Element("fullGenericName").Value,
               //bind more here...
               RxCUI = x.Element("rxcui").Value,
       });

ASP.NET-Webdienst (ASMX)

ASMX bietet die Möglichkeit, Webdienste zu erstellen, die Nachrichten mit dem Simple Object Access Protocol (SOAP) senden. SOAP ist ein plattformunabhängiges und sprachunabhängiges Protokoll zum Erstellen und Zugreifen auf Webdienste. Consumer eines ASMX-Diensts müssen nichts über die Plattform, das Objektmodell oder die Programmiersprache wissen, die zum Implementieren des Diensts verwendet werden. Sie müssen nur verstehen, wie SOAP-Nachrichten gesendet und empfangen werden.

Eine SOAP-Nachricht ist ein XML-Dokument, das die folgenden Elemente enthält:

  • Ein Stammelement namens Envelope , das das XML-Dokument als SOAP-Nachricht identifiziert.
  • Ein optionales Header-Element , das anwendungsspezifische Informationen wie Authentifizierungsdaten enthält. Wenn das Header-Element vorhanden ist, muss es das erste untergeordnete Element des Envelope-Elements sein.
  • Ein erforderliches Body-Element , das die SOAP-Nachricht enthält, die für den Empfänger bestimmt ist.
  • Ein optionales Fault-Element , das verwendet wird, um Fehlermeldungen anzugeben. Wenn das Fault-Element vorhanden ist, muss es sich um ein untergeordnetes Element des Body-Elements sein.

SOAP kann über viele Transportprotokolle wie HTTP, SMTP, TCP und UDP ausgeführt werden. Ein ASMX-Dienst kann jedoch nur über HTTP ausgeführt werden. Die Xamarin-Plattform unterstützt SOAP 1.1-Standardimplementierungen über HTTP, und dies schließt die Unterstützung für viele der Standardmäßigen ASMX-Dienstkonfigurationen ein.

Generieren eines Proxys

Ein Proxy muss generiert werden, um einen ASMX-Dienst zu nutzen, der es der Anwendung ermöglicht, eine Verbindung mit dem Dienst herzustellen. Der Proxy wird erstellt, indem Dienstmetadaten verwendet werden, die die Methoden und die zugehörige Dienstkonfiguration definieren. Diese Metadaten werden als WSDL-Dokument (Web Services Description Language) verfügbar gemacht, das vom Webdienst generiert wird. Der Proxy wird mithilfe von Visual Studio für Mac oder Visual Studio erstellt, um den plattformspezifischen Projekten einen Webverweis für den Webdienst hinzuzufügen.

Die Webdienst-URL kann entweder eine gehostete Remotequelle oder eine lokale Dateisystemressource sein, auf die über das file:/// Pfadpräfix zugegriffen werden kann, z. B.:

file:///Users/myUserName/projects/MyProjectName/service.wsdl

Die Webdienst-URL kann entweder eine gehostete Remotequelle oder eine lokale Dateisystemressource sein, auf die über das Dateipfadpräfix zugegriffen werden kann.

Dadurch wird der Proxy im Ordner Web- oder Dienstverweise des Projekts generiert. Da ein Proxycode generiert wird, sollte er nicht geändert werden.

Manuelles Hinzufügen eines Proxys zu einem Projekt

Wenn Sie über einen vorhandenen Proxy verfügen, der mit kompatiblen Tools generiert wurde, kann diese Ausgabe verwendet werden, wenn sie als Teil Ihres Projekts eingeschlossen wird. Verwenden Sie in Visual Studio für Mac die Menüoption Dateien hinzufügen..., um den Proxy hinzuzufügen. Darüber hinaus muss System.Web.Services.dll explizit über das Dialogfeld Verweise hinzufügen... referenziert werden.

Verwenden des Proxys

Die generierten Proxyklassen bieten Methoden zum Nutzen des Webdiensts, die das Entwurfsmuster Asynchrones Programmiermodell (APM) verwenden. In diesem Muster wird ein asynchroner Vorgang als zwei Methoden namens BeginOperationName und EndOperationName implementiert, die den asynchronen Vorgang beginnen und beenden.

Die BeginOperationName-Methode beginnt den asynchronen Vorgang und gibt ein Objekt zurück, das die IAsyncResult Schnittstelle implementiert. Nach dem Aufrufen von BeginOperationName kann eine Anwendung weiterhin Anweisungen für den aufrufenden Thread ausführen, während der asynchrone Vorgang in einem Threadpoolthread stattfindet.

Bei jedem Aufruf von BeginOperationName sollte die Anwendung auch EndOperationName aufrufen, um die Ergebnisse des Vorgangs abzurufen. Der Rückgabewert von EndOperationName ist derselbe Typ, der von der synchronen Webdienstmethode zurückgegeben wird. Das folgende Codebeispiel veranschaulicht dieses Verhalten:

public async Task<List<TodoItem>> RefreshDataAsync ()
{
  ...
  var todoItems = await Task.Factory.FromAsync<ASMXService.TodoItem[]> (
    todoService.BeginGetTodoItems,
    todoService.EndGetTodoItems,
    null,
    TaskCreationOptions.None);
  ...
}

Die Task Parallel Library (TPL) kann die Verwendung eines APM-Start-End-Methodenpaars vereinfachen, indem die asynchronen Vorgänge im selben Task Objekt gekapselt werden. Diese Kapselung wird durch mehrere Überladungen der Task.Factory.FromAsync -Methode bereitgestellt. Diese Methode erstellt eine Task , die die TodoService.EndGetTodoItems Methode nach Abschluss der TodoService.BeginGetTodoItems Methode ausführt, wobei der null Parameter angibt, dass keine Daten an den BeginGetTodoItems Delegaten übergeben werden. Schließlich gibt der Wert der TaskCreationOptions Enumeration an, dass das Standardverhalten für die Erstellung und Ausführung von Aufgaben verwendet werden soll.

Weitere Informationen zu APM finden Sie unter Asynchrones Programmiermodell und TPL und herkömmliche .NET Framework asynchrone Programmierung auf MSDN.

Weitere Informationen zum Nutzen eines ASMX-Diensts finden Sie unter Verwenden eines ASP.NET-Webdiensts (ASMX).

Windows Communication Foundation (WCF)

WCF ist das einheitliche Framework von Microsoft zum Erstellen dienstorientierter Anwendungen. Es ermöglicht Entwicklern, sichere, zuverlässige, transaktionsfähige und interoperable verteilte Anwendungen zu erstellen.

WCF beschreibt einen Dienst mit verschiedenen Verträgen, die Folgendes umfassen:

  • Datenverträge : Definieren Sie die Datenstrukturen, die die Grundlage für den Inhalt einer Nachricht bilden.
  • Nachrichtenverträge : Verfassen von Nachrichten aus vorhandenen Datenverträgen.
  • Fehlerverträge : Zulassen, dass benutzerdefinierte SOAP-Fehler angegeben werden.
  • Dienstverträge : Geben Sie die Vorgänge an, die von den Diensten unterstützt werden, und die Nachrichten, die für die Interaktion mit den einzelnen Vorgängen erforderlich sind. Sie geben auch ein beliebiges benutzerdefiniertes Fehlerverhalten an, das Vorgängen für jeden Dienst zugeordnet werden kann.

Es gibt Unterschiede zwischen ASP.NET Webdiensten (ASMX) und WCF, aber es ist wichtig zu verstehen, dass WCF die gleichen Funktionen unterstützt, die ASMX bietet – SOAP-Nachrichten über HTTP.

Wichtig

Die Xamarin-Plattformunterstützung für WCF ist auf textcodierte SOAP-Nachrichten über HTTP/HTTPS unter Verwendung der BasicHttpBinding -Klasse beschränkt. Darüber hinaus erfordert die WCF-Unterstützung die Verwendung von Tools, die nur in einer Windows-Umgebung verfügbar sind, um den Proxy zu generieren.

Generieren eines Proxys

Ein Proxy muss generiert werden, um einen WCF-Dienst zu nutzen, sodass die Anwendung eine Verbindung mit dem Dienst herstellen kann. Der Proxy wird erstellt, indem Dienstmetadaten verwendet werden, die die Methoden und die zugehörige Dienstkonfiguration definieren. Diese Metadaten werden in Form eines WSDL-Dokuments (Web Services Description Language) verfügbar gemacht, das vom Webdienst generiert wird. Der Proxy kann mithilfe des Microsoft WCF Web Service Reference-Anbieters in Visual Studio 2017 erstellt werden, um einer .NET-Standardbibliothek einen Dienstverweis für den Webdienst hinzuzufügen.

Eine Alternative zum Erstellen des Proxys mit dem Microsoft WCF Web Service Reference-Anbieter in Visual Studio 2017 ist die Verwendung des ServiceModel Metadata Utility Tools (svcutil.exe). Weitere Informationen finden Sie unter ServiceModel Metadata Utility Tool (Svcutil.exe).

Konfigurieren des Proxys

Beim Konfigurieren des generierten Proxys werden während der Initialisierung in der Regel zwei Konfigurationsargumente (abhängig von SOAP 1.1/ASMX oder WCF) verwendet: die EndpointAddress und/oder die zugeordneten Bindungsinformationen, wie im folgenden Beispiel gezeigt:

var binding = new BasicHttpBinding () {
       Name= "basicHttpBinding",
       MaxReceivedMessageSize = 67108864,
};

binding.ReaderQuotas = new System.Xml.XmlDictionaryReaderQuotas() {
       MaxArrayLength = 2147483646,
       MaxStringContentLength = 5242880,
};

var timeout = new TimeSpan(0,1,0);
binding.SendTimeout= timeout;
binding.OpenTimeout = timeout;
binding.ReceiveTimeout = timeout;

client = new Service1Client (binding, new EndpointAddress ("http://192.168.1.100/Service1.svc"));

Eine Bindung wird verwendet, um die Transport-, Codierungs- und Protokolldetails anzugeben, die für die Kommunikation von Anwendungen und Diensten untereinander erforderlich sind. Gibt BasicHttpBinding an, dass textcodierte SOAP-Nachrichten über das HTTP-Transportprotokoll gesendet werden. Wenn Sie eine Endpunktadresse angeben, kann die Anwendung eine Verbindung mit verschiedenen Instanzen des WCF-Diensts herstellen, sofern mehrere veröffentlichte Instanzen vorhanden sind.

Verwenden des Proxys

Die generierten Proxyklassen stellen Methoden zum Nutzen der Webdienste bereit, die das Entwurfsmuster Asynchrones Programmiermodell (APM) verwenden. In diesem Muster wird ein asynchroner Vorgang als zwei Methoden namens BeginOperationName und EndOperationName implementiert, die den asynchronen Vorgang beginnen und beenden.

Die BeginOperationName-Methode beginnt den asynchronen Vorgang und gibt ein Objekt zurück, das die IAsyncResult Schnittstelle implementiert. Nach dem Aufrufen von BeginOperationName kann eine Anwendung weiterhin Anweisungen für den aufrufenden Thread ausführen, während der asynchrone Vorgang in einem Threadpoolthread stattfindet.

Bei jedem Aufruf von BeginOperationName sollte die Anwendung auch EndOperationName aufrufen, um die Ergebnisse des Vorgangs abzurufen. Der Rückgabewert von EndOperationName ist derselbe Typ, der von der synchronen Webdienstmethode zurückgegeben wird. Das folgende Codebeispiel veranschaulicht dieses Verhalten:

public async Task<List<TodoItem>> RefreshDataAsync ()
{
  ...
  var todoItems = await Task.Factory.FromAsync <ObservableCollection<TodoWCFService.TodoItem>> (
    todoService.BeginGetTodoItems,
    todoService.EndGetTodoItems,
    null,
    TaskCreationOptions.None);
  ...
}

Die Task Parallel Library (TPL) kann die Verwendung eines APM-Start-End-Methodenpaars vereinfachen, indem die asynchronen Vorgänge im selben Task Objekt gekapselt werden. Diese Kapselung wird durch mehrere Überladungen der Task.Factory.FromAsync -Methode bereitgestellt. Diese Methode erstellt eine Task , die die TodoServiceClient.EndGetTodoItems Methode nach Abschluss der TodoServiceClient.BeginGetTodoItems Methode ausführt, wobei der null Parameter angibt, dass keine Daten an den BeginGetTodoItems Delegaten übergeben werden. Schließlich gibt der Wert der TaskCreationOptions Enumeration an, dass das Standardverhalten für die Erstellung und Ausführung von Aufgaben verwendet werden soll.

Weitere Informationen zu APM finden Sie unter Asynchrones Programmiermodell und TPL und herkömmliche .NET Framework asynchrone Programmierung auf MSDN.

Weitere Informationen zum Nutzen eines WCF-Diensts finden Sie unter Verwenden eines Windows Communication Foundation (WCF)-Webdiensts.

Verwenden der Transportsicherheit

WCF-Dienste können Sicherheit auf Transportebene verwenden, um vor dem Abfangen von Nachrichten zu schützen. Die Xamarin-Plattform unterstützt Bindungen, die die Sicherheit auf Transportebene mithilfe von SSL nutzen. Es kann jedoch vorkommen, dass der Stapel das Zertifikat überprüfen muss, was zu einem unerwarteten Verhalten führt. Die Überprüfung kann überschrieben werden, indem sie einen ServerCertificateValidationCallback Delegaten registrieren, bevor Sie den Dienst aufrufen, wie im folgenden Codebeispiel veranschaulicht:

System.Net.ServicePointManager.ServerCertificateValidationCallback +=
(se, cert, chain, sslerror) => { return true; };

Dadurch wird die Transportverschlüsselung beibehalten, während die serverseitige Zertifikatüberprüfung ignoriert wird. Dieser Ansatz ignoriert jedoch effektiv die Vertrauensbedenken, die mit dem Zertifikat verbunden sind, und ist möglicherweise nicht angemessen. Weitere Informationen finden Sie unter Verwenden von vertrauenswürdigen Wurzeln aufmono-project.com.

Verwenden der Sicherheit von Clientanmeldeinformationen

WCF-Dienste erfordern möglicherweise auch die Authentifizierung der Dienstclients mithilfe von Anmeldeinformationen. Die Xamarin-Plattform unterstützt das WS-Security-Protokoll nicht, sodass Clients Anmeldeinformationen innerhalb des SOAP-Nachrichtenumschlags senden können. Die Xamarin-Plattform unterstützt jedoch die Möglichkeit, Anmeldeinformationen für die HTTP-Standardauthentifizierung an den Server zu senden, indem die entsprechenden ClientCredentialTypeangegeben werden:

basicHttpBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Basic;

Anschließend können die Anmeldeinformationen für die standardauthentifizierung angegeben werden:

client.ClientCredentials.UserName.UserName = @"foo";
client.ClientCredentials.UserName.Password = @"mrsnuggles";

Weitere Informationen zur HTTP-Standardauthentifizierung finden Sie im Kontext eines REST-Webdiensts unter Authentifizieren eines RESTful-Webdiensts.