Megosztás a következőn keresztül:

Kapcsolat nélküli adatszinkronizálás az Azure Mobile Apps megoldásban

  • Cikk

Mi az offline adatszinkronizálás?

Az offline adatszinkronizálás az Azure Mobile Apps ügyfél- és kiszolgáló SDK-szolgáltatása, amely megkönnyíti a fejlesztők számára a hálózati kapcsolat nélkül működő alkalmazások létrehozását.

Ha az alkalmazás offline módban van, továbbra is létrehozhat és módosíthat adatokat, amelyeket a rendszer egy helyi tárolóba ment. Amikor az alkalmazás újra online állapotba áll, képes szinkronizálni a helyi módosításokat az Azure Mobile App háttéralkalmazásával. A szolgáltatás emellett támogatja az ütközések észlelését is, ha ugyanazt a rekordot az ügyfélen és a háttéren is megváltoztatják. Az ütközések ezután a kiszolgálón vagy az ügyfélen is kezelhetők.

Az offline szinkronizálásnak számos előnye van:

  • Az alkalmazás válaszképességének javítása a kiszolgálóadatok helyi gyorsítótárazása az eszközön
  • Robusztus alkalmazások létrehozása, amelyek hálózati problémák esetén is hasznosak maradnak
  • Lehetővé teszi, hogy a végfelhasználók hálózati hozzáférés nélkül is hozzanak létre és módosítsák az adatokat, és csak kevés kapcsolattal vagy kapcsolat nélkül tudjanak adatokat létrehozni.
  • Adatok szinkronizálása több eszközön, és ütközések észlelése, ha ugyanazt a rekordot két eszköz módosítja
  • A hálózathasználat korlátozása nagy késésű vagy forgalmi díjas hálózatokon

Az alábbi oktatóanyagok azt mutatják be, hogyan adhat offline szinkronizálást mobil ügyfeleihez az Azure Mobile Apps:

Mi az a szinkronizálási tábla?

A "/tables" végpont eléréséhez az Azure Mobile IMobileServiceTable ügyféloldali SDK-k olyan felületeket biztosítanak, mint a (.NET ügyféloldali SDK) vagy MSTable az (iOS-ügyfél). Ezek az API-k közvetlenül az Azure Mobile App háttéralkalmazásához csatlakoznak, és meghiúsulnak, ha az ügyféleszköz nem rendelkezik hálózati kapcsolattal.

Az offline használat támogatásához az alkalmazásnak ehelyett a szinkronizálási táblázat API-ját kell használnia, IMobileServiceSyncTable például a (.NET ügyféloldali SDK) MSSyncTable vagy az (iOS-ügyfél) API-kat. Ugyanezek a CRUD-műveletek (Létrehozás, Olvasás, Frissítés, Törlés) működnek a szinkronizálási tábla API-ján, kivéve, ha most egy helyi tárolóból olvasnak vagy írnak. A szinkronizálási tábla műveleteinek végrehajtásához inicializálni kell a helyi tárolót.

Mi az a helyi áruház?

A helyi tároló az adatmegőrzési réteg az ügyféleszközön. Az Azure Mobile Apps ügyféloldali SDK-k alapértelmezett helyi tároló-implementációt biztosítanak. A Windows, A Xamarin és az Android az SQLite-on alapul. Az iOS-hez alapadatokon alapul.

Ha az SQLite-alapú implementációt Windows Phone-telefon vagy Microsoft Store, telepítenie kell egy SQLite bővítményt. További információ: Univerzális Windows-platform offline szinkronizálás engedélyezése. Az Android és az iOS az SQLite egy verzióját használja magában az eszköz operációs rendszerében, ezért nem szükséges hivatkozni az SQLite saját verziójára.

A fejlesztők saját helyi áruházat is megvalósíthatnak. Ha például titkosított formában szeretné tárolni az adatokat a mobil ügyfélen, meghatározhat egy helyi tárolót, amely az SQLCipher titkosítást használja.

Mi az a szinkronizálási környezet?

A szinkronizálási környezet egy mobil ügyfélobjektumhoz (IMobileServiceClientMSClientpéldául vagy ) van társítva, és nyomon követi a szinkronizálási táblákkal végrehajtott módosításokat. A szinkronizálási környezet fenntart egy műveleti várólistát , amely a CUD-műveletek (létrehozás, frissítés, törlés) rendezett listáját tartja meg, amelyet később elküld a kiszolgálónak.

A szinkronizálási környezethez helyi tároló van társítva egy inicializálási módszerrel, például IMobileServicesSyncContext.InitializeAsync(localstore) a .NET ügyfél-SDK-ban.

Az offline szinkronizálás működése

Szinkronizálási táblák használata esetén az ügyfélkód szabályozza, hogy mikor szinkronizálja a rendszer a helyi módosításokat egy Azure Mobile App-háttéralkalmazással. A rendszer semmit nem küld a háttérnek, amíg nincs hívás a helyi módosítások leküldésre . Hasonlóképpen, a helyi tároló csak akkor lesz feltöltve új adatokkal, ha az adatok lehívására vonatkozó hívás történik.

  • Leküldés: A leküldés a szinkronizálási környezet egyik művelete, amely az utolsó leküldés óta végrehajtott összes CUD-módosítást elküldi. Vegye figyelembe, hogy nem lehet csak az egyes tábla módosításait elküldeni, mert ellenkező esetben a műveletek sorrendből küldve lesznek. A Push rest-hívásokat hajt végre az Azure Mobile App háttéralkalmazásához, ami pedig módosítja a kiszolgálói adatbázist.

  • Lekérés: A lekérés táblázatonként történik, és egy lekérdezéssel testre szabható, hogy csak a kiszolgáló adatainak egy részkészletét olvassa be. Az Azure Mobile-ügyféloldali ADATTK-k ezután beszúrják az eredményül kapott adatokat a helyi tárolóba.

  • Implicit leküldések: Ha olyan táblán hajt végre leküldést, amely helyi frissítésekre vár, a leküldés először végrehajt egy kódot a push() szinkronizálási környezetben. Ez a leküldés segít minimalizálni a már várólistán lévő módosítások és a kiszolgálóról származó új adatok közötti ütközéseket.

  • Növekményes szinkronizálás : a lekérdező művelet első paramétere egy olyan lekérdezésnév, amely csak az ügyfélen használatos. Ha nem null lekérdezésnevet használ, az Azure Mobile SDK növekményes szinkronizálást hajt végre. Minden alkalommal, amikor egy lekért művelet egy eredménykészletet ad vissza, updatedAt az eredményhalmaz legfrissebb időbélyege az SDK helyi rendszertábláiban lesz tárolva. A későbbi lekérési műveletek csak az időbélyegzőt követő rekordokat lekérik.

    A növekményes szinkronizáláshoz a kiszolgálónak updatedAt értelmes értékeket kell visszaadni, és támogatnia kell a mező alapján való rendezést is. Mivel azonban az SDK saját rendezést ad hozzá a updatedAt mezőhöz, nem használhat olyan lekérdező lekérdezést, amely saját záradékkal orderBy rendelkezik.

    A lekérdezés neve bármilyen sztring lehet, de az alkalmazás minden logikai lekérdezéséhez egyedinek kell lennie. Ellenkező esetben a különböző lekérdező műveletek felülírják ugyanazt a növekményes szinkronizálási időbélyeget, és a lekérdezések helytelen eredményeket kaphatnak.

    Ha a lekérdezés rendelkezik paraméterrel, az egyedi lekérdezésnév létrehozásának egyik módja a paraméterérték belefoglalása. Ha például a userid azonosítóra szűr, a lekérdezés neve a következő lehet (C#-ban):

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

    Ha le szeretné mondani a növekményes szinkronizálást, adja meg null a lekérdezés azonosítóját. Ebben az esetben a lekérdezése az összes rekordot a minden hívása PullAsyncesetén lekéri, ami potenciálisan nem hatékony.

  • Kiürítés: A helyi tároló tartalmát a használatával ürítheti ki IMobileServiceSyncTable.PurgeAsync. Kiürítésre akkor lehet szükség, ha elavult adatok vannak az ügyféladatbázisban, vagy ha el szeretné vetni az összes függőben lévő módosítást.

    A véglegesen töröl egy táblát a helyi tárolóból. Ha műveletek várnak a kiszolgálóadatbázissal való szinkronizálásra, a véglegesen kiürítés kivételt ad vissza, kivéve, ha a kényszerített kiürítés paraméter be van állítva.

    Az ügyfél elavult adatainak példájaként tegyük fel, hogy a "todo list" (feladatlista) példában a Device1 csak a nem befejezett elemeket húzza le. A todoitem "Buy todoitem " buy todoitem "Buy todoitem" (Egy másik eszköz vásárolja meg) befejezettként van megjelölve a kiszolgálón. A Device1 eszköz azonban továbbra is rendelkezik a "Buy todoitem" todoitem elemet a helyi áruházban, mivel csak a nem befejezettként megjelölt elemeket húzza le. A véglegesen törölve lett ez az elavult elem.

Következő lépések