Offline gegevens synchroniseren

Offlinegegevenssynchronisatie is een SDK-functie van Azure Mobile Apps. Gegevens worden opgeslagen in een lokaal archief. Wanneer uw app offline is, kunt u de gegevens nog steeds maken, wijzigen en doorzoeken. Gegevens worden gesynchroniseerd met uw Azure Mobile Apps-service wanneer uw apparaat online is. De SDK ondersteunt conflictoplossing wanneer dezelfde record wordt gewijzigd op zowel de client als de service.

Offlinesynchronisatie heeft verschillende voordelen:

  • Verbetert de reactiesnelheid van apps
  • Verbetert de betrouwbaarheid van apps wanneer er een slechte netwerkverbinding is
  • Beperkt netwerkgebruik op netwerken met hoge latentie of met een datalimiet
  • Ondersteunt niet-verbonden gebruik

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

Wat is een synchronisatietabel?

De SDK's voor Azure Mobile Apps bieden IRemoteTable<T>rechtstreeks toegang tot de service. De bewerking mislukt als het apparaat geen netwerkverbinding heeft. Een synchronisatietabel (geleverd door IOfflineTable<T>) biedt dezelfde bewerkingen voor een lokaal archief. Het lokale archief kan vervolgens op een later tijdstip worden gesynchroniseerd met de service. Voordat u bewerkingen uitvoert, moet u het lokale archief initialiseren.

Wat is een lokale winkel?

Een lokaal archief is de laag voor gegevenspersistentie op het clientapparaat. De meeste platforms gebruiken SQLite voor het lokale archief, maar iOS maakt gebruik van Core Data. U kunt ook uw eigen lokale winkel implementeren. Gebruik bijvoorbeeld een versie van SQLite met SQLCipher om een versleuteld archief te produceren.

Hoe werkt offlinesynchronisatie?

De clientcode bepaalt wanneer lokale wijzigingen worden gesynchroniseerd met een gegevenssynchronisatieservice. Er wordt niets naar de service verzonden totdat u lokale wijzigingen pusht . Op dezelfde manier wordt het lokale archief alleen gevuld met nieuwe of bijgewerkte gegevens wanneer u gegevens ophaalt .

U kunt bewerkingen die in behandeling zijn pushen voor alle tabellen, een lijst met tabellen of één tabel:

// All tables
await client.PushTablesAsync();

// A list of tables
var tablesToPush = new string[] { "table1", "table2" };
await client.PushTablesAsync(tablesToPush);

// A single table
await table.PushItemsAsync();

Synchronisatie

Met de pushbewerking worden alle wijzigingen in behandeling in de bewerkingswachtrij naar de service verzonden. De wijziging die in behandeling is, wordt verzonden naar de service via een HTTP REST-aanroep, die uw database op zijn beurt wijzigt.

Pushbewerkingen worden uitgevoerd voordat pull-bewerkingen worden uitgevoerd. Met de pull-bewerking worden gewijzigde gegevens opgehaald uit de service en opgeslagen in het lokale archief.

Impliciete push

Als u een pull uitvoert voor een tabel die lokale updates in behandeling heeft, voert de pull eerst een push uit voor die tabel. Deze push helpt conflicten tussen wijzigingen die al in de wachtrij staan en nieuwe gegevens van de server te minimaliseren. U kunt desgewenst een push van alle tabellen configureren door het volgende in PullOptionste stellenPushOtherTables:

var pullOptions = new PullOptions { PushOtherTables = true };
await table.PullItemsAsync(pullOptions);

Een subset records ophalen

U kunt desgewenst een query opgeven die wordt gebruikt om te bepalen welke records moeten worden opgenomen in de offlinedatabase. Voorbeeld:

var query = table.CreateQuery().Where(x => x.Color == "Blue");
await table.PullItemsAsync(query);

Incrementele synchronisatie

Azure Mobile Apps implementeert incrementele synchronisatie. Alleen records die zijn gewijzigd sinds de laatste pull-bewerking worden opgehaald. Incrementele synchronisatie bespaart tijd en bandbreedte wanneer u grote tabellen verwerkt.

Voor elke unieke query wordt het UpdatedAt veld van de laatst overgebrachte record opgeslagen als een token in de offlinestore. De laatste UpdatedAt waarde wordt opgeslagen in het deltatokenarchief. Het deltatokenarchief wordt geïmplementeerd als een tabel in de offline store.

Prestaties en consistentie

Synchronisatie stopt soms voortijdig. Voorbeeld:

  • Het netwerk dat u voor synchronisatie gebruikt, is niet meer beschikbaar tijdens het synchronisatieproces.
  • U dwingt de toepassing af tijdens de synchronisatie.

Om het risico van een consistentieprobleem in de offlinedatabase te minimaliseren, wordt elke record naar de database geschreven terwijl deze wordt ontvangen. U kunt desgewenst besluiten om de records in batches naar de database te schrijven. Batchbewerkingen verhogen de prestaties van de offlinedatabaseschrijfbewerkingen tijdens de pull-bewerking. Ze verhogen echter ook het risico op inconsistentie tussen de metagegevens van de tabel en de gegevens in de tabel.

U kunt het interval tussen schrijfbewerkingen als volgt afstemmen:

var pullOptions = new PullOptions { WriteDeltaTokenInterval = 25 };
await table.PullItemsAsync(pullOptions);

Met deze code worden schrijfbewerkingen verzameld in batches van 25 records. Prestatietests suggereren dat prestaties tot een waarde van 25 verbeteren. Een WriteDeltaTokenInterval waarde groter dan 25 verbetert de prestaties niet aanzienlijk.

Reinigend

U kunt de inhoud van het lokale archief wissen met behulp van IOfflineTable<T>.PurgeItemsAsync. 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. Een tabel leegmaken:

await table.PurgeItemsAsync("", new PurgeOptions());

De PurgeItemsAsync() methode genereert een InvalidOperationException fout als er wijzigingen in behandeling zijn in de tabel. In dit geval kunt u afdwingen dat de opschoning plaatsvindt:

await table.PurgeItemsAsync("", new PurgeOptions { DiscardPendingOperations = true });

Opschonen is een laatste redmiddel voor het opschonen van een tabel in de offline store, omdat hiermee alle records uit de cache worden gewist en u ze opnieuw moet downloaden.