Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Überblick
In diesem Handbuch erfahren Sie, wie Sie allgemeine Szenarien mithilfe der verwalteten Clientbibliothek für Mobile Apps für Azure App Service Mobile Apps für Windows und Xamarin-Apps ausführen. Wenn Sie noch nicht mit Mobilen Apps vertraut sind, sollten Sie zunächst das Lernprogramm für Azure Mobile Apps abschließen. In diesem Leitfaden konzentrieren wir uns auf das clientseitige verwaltete SDK. Weitere Informationen zu den serverseitigen SDKs für mobile Apps finden Sie in der Dokumentation zum .NET Server SDK oder zumNode.js Server SDK.
Referenzdokumentation
Die Referenzdokumentation für das Client-SDK befindet sich hier: Azure Mobile Apps .NET-Clientreferenz. Sie finden auch mehrere Clientbeispiele im Azure-Samples GitHub-Repository.
Unterstützte Plattformen
Die .NET-Plattform unterstützt die folgenden Plattformen:
- Xamarin Android-Versionen für API 19 bis 24 (KitKat über Nougat)
- Xamarin iOS-Veröffentlichungen für iOS-Versionen 8.0 und höher
- Universelle Windows-Plattform
- Windows Phone 8.1
- Windows Phone 8.0 mit Ausnahme von Silverlight-Anwendungen
Die "Server-Flow"-Authentifizierung verwendet ein WebView für die angezeigte Benutzeroberfläche. Wenn das Gerät keine WebView-Benutzeroberfläche präsentieren kann, sind andere Authentifizierungsmethoden erforderlich. Dieses SDK eignet sich daher nicht für Watch-Type- oder ähnlich eingeschränkte Geräte.
Einrichtung und Voraussetzungen
Es wird davon ausgegangen, dass Sie Ihr Mobile App-Back-End-Projekt bereits erstellt und veröffentlicht haben, das mindestens eine Tabelle enthält. Im code, der in diesem Thema verwendet wird, wird die Tabelle benannt TodoItem und enthält die folgenden Spalten: Id, , Textund Complete. Diese Tabelle ist die gleiche Tabelle, die beim Abschließen der Azure Mobile Apps-Schnellstartanleitung erstellt wird.
Der entsprechende typierte clientseitige Typ in C# ist die folgende Klasse:
public class TodoItem
{
public string Id { get; set; }
[JsonProperty(PropertyName = "text")]
public string Text { get; set; }
[JsonProperty(PropertyName = "complete")]
public bool Complete { get; set; }
}
Die JsonPropertyAttribute- wird verwendet, um die PropertyName- Zuordnung zwischen dem Clientfeld und dem Tabellenfeld zu definieren.
Informationen zum Erstellen von Tabellen in Ihrem Mobilen Apps-Back-End finden Sie im Thema .NET Server SDK oder im ThemaNode.js Server SDK. Wenn Sie Ihr Mobile App-Back-End im Azure-Portal mithilfe der Schnellstartanleitung erstellt haben, können Sie auch die Einstellung "Einfache Tabellen " im Azure-Portal verwenden.
Anleitung: Installieren des verwalteten Client-SDK-Pakets
Verwenden Sie eine der folgenden Methoden, um das verwaltete Client-SDK-Paket für mobile Apps von NuGet zu installieren:
- Visual Studio Klicken Sie mit der rechten Maustaste auf Ihr Projekt, klicken Sie auf "NuGet-Pakete verwalten", suchen Sie nach dem
Microsoft.Azure.Mobile.ClientPaket, und klicken Sie dann auf "Installieren". - Xamarin Studio Klicken Sie mit der rechten Maustaste auf Ihr Projekt, klicken Sie auf"NuGet-Pakete>", suchen Sie nach dem
Microsoft.Azure.Mobile.ClientPaket, und klicken Sie dann auf "Paket hinzufügen".
Denken Sie in Ihrer Hauptaktivitätsdatei daran, die folgende using-Anweisung hinzuzufügen:
using Microsoft.WindowsAzure.MobileServices;
Hinweis
Bitte beachten Sie, dass alle Supportpakete, auf die in Ihrem Android-Projekt verwiesen wird, dieselbe Version aufweisen müssen. Das SDK verfügt über Xamarin.Android.Support.CustomTabs Abhängigkeiten für die Android-Plattform. Wenn Ihr Projekt also neuere Supportpakete verwendet, müssen Sie dieses Paket mit der erforderlichen Version direkt installieren, um Konflikte zu vermeiden.
Vorgehensweise: Arbeiten mit Debugsymbolen in Visual Studio
Die Symbole für den Microsoft.Azure.Mobile-Namespace sind auf SymbolSource verfügbar. Informationen zum Integrieren von SymbolSource in Visual Studio finden Sie in den SymbolSource-Anweisungen .
Erstellen des Clients für mobile Apps
Der folgende Code erstellt das MobileServiceClient--Objekt, das für den Zugriff auf Ihr Mobile App-Back-End verwendet wird.
var client = new MobileServiceClient("MOBILE_APP_URL");
Ersetzen Sie MOBILE_APP_URL im vorangegangenen Code durch die URL des Mobile App-Backends, das im Bereich für Ihr Mobile App-Backend im Azure-Portal zu finden ist. Das MobileServiceClient-Objekt sollte ein Singleton sein.
Arbeiten mit Tabellen
Im folgenden Abschnitt wird erläutert, wie Datensätze gesucht und abgerufen und die Daten in der Tabelle geändert werden. Die folgenden Themen werden behandelt:
- Erstellen eines Tabellenverweises
- Daten abfragen
- Vom Filter zurückgegebene Daten
- Zurückgegebene Daten sortieren
- Daten seitenweise zurückgeben
- Auswählen bestimmter Spalten
- Nachschlagen eines Datensatzes mit ID
- Umgang mit nicht typisierten Abfragen
- Einfügen von Daten
- Aktualisieren von Daten
- Löschen von Daten
- Konfliktauflösung und optimistische Parallelität
- Binden an eine Windows-Benutzeroberfläche
- Ändern des Seitenformats
So geht's: Erstellen einer Tabellenreferenz
Der gesamte Code, der auf Daten in einer Back-End-Tabelle zugreift oder ändert, ruft Funktionen für das MobileServiceTable-Objekt auf. Rufen Sie einen Verweis auf die Tabelle ab, indem Sie die GetTable--Methode wie folgt aufrufen:
IMobileServiceTable<TodoItem> todoTable = client.GetTable<TodoItem>();
Das zurückgegebene Objekt verwendet das typierte Serialisierungsmodell. Ein nicht typisiertes Serialisierungsmodell wird ebenfalls unterstützt. Im folgenden Beispiel wird ein Verweis auf eine nicht typisierte Tabelleerstellt:
// Get an untyped table reference
IMobileServiceTable untypedTodoTable = client.GetTable("TodoItem");
In nicht typisierten Abfragen müssen Sie die zugrunde liegende OData-Abfragezeichenfolge angeben.
Vorgehensweise: Abfragen von Daten aus Ihrer mobilen App
In diesem Abschnitt wird beschrieben, wie Sie Abfragen an das Mobile App-Back-End ausgeben, das die folgenden Funktionen enthält:
- Vom Filter zurückgegebene Daten
- Zurückgegebene Daten sortieren
- Daten seitenweise zurückgeben
- Auswählen bestimmter Spalten
- Daten nach ID suchen
Hinweis
Eine servergesteuerte Seitengröße wird erzwungen, um zu verhindern, dass alle Zeilen zurückgegeben werden. Durch Paging wird verhindert, dass Standardanforderungen für große Datensätze negative Auswirkungen auf den Dienst haben. Um mehr als 50 Zeilen zurückzugeben, verwenden Sie die methode Skip und Take, wie in Rückgabedaten in Seitenbeschrieben.
Vorgehensweise: Filtern zurückgegebener Daten
Der folgende Code veranschaulicht, wie Daten gefiltert werden, indem eine Where-Klausel in eine Abfrage eingeschlossen wird. Es gibt alle Elemente aus todoTable zurück, deren Complete Eigenschaft gleich falseist. Die Where-Funktion wendet ein Zeilenfilter-Prädikat auf die Abfrage für die Tabelle an.
// This query filters out completed TodoItems and items without a timestamp.
List<TodoItem> items = await todoTable
.Where(todoItem => todoItem.Complete == false)
.ToListAsync();
Sie können den URI der an das Back-End gesendeten Anforderung mithilfe von Nachrichtenüberprüfungssoftware anzeigen, z. B. Browserentwicklertools oder Fiddler. Wenn Sie den Anforderungs-URI betrachten, beachten Sie, dass die Abfragezeichenfolge geändert wird:
GET /tables/todoitem?$filter=(complete+eq+false) HTTP/1.1
Diese OData-Anforderung wird in eine SQL-Abfrage vom Server SDK übersetzt:
SELECT *
FROM TodoItem
WHERE ISNULL(complete, 0) = 0
Die Funktion, die an die Where-Methode übergeben wird, kann eine beliebige Anzahl von Bedingungen aufweisen.
// This query filters out completed TodoItems where Text isn't null
List<TodoItem> items = await todoTable
.Where(todoItem => todoItem.Complete == false && todoItem.Text != null)
.ToListAsync();
In diesem Beispiel wird der Server SDK das Beispiel in eine SQL-Abfrage umwandeln.
SELECT *
FROM TodoItem
WHERE ISNULL(complete, 0) = 0
AND ISNULL(text, 0) = 0
Diese Abfrage kann auch in mehrere Klauseln aufgeteilt werden:
List<TodoItem> items = await todoTable
.Where(todoItem => todoItem.Complete == false)
.Where(todoItem => todoItem.Text != null)
.ToListAsync();
Die beiden Methoden sind gleichwertig und können austauschbar verwendet werden. Die frühere Option zum Verketten mehrerer Prädikate in einer Abfrage ist kompakter und empfohlener.
Die Where-Klausel unterstützt Vorgänge, die in die OData-Teilmenge übersetzt werden. Zu den Vorgängen gehören:
- Relationale Operatoren (==, !=, <= <, >= >),
- Arithmetische Operatoren (+, -, /, *, %),
- Präzision bei Zahlen (Math.Floor, Math.Ceiling)
- Zeichenfolgenfunktionen (Length, Substring, Replace, IndexOf, StartsWith, EndsWith),
- Datumseigenschaften (Jahr, Monat, Tag, Stunde, Minute, Sekunde),
- Zugreifen auf Eigenschaften eines Objekts und
- Ausdrücke, die eine dieser Vorgänge kombinieren.
Wenn Sie überlegen, was das Server SDK unterstützt, können Sie die OData v3 Documentationberücksichtigen.
Vorgehensweise: Sortieren zurückgegebener Daten
Der folgende Code veranschaulicht, wie Daten sortiert werden, indem eine OrderBy- oder OrderByDescending- funktion in die Abfrage eingeschlossen wird. Es gibt die Elemente aus todoTable zurück, die nach dem Feld Text aufsteigend sortiert sind.
// Sort items in ascending order by Text field
MobileServiceTableQuery<TodoItem> query = todoTable
.OrderBy(todoItem => todoItem.Text)
List<TodoItem> items = await query.ToListAsync();
// Sort items in descending order by Text field
MobileServiceTableQuery<TodoItem> query = todoTable
.OrderByDescending(todoItem => todoItem.Text)
List<TodoItem> items = await query.ToListAsync();
Anleitung: Daten seitenweise zurückgeben
Standardmäßig gibt das Back-End nur die ersten 50 Zeilen zurück. Sie können die Anzahl der zurückgegebenen Zeilen erhöhen, indem Sie die Take-Methode aufrufen. Verwenden Sie Take zusammen mit der Skip-Methode, um eine bestimmte "Seite" des gesamt von der Abfrage zurückgegebenen Datasets anzufordern. Die folgende Abfrage gibt bei Ausführung die drei obersten Elemente in der Tabelle zurück.
// Define a filtered query that returns the top 3 items.
MobileServiceTableQuery<TodoItem> query = todoTable.Take(3);
List<TodoItem> items = await query.ToListAsync();
Die folgende überarbeitete Abfrage überspringt die ersten drei Ergebnisse und gibt die nächsten drei Ergebnisse zurück. Diese Abfrage erzeugt die zweite "Seite" von Daten, wobei die Seitengröße drei Elemente ist.
// Define a filtered query that skips the top 3 items and returns the next 3 items.
MobileServiceTableQuery<TodoItem> query = todoTable.Skip(3).Take(3);
List<TodoItem> items = await query.ToListAsync();
Die IncludeTotalCount- Methode fordert die Gesamtanzahl für alle der zurückgegebenen Datensätze an, wobei alle angegebenen Paging/Limit-Klauseln ignoriert werden:
query = query.IncludeTotalCount();
In einer realen App können Sie Abfragen verwenden, die dem vorherigen Beispiel mit einem Pager-Steuerelement oder einer vergleichbaren Benutzeroberfläche ähneln, um zwischen Seiten zu navigieren.
Hinweis
Um den Grenzwert von 50 Zeilen in einem Mobilen App-Back-End außer Kraft zu setzen, müssen Sie auch die EnableQueryAttribute- auf die öffentliche GET-Methode anwenden und das Pagingverhalten angeben. Bei Anwendung auf die Methode legt Folgendes die maximal zurückgegebenen Zeilen auf 1000 fest:
[EnableQuery(MaxTop=1000)]
Vorgehensweise: Auswählen bestimmter Spalten
Sie können angeben, welche Eigenschaften in die Ergebnisse einbezogen werden sollen, indem Sie ihrer Abfrage eine Select-Klausel hinzufügen. Mit dem folgenden Code wird beispielsweise gezeigt, wie sie nur ein Feld auswählen und auch mehrere Felder auswählen und formatieren:
// Select one field -- just the Text
MobileServiceTableQuery<TodoItem> query = todoTable
.Select(todoItem => todoItem.Text);
List<string> items = await query.ToListAsync();
// Select multiple fields -- both Complete and Text info
MobileServiceTableQuery<TodoItem> query = todoTable
.Select(todoItem => string.Format("{0} -- {1}",
todoItem.Text.PadRight(30), todoItem.Complete ?
"Now complete!" : "Incomplete!"));
List<string> items = await query.ToListAsync();
Alle bisher beschriebenen Funktionen sind additiv, damit wir sie weiter verketten können. Jeder verkettete Aufruf wirkt sich stärker auf die Abfrage aus. Ein weiteres Beispiel:
MobileServiceTableQuery<TodoItem> query = todoTable
.Where(todoItem => todoItem.Complete == false)
.Select(todoItem => todoItem.Text)
.Skip(3).
.Take(3);
List<string> items = await query.ToListAsync();
Gewusst wie: Nachschlagen von Daten nach ID
Die LookupAsync--Funktion kann verwendet werden, um Objekte aus der Datenbank mit einer bestimmten ID nachzuschlagen.
// This query filters out the item with the ID of 37BBF396-11F0-4B39-85C8-B319C729AF6D
TodoItem item = await todoTable.LookupAsync("37BBF396-11F0-4B39-85C8-B319C729AF6D");
Vorgehensweise: Ausführen von nicht typisierten Abfragen
Wenn Sie eine Abfrage mit einem nicht typisierten Tabellenobjekt ausführen, müssen Sie die OData-Abfragezeichenfolge explizit angeben, indem Sie ReadAsync-aufrufen, wie im folgenden Beispiel gezeigt:
// Lookup untyped data using OData
JToken untypedItems = await untypedTodoTable.ReadAsync("$filter=complete eq 0&$orderby=text");
Sie erhalten JSON-Werte, die Sie wie eine Eigenschaften-Sammlung verwenden können. Weitere Informationen zu JToken und Newtonsoft Json.NET finden Sie auf der Json.NET-Website .
Vorgehensweise: Einfügen von Daten in ein Mobile App-Back-End
Alle Clienttypen müssen ein Element mit dem Namen IDenthalten, das standardmäßig eine Zeichenfolge ist. Diese ID- ist erforderlich, um CRUD-Vorgänge und offline zu synchronisieren. Der folgende Code veranschaulicht, wie die InsertAsync--Methode verwendet wird, um neue Zeilen in eine Tabelle einzufügen. Der Parameter enthält die Daten, die als .NET-Objekt eingefügt werden sollen.
await todoTable.InsertAsync(todoItem);
Wenn während eines Einfügens kein eindeutiger benutzerdefinierter ID-Wert in der todoItem enthalten ist, wird vom Server eine GUID generiert.
Sie können die generierte ID abrufen, indem Sie das Objekt überprüfen, nachdem der Aufruf zurückgegeben wurde.
Um nicht typisierte Daten einzufügen, können Sie Json.NET nutzen:
JObject jo = new JObject();
jo.Add("Text", "Hello World");
jo.Add("Complete", false);
var inserted = await table.InsertAsync(jo);
Nachfolgend sehen Sie ein Beispiel für die Verwendung einer E-Mail-Adresse als eindeutige Zeichenfolgen-ID:
JObject jo = new JObject();
jo.Add("id", "myemail@emaildomain.com");
jo.Add("Text", "Hello World");
jo.Add("Complete", false);
var inserted = await table.InsertAsync(jo);
Arbeiten mit ID-Werten
Mobile Apps unterstützt eindeutige benutzerdefinierte Zeichenfolgenwerte für die ID der Tabelle Spalte. Mit einem Zeichenfolgenwert können Anwendungen benutzerdefinierte Werte wie E-Mail-Adressen oder Benutzernamen für die ID verwenden. Zeichenfolgen-IDs bieten Ihnen die folgenden Vorteile:
- IDs werden generiert, ohne einen Roundtrip zur Datenbank vorzunehmen.
- Datensätze aus unterschiedlichen Tabellen oder Datenbanken lassen sich leichter zusammenführen.
- IDs-Werte können besser in die Logik einer Anwendung integriert werden.
Wenn kein Zeichenfolgen-ID-Wert für einen eingefügten Datensatz festgelegt wird, generiert das Mobile App-Back-End einen eindeutigen Wert für die ID. Sie können die Guid.NewGuid Methode verwenden, um eigene ID-Werte entweder auf dem Client oder im Back-End zu generieren.
JObject jo = new JObject();
jo.Add("id", Guid.NewGuid().ToString("N"));
Vorgehensweise: Ändern von Daten in einem Mobilen App-Back-End
Im folgenden Code wird veranschaulicht, wie Sie mithilfe der UpdateAsync Methode einen vorhandenen Datensatz mit derselben ID mit neuen Informationen aktualisieren. Der Parameter enthält die Daten, die als .NET-Objekt aktualisiert werden sollen.
await todoTable.UpdateAsync(todoItem);
Um nicht eingegebene Daten zu aktualisieren, können Sie Json.NET wie folgt nutzen:
JObject jo = new JObject();
jo.Add("id", "37BBF396-11F0-4B39-85C8-B319C729AF6D");
jo.Add("Text", "Hello World");
jo.Add("Complete", false);
var inserted = await table.UpdateAsync(jo);
Ein id-Feld muss beim Aktualisieren angegeben werden. Das Back-End verwendet das feld id, um zu identifizieren, welche Zeile aktualisiert werden soll. Das feld id kann aus dem Ergebnis des InsertAsync Aufrufs abgerufen werden. Ein ArgumentException wird ausgelöst, wenn Sie versuchen, ein Element zu aktualisieren, ohne den id Wert bereitzustellen.
Vorgehensweise: Löschen von Daten in einem Mobilen App-Back-End
Der folgende Code veranschaulicht, wie die DeleteAsync--Methode zum Löschen einer vorhandenen Instanz verwendet wird. Die Instanz wird durch das Feld id auf der todoItem identifiziert.
await todoTable.DeleteAsync(todoItem);
Um nicht eingegebene Daten zu löschen, können Sie Json.NET wie folgt nutzen:
JObject jo = new JObject();
jo.Add("id", "37BBF396-11F0-4B39-85C8-B319C729AF6D");
await table.DeleteAsync(jo);
Wenn Sie eine Löschanforderung vornehmen, muss eine ID angegeben werden. Andere Eigenschaften werden nicht an den Dienst übergeben oder beim Dienst ignoriert. Das Ergebnis eines DeleteAsync Anrufs wird in der Regel null. Die ID, die übergeben werden soll, kann aus dem Ergebnis des InsertAsync Aufrufs abgerufen werden. Ein MobileServiceInvalidOperationException wird ausgelöst, wenn Sie versuchen, ein Element zu löschen, ohne das feld id anzugeben.
Vorgehensweise: Verwenden der optimistischen Parallelität für die Konfliktauflösung
Zwei oder mehr Clients können Gleichzeitig Änderungen an demselben Element schreiben. Ohne Konflikterkennung würde der letzte Schreibvorgang alle vorherigen Updates überschreiben. Optimistische Parallelitätssteuerung nimmt an, dass jede Transaktion abgeschlossen werden kann und daher keine Ressourcensperren verwendet. Vor dem Commit einer Transaktion überprüft die optimistische Nebenläufigkeitskontrolle, dass keine andere Transaktion die Daten geändert hat. Wenn die Daten geändert wurden, wird die Transaktion rückgängig gemacht.
Mobile Apps unterstützt optimistische Parallelitätssteuerung, indem Änderungen an den einzelnen Elementen mithilfe der version Systemeigenschaftenspalte nachverfolgt werden, die für jede Tabelle in Ihrem Mobile App-Back-End definiert ist. Jedes Mal, wenn ein Datensatz aktualisiert wird, legt Mobile Apps die version-Eigenschaft für diesen Datensatz auf einen neuen Wert fest. Bei jeder Aktualisierungsanforderung wird die version Eigenschaft des Datensatzes, der in der Anforderung enthalten ist, mit der gleichen Eigenschaft für den Datensatz auf dem Server verglichen. Wenn die mit der Anforderung übergebene Version nicht mit dem Back-End übereinstimmt, löst die Clientbibliothek eine MobileServicePreconditionFailedException<T> Ausnahme aus. Der in der Ausnahme enthaltene Typ ist der Datensatz aus dem Back-End, der die Serverversion des Datensatzes enthält. Die Anwendung kann diese Informationen dann verwenden, um zu entscheiden, ob die Updateanforderung erneut mit dem richtigen version Wert aus dem Back-End ausgeführt werden soll, um Änderungen zu übernehmen.
Definieren Sie eine Spalte in der Tabellenklasse für die version Systemeigenschaft, um eine optimistische Parallelität zu ermöglichen. Beispiel:
public class TodoItem
{
public string Id { get; set; }
[JsonProperty(PropertyName = "text")]
public string Text { get; set; }
[JsonProperty(PropertyName = "complete")]
public bool Complete { get; set; }
// *** Enable Optimistic Concurrency *** //
[JsonProperty(PropertyName = "version")]
public string Version { set; get; }
}
Anwendungen, die untypisierte Tabellen verwenden, ermöglichen eine optimistische Synchronisierung, indem sie das Version-Flag für die SystemProperties der Tabelle wie folgt festlegen.
//Enable optimistic concurrency by retrieving version
todoTable.SystemProperties |= MobileServiceSystemProperties.Version;
Zusätzlich zur Aktivierung optimistischer Parallelität müssen Sie beim Aufrufen von MobileServicePreconditionFailedException<T> auch die Ausnahme in Ihrem Code abfangen. Lösen Sie den Konflikt, indem Sie den richtigen version auf den aktualisierten Datensatz anwenden und UpdateAsync- mit dem aufgelösten Datensatz aufrufen. Der folgende Code zeigt, wie ein Schreibkonflikt gelöst wird, nachdem ein Fehler erkannt wurde:
private async void UpdateToDoItem(TodoItem item)
{
MobileServicePreconditionFailedException<TodoItem> exception = null;
try
{
//update at the remote table
await todoTable.UpdateAsync(item);
}
catch (MobileServicePreconditionFailedException<TodoItem> writeException)
{
exception = writeException;
}
if (exception != null)
{
// Conflict detected, the item has changed since the last query
// Resolve the conflict between the local and server item
await ResolveConflict(item, exception.Item);
}
}
private async Task ResolveConflict(TodoItem localItem, TodoItem serverItem)
{
//Ask user to choose the resolution between versions
MessageDialog msgDialog = new MessageDialog(
String.Format("Server Text: \"{0}\" \nLocal Text: \"{1}\"\n",
serverItem.Text, localItem.Text),
"CONFLICT DETECTED - Select a resolution:");
UICommand localBtn = new UICommand("Commit Local Text");
UICommand ServerBtn = new UICommand("Leave Server Text");
msgDialog.Commands.Add(localBtn);
msgDialog.Commands.Add(ServerBtn);
localBtn.Invoked = async (IUICommand command) =>
{
// To resolve the conflict, update the version of the item being committed. Otherwise, you will keep
// catching a MobileServicePreConditionFailedException.
localItem.Version = serverItem.Version;
// Updating recursively here just in case another change happened while the user was making a decision
UpdateToDoItem(localItem);
};
ServerBtn.Invoked = async (IUICommand command) =>
{
RefreshTodoItems();
};
await msgDialog.ShowAsync();
}
Weitere Informationen finden Sie im Thema Offlinedatensynchronisierung in Azure Mobile Apps Thema.
Vorgehensweise: Binden mobiler Apps-Daten an eine Windows-Benutzeroberfläche
In diesem Abschnitt wird gezeigt, wie zurückgegebene Datenobjekte mithilfe von UI-Elementen in einer Windows-App angezeigt werden. Der folgende Beispielcode bindet an die Quelle der Liste mit einer Abfrage nach unvollständigen Elementen. Die MobileServiceCollection erstellt eine mobile Apps-bewusste Bindungssammlung.
// This query filters out completed TodoItems.
MobileServiceCollection<TodoItem, TodoItem> items = await todoTable
.Where(todoItem => todoItem.Complete == false)
.ToCollectionAsync();
// itemsControl is an IEnumerable that could be bound to a UI list control
IEnumerable itemsControl = items;
// Bind this to a ListBox
ListBox lb = new ListBox();
lb.ItemsSource = items;
Einige Steuerelemente in der verwalteten Laufzeit unterstützen eine Schnittstelle namens ISupportIncrementalLoading. Diese Schnittstelle ermöglicht es Steuerelementen, zusätzliche Daten anzufordern, wenn der Benutzer scrollt. Es gibt integrierte Unterstützung für diese Schnittstelle für universelle Windows-Apps über MobileServiceIncrementalLoadingCollection, die die Aufrufe von den Steuerelementen automatisch verarbeitet. Verwenden Sie MobileServiceIncrementalLoadingCollection in Windows-Apps wie folgt:
MobileServiceIncrementalLoadingCollection<TodoItem,TodoItem> items;
items = todoTable.Where(todoItem => todoItem.Complete == false).ToIncrementalLoadingCollection();
ListBox lb = new ListBox();
lb.ItemsSource = items;
Um die neue Auflistung in Windows Phone 8- und Silverlight-Apps zu verwenden, verwenden Sie die ToCollection Erweiterungsmethoden für IMobileServiceTableQuery<T> und IMobileServiceTable<T>. Rufen Sie zum Laden von Daten LoadMoreItemsAsync()auf.
MobileServiceCollection<TodoItem, TodoItem> items = todoTable.Where(todoItem => todoItem.Complete==false).ToCollection();
await items.LoadMoreItemsAsync();
Wenn Sie die durch Aufrufen von ToCollectionAsync oder ToCollectionerstellte Auflistung verwenden, erhalten Sie eine Sammlung, die an UI-Steuerelemente gebunden werden kann. Diese Sammlung ist seitenaufwendigend. Da die Sammlung Daten aus dem Netzwerk lädt, schlägt das Laden manchmal fehl. Um solche Fehler zu behandeln, überschreiben Sie die OnException-Methode für MobileServiceIncrementalLoadingCollection, um Ausnahmen zu behandeln, die sich aus Aufrufen von LoadMoreItemsAsyncergeben.
Überlegen Sie, ob Ihre Tabelle viele Felder enthält, aber nur einige felder in Ihrem Steuerelement anzeigen möchten. Sie können die Anleitungen im vorherigen Abschnitt "Auswählen bestimmter Spalten" verwenden, um bestimmte Spalten auszuwählen, die in der Benutzeroberfläche angezeigt werden sollen.
Ändern der Seitengröße
Azure Mobile Apps gibt standardmäßig maximal 50 Elemente pro Anforderung zurück. Sie können die Seitengröße ändern, indem Sie die maximale Seitengröße sowohl auf dem Client als auch auf dem Server erhöhen. Um die angeforderte Seitengröße zu erhöhen, geben Sie PullOptions an, wenn Sie PullAsync()verwenden:
PullOptions pullOptions = new PullOptions
{
MaxPageSize = 100
};
Angenommen, Sie haben den Wert von PageSize innerhalb des Servers auf 100 oder höher gesetzt, gibt eine Anfrage bis zu 100 Elemente zurück.
Arbeiten mit Offlinetabellen
Offlinetabellen verwenden einen lokalen SQLite-Speicher, um Daten zur Verwendung im Offlinemodus zu speichern. Alle Tabellenvorgänge werden für den lokalen SQLite-Speicher anstelle des Remoteserverspeichers ausgeführt. Um eine Offlinetabelle zu erstellen, bereiten Sie zuerst Ihr Projekt vor:
Klicken Sie in Visual Studio mit der rechten Maustaste auf die Projektmappe >NuGet-Pakete für Projektmappe verwalten..., und installieren Sie dann das Microsoft.Azure.Mobile.Client.SQLiteStore NuGet-Paket für alle Projekte in der Projektmappe.
(Optional) Um Windows-Geräte zu unterstützen, installieren Sie eines der folgenden SQLite-Laufzeitpakete:
- Windows 8.1-Runtime: Installieren Sie SQLite für Windows 8.1.
- Windows Phone 8.1: Installieren Sie SQLite für Windows Phone 8.1.
- Universelle Windows-Plattform Installieren Sie SQLite für die universelle Windows-App.
(optional) Klicken Sie für Windows-Geräte auf Verweise>Verweis hinzufügen..., erweitern Sie den Windows-Ordner und die >, und aktivieren Sie dann das entsprechende SQLite für Windows SDK zusammen mit dem Visual C++ 2013 Runtime für Windows SDK. Die SQLite SDK-Namen variieren geringfügig bei jeder Windows-Plattform.
Bevor ein Tabellenverweis erstellt werden kann, muss der lokale Speicher vorbereitet werden:
var store = new MobileServiceSQLiteStore(Constants.OfflineDbPath);
store.DefineTable<TodoItem>();
//Initializes the SyncContext using the default IMobileServiceSyncHandler.
await this.client.SyncContext.InitializeAsync(store);
Die Store-Initialisierung erfolgt normalerweise unmittelbar nach dem Erstellen des Clients. Die OfflineDbPath- sollte ein Dateiname sein, der für die Verwendung auf allen von Ihnen unterstützten Plattformen geeignet ist. Wenn der Pfad ein vollqualifizierter Pfad ist (d. h. er beginnt mit einem Schrägstrich), wird dieser Pfad verwendet. Wenn der Pfad nicht vollständig qualifiziert ist, wird die Datei an einem plattformspezifischen Speicherort platziert.
- Für iOS- und Android-Geräte ist der Standardpfad der Ordner "Persönliche Dateien".
- Für Windows-Geräte ist der Standardpfad der anwendungsspezifische Ordner "AppData".
Mithilfe der GetSyncTable<>-Methode kann ein Tabellenverweis abgerufen werden:
var table = client.GetSyncTable<TodoItem>();
Sie müssen sich nicht authentifizieren, um eine Offlinetabelle zu verwenden. Sie müssen sich nur authentifizieren, wenn Sie mit dem Back-End-Dienst kommunizieren.
Synchronisieren einer Offlinetabelle
Offlinetabellen werden standardmäßig nicht mit dem Back-End synchronisiert. Die Synchronisierung wird in zwei Teile aufgeteilt. Sie können Änderungen separat vom Herunterladen neuer Elemente übertragen. Hier ist eine typische Synchronisierungsmethode:
public async Task SyncAsync()
{
ReadOnlyCollection<MobileServiceTableOperationError> syncErrors = null;
try
{
await this.client.SyncContext.PushAsync();
await this.todoTable.PullAsync(
//The first parameter is a query name that is used internally by the client SDK to implement incremental sync.
//Use a different query name for each unique query in your program
"allTodoItems",
this.todoTable.CreateQuery());
}
catch (MobileServicePushFailedException exc)
{
if (exc.PushResult != null)
{
syncErrors = exc.PushResult.Errors;
}
}
// Simple error/conflict handling. A real application would handle the various errors like network conditions,
// server conflicts and others via the IMobileServiceSyncHandler.
if (syncErrors != null)
{
foreach (var error in syncErrors)
{
if (error.OperationKind == MobileServiceTableOperationKind.Update && error.Result != null)
{
//Update failed, reverting to server's copy.
await error.CancelAndUpdateItemAsync(error.Result);
}
else
{
// Discard local change.
await error.CancelAndDiscardItemAsync();
}
Debug.WriteLine(@"Error executing sync operation. Item: {0} ({1}). Operation discarded.", error.TableName, error.Item["id"]);
}
}
}
Wenn das erste Argument für PullAsync null ist, wird die inkrementelle Synchronisierung nicht verwendet. Jeder Synchronisierungsvorgang ruft alle Datensätze ab.
Das SDK führt ein implizites PushAsync() aus, bevor es Datensätze abruft.
Die Konfliktbehandlung erfolgt in einer PullAsync()-Methode. Sie können Konflikte auf die gleiche Weise wie Onlinetabellen behandeln. Der Konflikt wird erzeugt, wenn PullAsync() anstelle des Einfügens, Aktualisierens oder Löschens aufgerufen wird. Wenn mehrere Konflikte auftreten, werden sie in einer einzigen MobileServicePushFailedException gebündelt. Behandeln Sie jeden Fehler separat.
Arbeiten mit einer benutzerdefinierten API
Mit einer benutzerdefinierten API können Sie benutzerdefinierte Endpunkte definieren, die Serverfunktionen zur Verfügung stellen, welche keinem Einfüge-, Aktualisierungs-, Lösch- oder Lesevorgang zugeordnet sind. Durch die Verwendung einer benutzerdefinierten API erhalten Sie mehr Kontrolle über das Messaging, einschließlich Lesen und Einstellen der HTTP-Nachrichten-Header sowie Definieren eines von JSON abweichenden Nachrichtentextformats.
Sie rufen eine benutzerdefinierte API auf, indem Sie eine der InvokeApiAsync- Methoden auf dem Client aufrufen. Beispielsweise sendet die folgende Codezeile eine POST-Anforderung an die completeAll API im Back-End:
var result = await client.InvokeApiAsync<MarkAllResult>("completeAll", System.Net.Http.HttpMethod.Post, null);
Dieses Formular ist ein typierter Methodenaufruf und erfordert, dass der MarkAllResult- Rückgabetyp definiert ist. Sowohl typisierte als auch nicht typisierte Methoden werden unterstützt.
Die InvokeApiAsync()-Methode stellt "/api/" der API voran, die Sie aufrufen möchten, es sei denn, die API beginnt mit einem "/". Beispiel:
InvokeApiAsync("completeAll",...)ruft /api/completeAll im Back-end aufInvokeApiAsync("/.auth/me",...)aufruft /.auth/me im Back-End
Sie können InvokeApiAsync verwenden, um eine beliebige WebAPI aufzurufen, einschließlich der WebAPIs, die nicht mit Azure Mobile Apps definiert sind. Wenn Sie InvokeApiAsync() verwenden, werden die entsprechenden Header, einschließlich Authentifizierungsheadern, mit der Anforderung gesendet.
Authentifizieren von Benutzern
Mobile Apps unterstützt die Authentifizierung und Autorisierung von App-Benutzern mithilfe verschiedener externer Identitätsanbieter: Facebook, Google, Microsoft-Konto, Twitter und Azure Active Directory. Sie können Berechtigungen für Tabellen vergeben, um den Zugriff auf bestimmte Operationen auf authentifizierte Benutzer zu beschränken. Sie können auch die Identität authentifizierter Benutzer verwenden, um Autorisierungsregeln in Serverskripts zu implementieren. Weitere Informationen finden Sie im Lernprogramm Hinzufügen der Authentifizierung zu Ihrer App.
Zwei Authentifizierungsflüsse werden unterstützt: vom Client verwalteten und vom Server verwalteten-Fluss. Der vom Server verwaltete Fluss bietet die einfachste Authentifizierung, da er auf der Webauthentifizierungsschnittstelle des Anbieters basiert. Der vom Client verwaltete Fluss ermöglicht eine tiefere Integration in gerätespezifische Funktionen, da er auf anbieterspezifischen gerätespezifischen SDKs basiert.
Hinweis
Wir empfehlen die Verwendung eines clientseitig verwalteten Ablaufs in Ihren Produktionsanwendungen.
Zum Einrichten der Authentifizierung müssen Sie Ihre App bei einem oder mehreren Identitätsanbietern registrieren. Der Identitätsanbieter generiert eine Client-ID und einen geheimen Clientschlüssel für Ihre App. Diese Werte werden dann in Ihrem Back-End festgelegt, um die Azure App Service-Authentifizierung/Autorisierung zu aktivieren. Weitere Informationen finden Sie in den detaillierten Anweisungen im Lernprogramm Zum Hinzufügen der Authentifizierung zu Ihrer App.
Die folgenden Themen werden in diesem Abschnitt behandelt:
- Client-verwaltete Authentifizierung
- vom Server verwalteten Authentifizierung
- Zwischenspeichern des Authentifizierungstokens
Clientverwaltete Authentifizierung
Ihre App kann sich unabhängig an den Identitätsanbieter wenden und dann das zurückgegebene Token während der Anmeldung mit Ihrem Back-End bereitstellen. Mit diesem Clientfluss können Sie benutzern eine Einmalige Anmeldung ermöglichen oder zusätzliche Benutzerdaten vom Identitätsanbieter abrufen. Die Clientflussauthentifizierung wird gegenüber einem Serverfluss bevorzugt, da das Identitätsanbieter-SDK ein nativeres UX-Gefühl bietet und zusätzliche Anpassungen ermöglicht.
Beispiele werden für die folgenden Clientflussauthentifizierungsmuster bereitgestellt:
Authentifizieren von Benutzern mit der Active Directory-Authentifizierungsbibliothek
Sie können die Active Directory-Authentifizierungsbibliothek (Active Directory Authentication Library, ADAL) verwenden, um die Benutzerauthentifizierung über den Client mithilfe der Azure Active Directory-Authentifizierung zu initiieren.
Konfigurieren Sie Ihr mobiles App-Back-End für die AAD-Anmeldung, indem Sie dem Lernprogramm zum Konfigurieren des App Service für Active Directory folgen . Schließen Sie auch den optionalen Schritt zur Registrierung einer nativen Clientanwendung ab.
Öffnen Sie in Visual Studio oder Xamarin Studio Ihr Projekt, und fügen Sie einen Verweis auf das
Microsoft.IdentityModel.Clients.ActiveDirectoryNuGet-Paket hinzu. Schließen Sie bei der Suche Vorabversionen ein.Fügen Sie Ihrer Anwendung entsprechend der verwendeten Plattform den folgenden Code hinzu. Nehmen Sie in jedem die folgenden Ersetzungen vor:
Ersetzen Sie INSERT-AUTHORITY-HERE durch den Namen des Mandanten, in dem Sie Ihre Anwendung bereitgestellt haben. Das Format muss
https://login.microsoftonline.com/contoso.onmicrosoft.comsein. Dieser Wert kann auf der Registerkarte "Domäne" in Ihrem Azure Active Directory im Azure-Portal kopiert werden.Ersetzen Sie INSERT-RESOURCE-ID-HERE durch die Client-ID für Ihr mobiles App-Back-End. Sie können die Client-ID im Portal auf der Registerkarte Erweitert unter Azure Active Directory-Einstellungen abrufen.
Ersetzen Sie INSERT-CLIENT-ID-HERE durch die Client-ID, die Sie aus der nativen Clientanwendung kopiert haben.
Ersetzen Sie mithilfe des HTTPS-Schemas INSERT-REDIRECT-URI-HERE durch den Endpunkt /.auth/login/done Ihrer Website. Dieser Wert sollte
https://contoso.azurewebsites.net/.auth/login/doneähnlich sein.Der für jede Plattform benötigte Code folgt:
Windows:
private MobileServiceUser user; private async Task AuthenticateAsync() { string authority = "INSERT-AUTHORITY-HERE"; string resourceId = "INSERT-RESOURCE-ID-HERE"; string clientId = "INSERT-CLIENT-ID-HERE"; string redirectUri = "INSERT-REDIRECT-URI-HERE"; while (user == null) { string message; try { AuthenticationContext ac = new AuthenticationContext(authority); AuthenticationResult ar = await ac.AcquireTokenAsync(resourceId, clientId, new Uri(redirectUri), new PlatformParameters(PromptBehavior.Auto, false) ); JObject payload = new JObject(); payload["access_token"] = ar.AccessToken; user = await App.MobileService.LoginAsync( MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory, payload); message = string.Format("You are now logged in - {0}", user.UserId); } catch (InvalidOperationException) { message = "You must log in. Login Required"; } var dialog = new MessageDialog(message); dialog.Commands.Add(new UICommand("OK")); await dialog.ShowAsync(); } }Xamarin.iOS
private MobileServiceUser user; private async Task AuthenticateAsync(UIViewController view) { string authority = "INSERT-AUTHORITY-HERE"; string resourceId = "INSERT-RESOURCE-ID-HERE"; string clientId = "INSERT-CLIENT-ID-HERE"; string redirectUri = "INSERT-REDIRECT-URI-HERE"; try { AuthenticationContext ac = new AuthenticationContext(authority); AuthenticationResult ar = await ac.AcquireTokenAsync(resourceId, clientId, new Uri(redirectUri), new PlatformParameters(view)); JObject payload = new JObject(); payload["access_token"] = ar.AccessToken; user = await client.LoginAsync( MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory, payload); } catch (Exception ex) { Console.Error.WriteLine(@"ERROR - AUTHENTICATION FAILED {0}", ex.Message); } }Xamarin.Android
private MobileServiceUser user; private async Task AuthenticateAsync() { string authority = "INSERT-AUTHORITY-HERE"; string resourceId = "INSERT-RESOURCE-ID-HERE"; string clientId = "INSERT-CLIENT-ID-HERE"; string redirectUri = "INSERT-REDIRECT-URI-HERE"; try { AuthenticationContext ac = new AuthenticationContext(authority); AuthenticationResult ar = await ac.AcquireTokenAsync(resourceId, clientId, new Uri(redirectUri), new PlatformParameters(this)); JObject payload = new JObject(); payload["access_token"] = ar.AccessToken; user = await client.LoginAsync( MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory, payload); } catch (Exception ex) { AlertDialog.Builder builder = new AlertDialog.Builder(this); builder.SetMessage(ex.Message); builder.SetTitle("You must log in. Login Required"); builder.Create().Show(); } } protected override void OnActivityResult(int requestCode, Result resultCode, Intent data) { base.OnActivityResult(requestCode, resultCode, data); AuthenticationAgentContinuationHelper.SetAuthenticationAgentContinuationEventArgs(requestCode, resultCode, data); }
Single Sign-On mit einem Token von Facebook oder Google
Sie können den Clientfluss wie in diesem Codeausschnitt für Facebook oder Google gezeigt verwenden.
var token = new JObject();
// Replace access_token_value with actual value of your access token obtained
// using the Facebook or Google SDK.
token.Add("access_token", "access_token_value");
private MobileServiceUser user;
private async Task AuthenticateAsync()
{
while (user == null)
{
string message;
try
{
// Change MobileServiceAuthenticationProvider.Facebook
// to MobileServiceAuthenticationProvider.Google if using Google auth.
user = await client.LoginAsync(MobileServiceAuthenticationProvider.Facebook, token);
message = string.Format("You are now logged in - {0}", user.UserId);
}
catch (InvalidOperationException)
{
message = "You must log in. Login Required";
}
var dialog = new MessageDialog(message);
dialog.Commands.Add(new UICommand("OK"));
await dialog.ShowAsync();
}
}
Serververwaltete Authentifizierung
Nachdem Sie Ihren Identitätsanbieter registriert haben, rufen Sie die LoginAsync-Methode für [MobileServiceClient] mit dem Wert "MobileServiceAuthenticationProvider " Ihres Anbieters auf. Der folgende Code startet beispielsweise eine Server-Flow-Anmeldung mithilfe von Facebook.
private MobileServiceUser user;
private async System.Threading.Tasks.Task Authenticate()
{
while (user == null)
{
string message;
try
{
user = await client
.LoginAsync(MobileServiceAuthenticationProvider.Facebook);
message =
string.Format("You are now logged in - {0}", user.UserId);
}
catch (InvalidOperationException)
{
message = "You must log in. Login Required";
}
var dialog = new MessageDialog(message);
dialog.Commands.Add(new UICommand("OK"));
await dialog.ShowAsync();
}
}
Wenn Sie einen anderen Identitätsanbieter als Facebook verwenden, ändern Sie den Wert von MobileServiceAuthenticationProvider in den Wert für Ihren Anbieter.
In einem Serverablauf verwaltet Azure App Service den OAuth-Authentifizierungsfluss, indem die Anmeldeseite des ausgewählten Anbieters angezeigt wird. Sobald der Identitätsanbieter zurückkehrt, generiert Azure App Service ein App Service-Authentifizierungstoken. Die LoginAsync-Methode gibt einen MobileServiceUser zurück, der sowohl die UserId des authentifizierten Benutzers als auch das MobileServiceAuthenticationToken als JSON-Webtoken (JWT) bereitstellt. Dieses Token kann zwischengespeichert und wiederverwendet werden, bis es abläuft. Weitere Informationen finden Sie unter Zwischenspeichern des Authentifizierungstokens.
Bei Verwendung von Xamarin (android oder iOS) wird Xamarin.Essentials WebAuthenticator verwendet. Sie müssen den Standardkontext (Android) oder UIViewController (iOS) an die LoginAsync Methode übergeben. Darüber hinaus müssen Sie die Rückmeldung vom Webauthentifikator behandeln. In Android wird dies in MainActivity.cs:
public override void OnResume()
{
base.OnResume();
Xamarin.Essentials.Platform.OnResume();
}
Unter iOS wird dies innerhalb von AppDelegate.cs behandelt:On iOS, this is handled within AppDelegate.cs':
public override bool OpenUrl(UIApplication app, NSUrl url, NSDictionary options)
{
if (client.ResumeWithURL(app, url, options))
return true;
return base.OpenUrl(app, url, options);
}
Zwischenspeichern des Authentifizierungstokens
In einigen Fällen kann der Aufruf der Anmeldemethode nach der ersten erfolgreichen Authentifizierung vermieden werden, indem das Authentifizierungstoken vom Anbieter gespeichert wird. Microsoft Store- und UWP-Apps können PasswordVault- verwenden, um das aktuelle Authentifizierungstoken nach einer erfolgreichen Anmeldung wie folgt zwischenzuspeichern:
await client.LoginAsync(MobileServiceAuthenticationProvider.Facebook);
PasswordVault vault = new PasswordVault();
vault.Add(new PasswordCredential("Facebook", client.currentUser.UserId,
client.currentUser.MobileServiceAuthenticationToken));
Der UserId-Wert wird als Benutzername der Anmeldeinformationen gespeichert, und das Token wird als Kennwort gespeichert. Bei nachfolgenden Start-ups können Sie die PasswordVault- auf zwischengespeicherte Anmeldeinformationen überprüfen. Im folgenden Beispiel werden zwischengespeicherte Anmeldeinformationen verwendet, wenn sie gefunden werden, und andernfalls wird versucht, sich erneut beim Back-End zu authentifizieren:
// Try to retrieve stored credentials.
var creds = vault.FindAllByResource("Facebook").FirstOrDefault();
if (creds != null)
{
// Create the current user from the stored credentials.
client.currentUser = new MobileServiceUser(creds.UserName);
client.currentUser.MobileServiceAuthenticationToken =
vault.Retrieve("Facebook", creds.UserName).Password;
}
else
{
// Regular login flow and cache the token as shown above.
}
Wenn Sie sich bei einem Benutzer abmelden, müssen Sie auch die gespeicherten Anmeldeinformationen wie folgt entfernen:
client.Logout();
vault.Remove(vault.Retrieve("Facebook", client.currentUser.UserId));
Xamarin-Apps verwenden die Xamarin.Auth-APIs , um Anmeldeinformationen sicher in einem Account-Objekt zu speichern. Ein Beispiel für die Verwendung dieser APIs finden Sie in der codedatei AuthStore.cs im ContosoMoments-Fotofreigabebeispiel.
Wenn Sie die clientverwaltete Authentifizierung verwenden, können Sie auch das von Ihrem Anbieter abgerufene Zugriffstoken zwischenspeichern, z. B. Facebook oder Twitter. Dieses Token kann bereitgestellt werden, um ein neues Authentifizierungstoken aus dem Back-End anzufordern:
var token = new JObject();
// Replace <your_access_token_value> with actual value of your access token
token.Add("access_token", "<your_access_token_value>");
// Authenticate using the access token.
await client.LoginAsync(MobileServiceAuthenticationProvider.Facebook, token);
Push-Benachrichtigungen
Die folgenden Themen behandeln Pushbenachrichtigungen:
- Registrieren für Pushbenachrichtigungen
- Eine Microsoft Store-Paket-SID abrufen
- Registrieren mit plattformübergreifenden Vorlagen
Vorgehensweise: Registrieren für Pushbenachrichtigungen
Mit dem Client für mobile Apps können Sie sich für Pushbenachrichtigungen mit Azure Notification Hubs registrieren. Bei der Registrierung erhalten Sie ein Handle, das Sie vom plattformspezifischen Pushbenachrichtigungsdienst (PNS) erhalten. Anschließend geben Sie diesen Wert zusammen mit allen Tags an, wenn Sie die Registrierung erstellen. Der folgende Code registriert Ihre Windows-App für Pushbenachrichtigungen mit dem Windows-Benachrichtigungsdienst (Windows Notification Service, WNS):
private async void InitNotificationsAsync()
{
// Request a push notification channel.
var channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();
// Register for notifications using the new channel.
await MobileService.GetPush().RegisterNativeAsync(channel.Uri, null);
}
Wenn Sie an WNS pushen, müssen Sie eine MICROSOFT Store-Paket-SID abrufen. Weitere Informationen zu Windows-Apps, einschließlich der Registrierung von Vorlagen, finden Sie unter Hinzufügen von Pushbenachrichtigungen zu Ihrer App.
Das Anfordern von Tags vom Client wird nicht unterstützt. Taganforderungen werden automatisch aus der Registrierung gelöscht.
Wenn Sie Ihr Gerät mit Tags registrieren möchten, erstellen Sie eine benutzerdefinierte API, die die Notification Hubs-API verwendet, um die Registrierung in Ihrem Auftrag durchzuführen. Rufen Sie die benutzerdefinierte API anstelle der RegisterNativeAsync() Methode auf.
So erhalten Sie eine Microsoft Store Paket-SID
Zum Aktivieren von Pushbenachrichtigungen in Microsoft Store-Apps ist eine Paket-SID erforderlich. Um eine Paket-SID zu erhalten, registrieren Sie Ihre Anwendung beim Microsoft Store.
So rufen Sie diesen Wert ab:
- Klicken Sie im Projektmappen-Explorer von Visual Studio mit der rechten Maustaste auf das Microsoft Store-App-Projekt und wählen Sie Store>App mit dem Store verknüpfen....
- Klicken Sie im Assistenten auf "Weiter", melden Sie sich mit Ihrem Microsoft-Konto an, geben Sie in " Reservieren" einen Namen für Ihre App ein, und klicken Sie dann auf " Reservieren".
- Nachdem die App-Registrierung erfolgreich erstellt wurde, wählen Sie den App-Namen aus, klicken Sie auf "Weiter", und klicken Sie dann auf " Zuordnen".
- Melden Sie sich mit Ihrem Microsoft-Konto beim Windows Dev Center an. Klicken Sie unter "Meine Apps" auf die app-Registrierung, die Sie erstellt haben.
- Klicken Sie auf App-Verwaltung>App-Identität, und scrollen Sie dann nach unten, um Ihre Paket-SID zu finden.
Viele Verwendungen der Paket-SID behandeln sie als URI, in diesem Fall müssen Sie ms-app:// als Schema verwenden. Notieren Sie sich die Version der Paket-SID, die durch Verketten dieses Werts als Präfix gebildet wird.
Xamarin-Apps erfordern zusätzlichen Code, um eine App registrieren zu können, die auf den iOS- oder Android-Plattformen ausgeführt wird. Weitere Informationen finden Sie im Thema für Ihre Plattform:
Vorgehensweise: Registrieren von Pushvorlagen zum Senden plattformübergreifender Benachrichtigungen
Um Vorlagen zu registrieren, verwenden Sie die RegisterAsync() Methode mit den Vorlagen wie folgt:
JObject templates = myTemplates();
MobileService.GetPush().RegisterAsync(channel.Uri, templates);
Ihre Vorlagen sollten Typen sein JObject und können mehrere Vorlagen im folgenden JSON-Format enthalten:
public JObject myTemplates()
{
// single template for Windows Notification Service toast
var template = "<toast><visual><binding template=\"ToastText01\"><text id=\"1\">$(message)</text></binding></visual></toast>";
var templates = new JObject
{
["generic-message"] = new JObject
{
["body"] = template,
["headers"] = new JObject
{
["X-WNS-Type"] = "wns/toast"
},
["tags"] = new JArray()
},
["more-templates"] = new JObject {...}
};
return templates;
}
Die Methode RegisterAsync() akzeptiert auch sekundäre Kacheln:
MobileService.GetPush().RegisterAsync(string channelUri, JObject templates, JObject secondaryTiles);
Alle Tags werden bei der Registrierung zur Sicherheit entfernt. Informationen zum Hinzufügen von Tags zu Installationen oder Vorlagen in Installationen finden Sie unter [Arbeiten mit dem .NET-Back-End-Server-SDK für Azure Mobile Apps].
Informationen zum Senden von Benachrichtigungen mithilfe dieser registrierten Vorlagen finden Sie in den Notification Hubs-APIs.
Verschiedene Themen
Vorgehensweise: Behandeln von Fehlern
Wenn im Back-End ein Fehler auftritt, löst das Client-SDK eine MobileServiceInvalidOperationExceptionaus. Das folgende Beispiel zeigt, wie eine Ausnahme behandelt wird, die vom Back-End zurückgegeben wird:
private async void InsertTodoItem(TodoItem todoItem)
{
// This code inserts a new TodoItem into the database. When the operation completes
// and App Service has assigned an Id, the item is added to the CollectionView
try
{
await todoTable.InsertAsync(todoItem);
items.Add(todoItem);
}
catch (MobileServiceInvalidOperationException e)
{
// Handle error
}
}
Ein weiteres Beispiel für den Umgang mit Fehlerbedingungen finden Sie im Beispiel für Mobile Apps-Dateien. Das LoggingHandler-Beispiel stellt einen Protokolldelegathandler bereit, um die Anforderungen zu protokollieren, die an das Back-End gestellt werden.
Vorgehensweise: Anpassen von Anforderungsheadern
Um Ihr spezifisches App-Szenario zu unterstützen, müssen Sie möglicherweise die Kommunikation mit dem Mobilen App-Back-End anpassen. Sie können beispielsweise jeder ausgehenden Anforderung einen benutzerdefinierten Header hinzufügen oder sogar Antwortstatuscodes ändern. Sie können wie im folgenden Beispiel einen benutzerdefinierten DelegatingHandlerverwenden:
public async Task CallClientWithHandler()
{
MobileServiceClient client = new MobileServiceClient("AppUrl", new MyHandler());
IMobileServiceTable<TodoItem> todoTable = client.GetTable<TodoItem>();
var newItem = new TodoItem { Text = "Hello world", Complete = false };
await todoTable.InsertAsync(newItem);
}
public class MyHandler : DelegatingHandler
{
protected override async Task<HttpResponseMessage>
SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
// Change the request-side here based on the HttpRequestMessage
request.Headers.Add("x-my-header", "my value");
// Do the request
var response = await base.SendAsync(request, cancellationToken);
// Change the response-side here based on the HttpResponseMessage
// Return the modified response
return response;
}
}