Offlinesynchronisatie van gegevens in Azure Mobile Apps

Artikel
10/30/2016

Wat is offline gegevenssynchronisatie?

Offline gegevenssynchronisatie is een client- en server-SDK-functie van Azure Mobile Apps waarmee ontwikkelaars eenvoudig apps kunnen maken die functioneel zijn zonder netwerkverbinding.

Wanneer uw app in de offlinemodus is, kunt u nog steeds gegevens maken en wijzigen, die worden opgeslagen in een lokale store. Wanneer de app weer online is, kan deze lokale wijzigingen synchroniseren met de back-end van uw mobiele Azure-app. De functie biedt ook ondersteuning voor het detecteren van conflicten wanneer dezelfde record wordt gewijzigd op zowel de client als de back-end. Conflicten kunnen vervolgens worden afgehandeld op de server of op de client.

Offlinesynchronisatie heeft verschillende voordelen:

De reactiesnelheid van de app verbeteren door servergegevens lokaal op het apparaat op te halen
Robuuste apps maken die nuttig blijven wanneer er netwerkproblemen zijn
Eindgebruikers toestaan om gegevens te maken en te wijzigen, zelfs wanneer er geen netwerktoegang is, ondersteunende scenario's met weinig of geen connectiviteit
Gegevens synchroniseren tussen meerdere apparaten en conflicten detecteren wanneer dezelfde record door twee apparaten wordt gewijzigd
Netwerkgebruik in netwerken met hoge latentie of naar gebruik beperken

De volgende zelfstudies laten zien hoe u offline synchronisatie toevoegt aan uw mobiele clients met behulp van Azure Mobile Apps:

Wat is een synchronisatietabel?

Voor toegang tot het eindpunt /tables bieden de Azure Mobile-client-SDK's interfaces IMobileServiceTable zoals (.NET client SDK) MSTable of (iOS-client). Deze API's maken rechtstreeks verbinding met de back-end van azure Mobile App en mislukken als het clientapparaat geen netwerkverbinding heeft.

Ter ondersteuning van offlinegebruik moet uw app in plaats daarvan de synchronisatietabel-API's gebruiken, IMobileServiceSyncTable zoals (.NET client SDK) of MSSyncTable (iOS-client). Dezelfde CRUD-bewerkingen (Maken, Lezen, Bijwerken, Verwijderen) werken met synchronisatietabel-API's, behalve dat ze nu lezen uit of schrijven naar een lokaal opslag. Voordat synchronisatietabelbewerkingen kunnen worden uitgevoerd, moet het lokale opslag worden initialiseren.

Wat is een lokaal winkel?

Een lokaal opslag is de gegevens persistentielaag op het clientapparaat. De Azure Mobile Apps client-SDK's bieden een standaard implementatie van het lokale winkelbestand. Op Windows, Xamarin en Android is het gebaseerd op SQLite. In iOS is het gebaseerd op kerngegevens.

Als u de implementatie op basis van SQLite wilt gebruiken op Windows Phone of Microsoft Store, moet u een SQLite-extensie installeren. Zie voor meer informatie Universeel Windows-platform: Offlinesynchronisatie inschakelen. Android en iOS worden met een versie van SQLite in het besturingssysteem van het apparaat zelf verzenden, dus het is niet nodig om te verwijzen naar uw eigen versie van SQLite.

Ontwikkelaars kunnen ook hun eigen lokale winkel implementeren. Als u bijvoorbeeld gegevens in een versleutelde indeling wilt opslaan op de mobiele client, kunt u een lokaal opslagbestand definiëren dat SQLCipher gebruikt voor versleuteling.

Wat is een synchronisatiecontext?

Een synchronisatiecontext is gekoppeld aan een mobiel clientobject ( IMobileServiceClient zoals of MSClient) en houdt wijzigingen bij die zijn aangebracht met synchronisatietabellen. De synchronisatiecontext onderhoudt een bewerkingswachtrij, die een geordende lijst met CUD-bewerkingen (Maken, Bijwerken, Verwijderen) bijhoudt die later naar de server worden verzonden.

Een lokaal opslagbestand is gekoppeld aan de synchronisatiecontext met behulp van een initialisatiemethode, zoals IMobileServicesSyncContext.InitializeAsync(localstore) in de .NET-client-SDK.

Hoe offline synchronisatie werkt

Wanneer u synchronisatietabellen gebruikt, bepaalt uw clientcode wanneer lokale wijzigingen worden gesynchroniseerd met een back-end van een mobiele Azure-app. Er wordt niets naar de back-end verzonden totdat er een aanroep is om lokale wijzigingen te pushen. Op dezelfde manier wordt het lokale opslagopslag alleen gevuld met nieuwe gegevens wanneer er een aanroep is om gegevens op te halen.

Push: Push is een bewerking voor de synchronisatiecontext en verzendt alle CUD-wijzigingen sinds de laatste push. Houd er rekening mee dat het niet mogelijk is om alleen de wijzigingen van een afzonderlijke tabel te verzenden, omdat anders bewerkingen buiten de volgorde kunnen worden verzonden. Push voert een reeks REST-aanroepen uit naar de back-end van uw mobiele Azure-app, die op zijn beurt uw serverdatabase wijzigt.
Pull: Pull wordt per tabel uitgevoerd en kan worden aangepast met een query om alleen een subset van de servergegevens op te halen. De SDK's van de Azure Mobile-client voegen vervolgens de resulterende gegevens in het lokale opslagbestand in.
Impliciete pushes: als een pull wordt uitgevoerd voor een tabel die lokale updates in behandeling heeft, voert de pull eerst een uit push() in de synchronisatiecontext. Deze push helpt conflicten tussen wijzigingen die al in de wachtrij staan en nieuwe gegevens van de server te minimaliseren.
Incrementele synchronisatie: de eerste parameter voor de pull-bewerking is een querynaam die alleen op de client wordt gebruikt. Als u een querynaam gebruikt die niet null is, voert de Azure Mobile SDK een incrementele synchronisatie uit. Telkens als een pull-bewerking een set resultaten retourneert, updatedAt wordt de meest recente tijdstempel van die resultatenset opgeslagen in de lokale systeemtabellen van de SDK. Volgende pull-bewerkingen halen alleen records op na die tijdstempel.

Als u incrementele synchronisatie wilt gebruiken, moet uw server zinvolle waarden updatedAt retourneren en ook sorteren op dit veld ondersteunen. Omdat de SDK echter een eigen sort voor het bijgewerkteat-veld toevoegt, kunt u geen pull-query met een eigen component orderBy gebruiken.

De querynaam kan elke tekenreeks zijn die u kiest, maar deze moet uniek zijn voor elke logische query in uw app. Anders kunnen verschillende pull-bewerkingen dezelfde incrementele synchronisatietijdstempel overschrijven en kunnen uw query's onjuiste resultaten retourneren.

Als de query een parameter heeft, kunt u een unieke querynaam maken door de parameterwaarde op te nemen. Als u bijvoorbeeld filtert op userid, kan de querynaam er als volgt uit zien (in C#):
```
  await todoTable.PullAsync("todoItems" + userid,
      syncTable.Where(u => u.UserId == userid));
```
Als u wilt kiezen voor incrementele synchronisatie, geef dan door null als de query-id. In dit geval worden alle records opgehaald bij elke aanroep naar PullAsync, wat mogelijk inefficiënt is.
Leeg maken: u kunt de inhoud van het lokale winkel verwijderen met behulp van IMobileServiceSyncTable.PurgeAsync. Opsrekken kan nodig zijn als u verouderde gegevens in de clientdatabase hebt of als u alle wijzigingen in behandeling wilt verwijderen.

Met een opsting wordt een tabel uit het lokale winkel geweken. Als er bewerkingen zijn die wachten op synchronisatie met de serverdatabase, wordt er een uitzondering voor de opsmeting uitgevoerd, tenzij de parameter voor geforcering wordt ingesteld.

Als voorbeeld van verouderde gegevens op de client, stel dat in het voorbeeld 'todo list' Device1 alleen items ophaalt die niet zijn voltooid. Een todoitem 'Buy spam' wordt door een ander apparaat gemarkeerd als voltooid op de server. Device1 heeft echter nog steeds het todoitem 'Kopen' in het lokale winkel, omdat het alleen items ophaalt die niet als Voltooid zijn gemarkeerd. Met een opsting wordt dit verouderde item geweken.

Share via