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-backend. Funktionen innehåller också stöd för att identifiera konflikter när samma post ändras på både klienten och backend-datorn. Konflikter kan sedan hanteras antingen på servern eller på 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 om det inte finns någon nätverksåtkomst, stödscenarier 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ändning i nätverk med hög latens 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 komma åt slutpunkten "/tables" tillhandahåller Azure Mobile-klient-SDK IMobileServiceTable :er gränssnitt som (.NET-klient-SDK) eller MSTable (iOS-klient). Dessa API:er ansluter direkt till Azure Mobile App-backend och misslyckas om klientenhet inte har någon nätverksanslutning.

För att stödja användning offline bör din app i stället använda synkroniseringstabell-API : erna, IMobileServiceSyncTable till exempel (.NET-klient-SDK) eller MSSyncTable (iOS-klient). Alla 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 du kan utföra några synkroniseringstabellåtgärder måste det lokala arkivet initieras.

Vad är ett lokalt arkiv?

Ett lokalt arkiv är datapersistenceskiktet på klientenheterna. Azure Mobile Apps-KLIENT-SDK:er tillhandahåller en standardimplementering för lokalt arkiv. På Windows, Xamarin och Android baseras den på SQLite. I iOS baseras den på Core Data.

Om du vill använda den SQLite-baserade implementeringen 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 enhetens operativsystem, så det är inte nödvändigt att referera till din egen version av SQLite.

Utvecklare kan också implementera egna lokala arkiv. Om du till exempel vill lagra data i ett krypterat format på den mobila klienten 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 IMobileServiceClient exempel eller MSClient) och spårar ändringar som görs med synkroniseringstabeller. Synkroniseringskontexten upprätthå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 associeras med synkroniseringskontexten med hjälp av en initiera-metod, 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-backend. Inget skickas till backend-bladet förrän det finns ett anrop för att push-överför lokala ändringar. På samma sätt fylls det lokala arkivet bara med nya data när det finns ett anrop för att hämta data.

  • Push: Push är en åtgärd i synkroniseringskontexten och skickar alla CUD-ändringar sedan den senaste push-åtgärden. Observera att det inte går att skicka bara en enskild tabells ändringar, eftersom åtgärder annars kan skickas i oordning. Push kör en serie REST-anrop till serverdelsappen i Azure Mobile, som i sin tur ändrar serverdatabasen.

  • Hämtning: Hämtning 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 resulterande data i det lokala arkivet.

  • Implicita push-meddelanden: Om en pull körs mot en tabell som har väntande lokala uppdateringar, kör pull först en i push() synkroniseringskontexten. Den här push-funktionen 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 i pull-åtgärden är ett frågenamn som endast används på klienten. Om du använder ett icke-null-frågenamn utför Azure Mobile SDK en inkrementell synkronisering. Varje gång en pull-åtgärd returnerar en uppsättning resultat lagras updatedAt den senaste tidsstämpeln från resultatuppsättningen i de lokala SDK-systemtabellerna. Efterföljande hämtningsåtgärder hämtar endast poster efter den 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 med det här fältet. Men eftersom SDK:n 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 avanmäla 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 vara ineffektivt.

  • Rensning: Du kan rensa innehållet i det lokala arkivet med hjälp av IMobileServiceSyncTable.PurgeAsync. Rensning kan vara nödvändigt om du har inaktuella data i klientdatabasen eller om du vill ta bort alla väntande ändringar.

    En rensning rensar en tabell från det lokala arkivet. Om det finns åtgärder som väntar på synkronisering med serverdatabasen kastar rensningen ett undantag om inte parametern force purge har angetts.

    Som ett exempel på inaktuella data på klienten antar vi i exemplet "att göra-lista" att Device1 endast hämtar objekt som inte har slutförts. En todoitem "Köp köp"-fil markeras som slutförd på servern av en annan enhet. Device1 har dock fortfarande todoitem-bladet "Köp" i det lokala arkivet eftersom det bara är att hämta objekt som inte har markerats som slutförda. En rensning rensar det inaktuella objektet.

Nästa steg