Dela via


Datasynkronisering offline i Azure Mobile Apps

Vad är datasynkronisering offline?

Datasynkronisering offline är en klient- och server-SDK-funktion i Azure Mobile Apps som gör det enkelt för utvecklare att skapa appar som fungerar utan nätverksanslutning.

När appen är i offlineläge kan du fortfarande skapa och ändra data som sparas i ett lokalt arkiv. När appen är online igen kan den synkronisera lokala ändringar med din Azure Mobile App-serverdel. Funktionen innehåller även stöd för att identifiera konflikter när samma post ändras på både klienten och serverdelen. Konflikter kan sedan hanteras antingen på servern eller klienten.

Offlinesynkronisering har flera fördelar:

  • Förbättra appens svarstider genom att cachelagra serverdata lokalt på enheten
  • Skapa robusta appar som fortfarande är användbara när det finns nätverksproblem
  • Tillåt slutanvändare att skapa och ändra data även när det inte finns någon nätverksåtkomst, vilket stöder scenarier med liten eller ingen anslutning
  • Synkronisera data över flera enheter och identifiera konflikter när samma post ändras av två enheter
  • Begränsa nätverksanvändningen i nätverk med hög svarstid eller dataförbrukning

Följande självstudier visar hur du lägger till offlinesynkronisering till dina mobila klienter med hjälp av Azure Mobile Apps:

Vad är en synkroniseringstabell?

För att få åtkomst till slutpunkten "/tables" tillhandahåller Azure Mobile-klient-SDK:erna gränssnitt som IMobileServiceTable (.NET-klient-SDK) eller MSTable (iOS-klient). Dessa API:er ansluter direkt till Azure Mobile App-serverdelen och misslyckas om klientenheten inte har någon nätverksanslutning.

För att stödja offlineanvändning bör appen i stället använda -synkroniseringstabellen API:er, till exempel IMobileServiceSyncTable (.NET-klient-SDK) eller MSSyncTable (iOS-klient). Samma CRUD-åtgärder (Skapa, Läsa, Uppdatera, Ta bort) fungerar mot API:er för synkroniseringstabeller, förutom att de nu läser från eller skriver till ett lokalt arkiv. Innan några synktabelloperationer kan utföras måste den lokala databasen initieras.

Vad är en lokal butik?

Ett lokalt lager är skiktet för datapersistence på klientenheten. Azure Mobile Apps-klient-SDK:er tillhandahåller en standardimplementering av lokala butiker. I Windows, Xamarin och Android baseras den på SQLite. På iOS baseras den på Kärndata.

Om du vill använda den SQLite-baserade implementeringen på Windows Phone eller Microsoft Store måste du installera ett SQLite-tillägg. Mer information finns i Universell Windows-plattform: Aktivera offlinesynkronisering. Android och iOS levereras med en version av SQLite i själva enhetsoperativsystemet, så det är inte nödvändigt att referera till din egen version av SQLite.

Utvecklare kan också implementera sin egen lokala butik. Om du till exempel vill lagra data i ett krypterat format på mobilklienten kan du definiera ett lokalt arkiv som använder SQLCipher för kryptering.

Vad är en synkroniseringskontext?

En synkroniseringskontext är associerad med ett mobilt klientobjekt (till exempel IMobileServiceClient eller MSClient) och spårar ändringar som görs med synkroniseringstabeller. Synkroniseringskontexten underhåller en åtgärdskö, som behåller en ordnad lista över CUD-åtgärder (Skapa, Uppdatera, Ta bort) som senare skickas till servern.

Ett lokalt arkiv är associerat med synkroniseringskontexten med hjälp av en initieringsmetod, till exempel IMobileServicesSyncContext.InitializeAsync(localstore) i .NET-klient-SDK.

Så här fungerar offlinesynkronisering

När du använder synkroniseringstabeller styr klientkoden när lokala ändringar synkroniseras med en Azure Mobile App-serverdel. Ingenting skickas till backenden förrän ett anrop görs för att pusha lokala ändringar. På samma sätt fylls det lokala arkivet endast med nya data när det finns ett anrop till hämta data.

  • Push-: Push är en åtgärd i synkroniseringskontexten och skickar alla CUD-ändringar sedan den senaste push-överföringen. Observera att det inte går att bara skicka ändringar i en enskild tabell eftersom åtgärder annars kan skickas i fel ordning. Push kör en serie REST-anrop till din Azure Mobile App-serverdel, vilket i sin tur ändrar serverdatabasen.

  • Pull: Pull utförs per tabell och kan anpassas med en fråga för att endast hämta en delmängd av serverdata. Azure Mobile-klient-SDK:erna infogar sedan de erhållna data i den lokala lagringsplatsen.

  • implicita push-: Om en pull körs mot en tabell som har väntande lokala uppdateringar kör pull först en push() i synkroniseringskontexten. Den här push-överföringen hjälper till att minimera konflikter mellan ändringar som redan finns i kö och nya data från servern.

  • Inkrementell synkronisering: den första parametern för pull-åtgärden är ett frågenamn som endast används på klienten. Om du använder ett frågenamn som inte är null utför Azure Mobile SDK en inkrementell synkronisering. Varje gång en pull-åtgärd returnerar en uppsättning resultat lagras den senaste updatedAt tidsstämpeln från den resultatuppsättningen i de lokala SDK-systemtabellerna. Efterföljande pull-åtgärder hämtar endast poster efter tidsstämpeln.

    Om du vill använda inkrementell synkronisering måste servern returnera meningsfulla updatedAt värden och måste också ha stöd för sortering efter det här fältet. Men eftersom SDK lägger till sin egen sortering i fältet updatedAt kan du inte använda en pull-fråga som har en egen orderBy-sats.

    Frågenamnet kan vara vilken sträng du vill, men det måste vara unikt för varje logisk fråga i din app. Annars kan olika pull-åtgärder skriva över samma inkrementella synkroniseringstidsstämpel och dina frågor kan returnera felaktiga resultat.

    Om frågan har en parameter är ett sätt att skapa ett unikt frågenamn att införliva parametervärdet. Om du till exempel filtrerar på userid kan frågenamnet vara följande (i C#):

      await todoTable.PullAsync("todoItems" + userid,
          syncTable.Where(u => u.UserId == userid));
    

    Om du vill avregistrera dig från inkrementell synkronisering skickar du null som fråge-ID. I det här fallet hämtas alla poster vid varje anrop till PullAsync, vilket kan potentiellt vara ineffektivt.

  • Rensa: Du kan rensa innehållet i den lokala lagringen med IMobileServiceSyncTable.PurgeAsync. Rensning kan vara nödvändigt om du har inaktuella data i klientdatabasen eller om du vill ignorera alla väntande ändringar.

    En utrensning tar bort en tabell från det lokala lagret. Om det finns åtgärder som väntar på synkronisering med serverdatabasen kastar rensningen ett undantag, såvida inte parametern framtvinga rensning är inställd.

    Som ett exempel på inaktuella data på klienten antar vi i exemplet "att göra-listan" att Device1 bara hämtar objekt som inte har slutförts. En todoitem "Köp mjölk" markeras som slutförd på servern av en annan enhet. Device1 har dock fortfarande att göra-objektet "Köp mjölk" i lokal lagring eftersom den bara hämtar objekt som inte är markerade som slutförda. En utrensning tar bort det här gamla objektet.

Nästa steg