Offlinedatensynchronisierung in Azure Mobile Apps

Artikel
10/30/2016

Was ist die Offlinedatensynchronisierung?

Die Offlinedatensynchronisierung ist ein Client- und Server-SDK-Feature von Azure Mobile Apps, mit dem Entwickler Apps erstellen können, die ohne Netzwerkverbindung funktionsfähig sind.

Wenn sich Ihre App im Offlinemodus befindet, können Sie weiterhin Daten erstellen und ändern, die in einem lokalen Store gespeichert werden. Wenn die App wieder online ist, kann sie lokale Änderungen mit Ihrem Azure Mobile App-Back-End synchronisieren. Das Feature enthält auch Unterstützung für die Erkennung von Konflikten, wenn derselbe Datensatz sowohl auf dem Client als auch im Back-End geändert wird. Konflikte können dann entweder auf dem Server oder dem Client behandelt werden.

Die Offlinesynchronisierung bietet mehrere Vorteile:

Verbessern der App-Reaktionsfähigkeit durch lokales Zwischenspeichern von Serverdaten auf dem Gerät
Erstellen robuster Apps, die nützlich bleiben, wenn Netzwerkprobleme auftreten
Zulassen, dass Endbenutzer Daten erstellen und ändern können, auch wenn kein Netzwerkzugriff vorhanden ist, die Szenarien mit wenig oder ohne Konnektivität unterstützen
Synchronisieren von Daten auf mehreren Geräten und Erkennen von Konflikten, wenn derselbe Datensatz von zwei Geräten geändert wird
Beschränken der Netzwerknutzung in netzwerken mit hoher Latenz oder getakteten Netzwerken

In den folgenden Lernprogrammen wird gezeigt, wie Sie Ihren mobilen Clients mithilfe von Azure Mobile Apps Offlinesynchronisierung hinzufügen:

Was ist eine Synchronisierungstabelle?

Um auf den Endpunkt "/tables" zuzugreifen, stellen die Azure Mobile-Client-SDKs Schnittstellen wie IMobileServiceTable (.NET Client SDK) oder MSTable (iOS-Client) bereit. Diese APIs stellen eine direkte Verbindung mit dem Azure Mobile App-Back-End her und schlagen fehl, wenn das Clientgerät keine Netzwerkverbindung hat.

Um die Offlineverwendung zu unterstützen, sollte Ihre App stattdessen die Synchronisierungstabelle APIs verwenden, z. B. IMobileServiceSyncTable (.NET-Client-SDK) oder MSSyncTable (iOS-Client). Alle CRUD-Vorgänge (Create, Read, Update, Delete) werden an den Synchronisierungstabellen-APIs durchgeführt, mit der Ausnahme, dass sie aus einem lokalen Speicherlesen oder in diesen schreiben. Bevor Synchronisierungstabellenvorgänge ausgeführt werden können, muss der lokale Speicher initialisiert werden.

Was ist ein lokaler Store?

Ein lokaler Speicher ist die Datenpersistenzschicht auf dem Clientgerät. Die Azure Mobile Apps-Client-SDKs stellen eine standardmäßige lokale Speicherimplementierung bereit. Unter Windows, Xamarin und Android basiert es auf SQLite. Auf iOS basiert sie auf Core Data.

Um die SQLite-basierte Implementierung unter Windows Phone oder Microsoft Store zu verwenden, müssen Sie eine SQLite-Erweiterung installieren. Weitere Informationen finden Sie unter universelle Windows-Plattform: Aktivieren der Offlinesynchronisierung. Android und iOS werden mit einer Version von SQLite im Gerätebetriebssystem selbst ausgeliefert, daher ist es nicht erforderlich, auf Ihre eigene Version von SQLite zu verweisen.

Entwickler können auch ihren eigenen lokalen Store implementieren. Wenn Sie beispielsweise Daten in einem verschlüsselten Format auf dem mobilen Client speichern möchten, können Sie einen lokalen Speicher definieren, der SQLCipher für die Verschlüsselung verwendet.

Was ist ein Synchronisierungskontext?

Ein Synchronisierungskontext wird einem mobilen Clientobjekt (z. B. IMobileServiceClient oder MSClient) zugeordnet und Änderungen nachverfolgt, die mit Synchronisierungstabellen vorgenommen werden. Der Synchronisierungskontext verwaltet eine Vorgangswarteschlange, die eine sortierte Liste der CUD-Vorgänge (Erstellen, Aktualisieren, Löschen) speichert, die später an den Server gesendet wird.

Ein lokaler Speicher wird dem Synchronisierungskontext mithilfe einer Initialisierungsmethode wie IMobileServicesSyncContext.InitializeAsync(localstore) im .NET Client SDK-zugeordnet.

Funktionsweise der Offlinesynchronisierung

Bei Verwendung von Synchronisierungstabellen steuert Ihr Clientcode, wenn lokale Änderungen mit einem Azure Mobile App-Back-End synchronisiert werden. Nichts wird an das Back-End gesendet, bis ein Aufruf von zum Pushen von lokalen Änderungen erfolgt. Ebenso wird der lokale Speicher nur dann mit neuen Daten aufgefüllt, wenn ein Aufruf Pull- Daten vorhanden ist.

Push-: Push ist eine Operation im Synchronisierungskontext, und sendet alle CUD-Änderungen seit dem letzten Push. Beachten Sie, dass es nicht möglich ist, nur die Änderungen einer einzelnen Tabelle zu senden, da andernfalls Vorgänge außerhalb der Reihenfolge gesendet werden können. Push führt eine Reihe von REST-Aufrufen an Ihr Azure Mobile App-Back-End aus, wodurch wiederum Die Serverdatenbank geändert wird.
Pull-: Pull wird pro Tabelle ausgeführt und kann mit einer Abfrage angepasst werden, um nur eine Teilmenge der Serverdaten abzurufen. Die Azure Mobile-Client-SDKs fügen dann die resultierenden Daten in den lokalen Speicher ein.
implizite Pushs: Wenn ein Pull für eine Tabelle mit ausstehenden lokalen Updates ausgeführt wird, führt der Pull zuerst eine push() im Synchronisierungskontext aus. Dieser Push hilft dabei, Konflikte zwischen Änderungen zu minimieren, die bereits in die Warteschlange gestellt wurden, und neue Daten vom Server.
Inkrementelle Synchronisierung: Der erste Parameter für den Pullvorgang ist ein Abfragename, der nur auf dem Client verwendet wird. Wenn Sie einen Nicht-NULL-Abfragenamen verwenden, führt das Azure Mobile SDK eine inkrementelle Synchronisierungaus. Jedes Mal, wenn ein Pullvorgang eine Reihe von Ergebnissen zurückgibt, wird der neueste updatedAt Zeitstempel aus diesem Resultset in den lokalen SDK-Systemtabellen gespeichert. Nachfolgende Pullvorgänge rufen nur Datensätze nach diesem Zeitstempel ab.

Um die inkrementelle Synchronisierung zu verwenden, muss Ihr Server aussagekräftige updatedAt Werte zurückgeben und auch die Sortierung nach diesem Feld unterstützen. Da das SDK jedoch eine eigene Sortierung für das feld "updatedAt" hinzufügt, können Sie keine Pullabfrage verwenden, die über eine eigene orderBy-Klausel verfügt.

Der Abfragename kann eine beliebige Zeichenfolge sein, die Sie auswählen, muss jedoch für jede logische Abfrage in Ihrer App eindeutig sein. Andernfalls könnten unterschiedliche Pullvorgänge den gleichen inkrementellen Synchronisierungszeitstempel überschreiben, und Ihre Abfragen können falsche Ergebnisse zurückgeben.

Wenn die Abfrage über einen Parameter verfügt, besteht eine Möglichkeit zum Erstellen eines eindeutigen Abfragenamens darin, den Parameterwert zu integrieren. Wenn Sie z. B. nach "userid" filtern, kann ihr Abfragename wie folgt (in C#) sein:
```
  await todoTable.PullAsync("todoItems" + userid,
      syncTable.Where(u => u.UserId == userid));
```
Wenn Sie die inkrementelle Synchronisierung deaktivieren möchten, übergeben Sie null als Abfrage-ID. In diesem Fall werden alle Datensätze bei jedem Aufruf von PullAsyncabgerufen, was potenziell ineffizient ist.
Löschen: Sie können den Inhalt des lokalen Speichers mithilfe von IMobileServiceSyncTable.PurgeAsynclöschen. Das Löschen kann erforderlich sein, wenn Sie veraltete Daten in der Clientdatenbank haben oder alle ausstehenden Änderungen verwerfen möchten.

Eine Bereinigung löscht eine Tabelle aus dem lokalen Speicher. Wenn es Vorgänge gibt, die auf die Synchronisierung mit der Serverdatenbank warten, löst die Bereinigung eine Ausnahme aus. Dies geschieht jedoch nicht, wenn der Parameter erzwungene Bereinigung gesetzt wird.

Als Beispiel für veraltete Daten auf dem Client, angenommen, im Beispiel "Todo-Liste" ruft Device1 nur Elemente ab, die nicht abgeschlossen sind. Ein To-do-Element "Milch kaufen" wird von einem anderen Gerät auf dem Server als abgeschlossen markiert. Device1 verfügt jedoch weiterhin über das Todoitem "Milch kaufen" im lokalen Store, da nur Elemente abgerufen werden, die nicht als erledigt gekennzeichnet sind. Durch eine Bereinigung wird dieses veraltete Element gelöscht.

Freigeben über