Offline datasynchronisatie in Azure Mobile Apps

Artikel
10/30/2016

Wat is offline gegevenssynchronisatie?

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

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

Offlinesynchronisatie heeft verschillende voordelen:

De reactiesnelheid van apps verbeteren door servergegevens lokaal op het apparaat in de cache te plaatsen
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 op meerdere apparaten en conflicten detecteren wanneer dezelfde record wordt gewijzigd door twee apparaten
Netwerkgebruik beperken voor netwerken met hoge latentie of met datalimiet

In de volgende zelfstudies ziet u hoe u offlinesynchronisatie toevoegt aan uw mobiele clients met behulp van Azure Mobile Apps:

Wat is een synchronisatietabel?

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

Ter ondersteuning van offlinegebruik moet uw app in plaats daarvan gebruikmaken van de API's van de synchronisatietabel , zoals IMobileServiceSyncTable (.NET client SDK) of MSSyncTable (iOS-client). Alle CRUD-bewerkingen (Maken, Lezen, Bijwerken, Verwijderen) werken met synchronisatietabel-API's, behalve nu ze lezen van of schrijven naar een lokaal archief. Voordat synchronisatietabel-bewerkingen kunnen worden uitgevoerd, moet de lokale opslag worden geïnitialiseerd.

Wat is een lokale winkel?

Een lokaal archief is de laag voor gegevenspersistentie op het clientapparaat. De CLIENT-SDK's van Azure Mobile Apps bieden een standaard-implementatie voor lokale winkels. In Windows, Xamarin en Android is het gebaseerd op SQLite. In iOS is het gebaseerd op Core Data.

Als u de implementatie op basis van SQLite in Windows Phone of Microsoft Store wilt gebruiken, moet u een SQLite-extensie installeren. Zie Universeel Windows-platform voor meer informatie: Offlinesynchronisatie inschakelen. Android en iOS verzenden met een versie van SQLite in het besturingssysteem van het apparaat zelf, 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 wilt opslaan in een versleutelde indeling op de mobiele client, kunt u een lokaal archief definiëren dat gebruikmaakt van SQLCipher voor versleuteling.

Wat is een synchronisatiecontext?

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

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

Hoe offlinesynchronisatie werkt

Wanneer u synchronisatietabellen gebruikt, bepaalt uw clientcode wanneer lokale wijzigingen worden gesynchroniseerd met een back-end van azure Mobile App. Er wordt niets naar de back-end verzonden totdat er een oproep is om lokale wijzigingen te verzenden. Op dezelfde manier wordt het lokale archief alleen gevuld met nieuwe gegevens wanneer er een aanroep is om gegevens op te halen .

Push: Push is een bewerking in 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 Azure Mobile 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 de lokale opslag in.
Impliciete pushes: als een pull wordt uitgevoerd tegen een tabel met in behandeling zijnde lokale updates, voert de pull eerst een push() uit 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 niet-null-querynaam gebruikt, voert de Azure Mobile SDK een incrementele synchronisatie uit. Telkens wanneer een pull-bewerking een set resultaten retourneert, wordt de meest recente updatedAt tijdstempel uit 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 updatedAt waarden retourneren en moet het sorteren op dit veld ook ondersteunen. Omdat de SDK echter een eigen sortering toevoegt aan het bijgewerkteAt-veld, kunt u geen pull-query gebruiken die een eigen orderBy component heeft.

De querynaam kan elke tekenreeks zijn die u kiest, maar moet uniek zijn voor elke logische query in uw app. Anders kunnen verschillende pull-bewerkingen dezelfde tijdstempel voor incrementele synchronisatie 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 de gebruikers-id, kan uw querynaam er als volgt uitzien (in C#):
```
  await todoTable.PullAsync("todoItems" + userid,
      syncTable.Where(u => u.UserId == userid));
```
Als u zich wilt afmelden voor incrementele synchronisatie, gebruikt u null als de query-id. In dit geval worden alle records opgehaald bij elke aanroep naar PullAsync, wat mogelijk inefficiënt is.
Opschonen: U kunt de inhoud van de lokale opslag wissen met behulp van IMobileServiceSyncTable.PurgeAsync. Opschonen kan nodig zijn als u verouderde gegevens in de clientdatabase hebt of als u alle wijzigingen die in behandeling zijn, wilt negeren.

Een opschoning wist een tabel uit het lokale archief. Als er bewerkingen zijn die wachten op synchronisatie met de serverdatabase, genereert de opschoning een uitzondering, tenzij de parameter geforceerd opschonen is ingesteld.

Als voorbeeld van verouderde gegevens op de client, bijvoorbeeld in het voorbeeld 'takenlijst', haalt Device1 alleen items op die niet zijn voltooid. Een todoitem "Melk kopen" is voltooid gemarkeerd op de server door een ander apparaat. Device1 heeft echter nog steeds het todoitem 'Melk kopen' in de lokale winkel, omdat het alleen items ophaalt die niet zijn gemarkeerd als voltooid. Met een opschoning wordt dit verouderde item gewist.

Delen via