Synchronizowanie danych w trybie offline w usłudze Azure Mobile Apps

Artykuł
10/30/2016

Co to jest synchronizacja danych w trybie offline?

Synchronizacja danych w trybie offline to funkcja zestawu SDK klienta i serwera usługi Azure Mobile Apps, która ułatwia deweloperom tworzenie aplikacji, które działają bez połączenia sieciowego.

Gdy aplikacja jest w trybie offline, można nadal tworzyć i modyfikować dane, które są zapisywane w magazynie lokalnym. Gdy aplikacja wróci do trybu online, może synchronizować zmiany lokalne z zaplecza aplikacji mobilnej platformy Azure. Ta funkcja obejmuje również obsługę wykrywania konfliktów, gdy ten sam rekord zostanie zmieniony zarówno na kliencie, jak i w za wewnętrznej bazy danych. Konflikty mogą być następnie obsługiwane na serwerze lub na kliencie.

Synchronizacja w trybie offline ma kilka zalet:

Poprawianie czasu odpowiedzi aplikacji przez buforowanie danych serwera lokalnie na urządzeniu
Tworzenie niezawodnych aplikacji, które pozostają przydatne w przypadku problemów z siecią
Zezwalaj użytkownikom na tworzenie i modyfikowanie danych nawet wtedy, gdy nie ma dostępu do sieci, obsługując scenariusze z małą łącznością lub bez łączności
Synchronizowanie danych między wieloma urządzeniami i wykrywanie konfliktów w przypadku zmodyfikowania tego samego rekordu przez dwa urządzenia
Ograniczanie użycia sieci w sieciach z dużym opóźnieniem lub sieciach mierzonych

Następujące samouczki pokazują, jak dodać synchronizację w trybie offline do klientów mobilnych przy użyciu usługi Azure Mobile Apps:

Co to jest tabela synchronizacji?

Aby uzyskać dostęp do punktu końcowego "/tables", zestawy SDK klienta usługi Azure Mobile IMobileServiceTable zapewniają interfejsy, takie jak (zestaw SDK klienta platformy .NET) MSTable lub (klient systemu iOS). Te interfejsy API łączą się bezpośrednio z zaplecza aplikacji mobilnej platformy Azure i nie powiodą się, jeśli urządzenie klienckie nie ma połączenia sieciowego.

Aby obsługiwać użycie w trybie offline, aplikacja powinna zamiast tego używać interfejsów API tabeli synchronizacji, IMobileServiceSyncTable takich jak (zestaw SDK klienta platformy .NET) MSSyncTable lub (klient systemu iOS). Wszystkie te same operacje CRUD (tworzenie, odczyt, aktualizacja, usuwanie) działają z interfejsami API tabel synchronizacji, z wyjątkiem tego, że teraz odczytują dane z magazynu lokalnego lub zapisują je w magazynie lokalnym. Przed rozpoczęciem jakichkolwiek operacji tabeli synchronizacji należy zainicjować magazyn lokalny.

Co to jest magazyn lokalny?

Magazyn lokalny to warstwa trwałości danych na urządzeniu klienckim. Zestawy SDK Mobile Apps Azure zapewniają domyślną implementację magazynu lokalnego. Na Windows, Xamarin i Android jest on oparty na sqlite. W systemie iOS jest on oparty na danych podstawowych.

Aby użyć implementacji opartej na sqlite na Windows Phone lub Microsoft Store, należy zainstalować rozszerzenie SQLite. Aby uzyskać więcej informacji, zobacz platforma uniwersalna systemu Windows: Włączanie synchronizacji w trybie offline. Systemy Android i iOS są wraz z wersją sqlite w samym systemie operacyjnym urządzenia, więc nie trzeba odwoływać się do własnej wersji sqlite.

Deweloperzy mogą również zaimplementować własny sklep lokalny. Jeśli na przykład chcesz przechowywać dane w zaszyfrowanym formacie na kliencie mobilnym, możesz zdefiniować magazyn lokalny, który używa szyfrowania SQLCipher.

Co to jest kontekst synchronizacji?

Kontekst synchronizacji jest skojarzony z obiektem klienta mobilnego ( IMobileServiceClient takim jak lub MSClient) i śledzi zmiany wprowadzone za pomocą tabel synchronizacji. Kontekst synchronizacji utrzymuje kolejkę operacji, która przechowuje uporządkowaną listę operacji CUD (Tworzenie, Aktualizacja, Usuwanie), która jest później wysyłana do serwera.

Magazyn lokalny jest skojarzony z kontekstem synchronizacji przy użyciu metody inicjowania, takiej jak IMobileServicesSyncContext.InitializeAsync(localstore) zestaw SDK klienta platformy .NET.

Jak działa synchronizacja w trybie offline

W przypadku korzystania z tabel synchronizacji kod klienta kontroluje, kiedy zmiany lokalne są synchronizowane z zapleczami aplikacji mobilnej platformy Azure. Nic nie jest wysyłane do zaplecza do momentu wywołania wypychania zmian lokalnych. Podobnie magazyn lokalny jest wypełniany nowymi danymi tylko wtedy, gdy istnieje wywołanie do ściągania danych.

Wypychanie: wypychanie jest operacją w kontekście synchronizacji i wysyła wszystkie zmiany cudzysłowy od czasu ostatniego wypchania. Należy pamiętać, że nie można wysyłać tylko zmian w poszczególnych tabelach, ponieważ w przeciwnym razie operacje mogą być wysyłane poza kolejnością. Wypychanie wykonuje serię wywołań REST do zaplecza aplikacji mobilnej platformy Azure, co z kolei modyfikuje bazę danych serwera.
Ściąganie: Ściąganie jest wykonywane na podstawie tabeli i można je dostosować za pomocą zapytania w celu pobrania tylko podzestawu danych serwera. Zestawy SDK klienta usługi Azure Mobile wstawiają wynikowe dane do magazynu lokalnego.
Niejawne wypchnięcia: jeśli ściąganie jest wykonywane względem tabeli, która ma oczekujące aktualizacje lokalne, ściąganie najpierw wykonuje polecenie w kontekście push() synchronizacji. To wypychanie pomaga zminimalizować konflikty między zmianami, które są już w kolejce, a nowymi danymi z serwera.
Synchronizacja przyrostowa: pierwszym parametrem operacji ściągania jest nazwa zapytania , która jest używana tylko na kliencie. Jeśli używasz nazwy zapytania o wartości innych niż null, zestaw Azure Mobile SDK wykonuje synchronizację przyrostową. Za każdym razem, gdy operacja ściągania zwraca zestaw wyników, updatedAt najnowszy znacznik czasu z tego zestawu wyników jest przechowywany w lokalnych tabelach systemowych zestawu SDK. Kolejne operacje ściągania pobierają tylko rekordy po tym znaczniku czasu.

Aby korzystać z synchronizacji przyrostowej, serwer musi zwracać znaczące updatedAt wartości i musi również obsługiwać sortowanie według tego pola. Jednak ponieważ zestaw SDK dodaje własne sortowanie do pola updatedAt, nie można użyć zapytania ściągniętego, które ma własną klauzulę orderBy .

Nazwa zapytania może być dowolnym ciągiem, który wybierzesz, ale musi być unikatowa dla każdego zapytania logicznego w aplikacji. W przeciwnym razie różne operacje ściągania mogą zastąpić ten sam znacznik czasu synchronizacji przyrostowej, a zapytania mogą zwracać nieprawidłowe wyniki.

Jeśli zapytanie ma parametr, jednym ze sposobów utworzenia unikatowej nazwy zapytania jest uwzględnienie wartości parametru. Jeśli na przykład filtrowany jest identyfikator użytkownika, nazwa zapytania może być następująca (w języku C#):
```
  await todoTable.PullAsync("todoItems" + userid,
      syncTable.Where(u => u.UserId == userid));
```
Jeśli chcesz zrezygnować z synchronizacji przyrostowej, przekaż null jako identyfikator zapytania. W takim przypadku wszystkie rekordy są pobierane przy każdym wywołaniu PullAsyncdo , co jest potencjalnie nieefektywne.
Przeczyszczanie: zawartość magazynu lokalnego można wyczyścić przy użyciu funkcji IMobileServiceSyncTable.PurgeAsync. Przeczyszczanie może być konieczne, jeśli w bazie danych klienta są nieaktualne dane lub jeśli chcesz odrzucić wszystkie oczekujące zmiany.

Przeczyszczanie czyści tabelę z magazynu lokalnego. Jeśli istnieją operacje oczekujące na synchronizację z bazą danych serwera, przeczyszczanie zgłasza wyjątek, chyba że ustawiono parametr wymuszania przeczyszczania.

Jako przykład nieaktualnych danych na kliencie załóżmy, że w przykładzie "lista zadań do zadania" urządzenie Device1 ściąga tylko te elementy, które nie zostały ukończone. Todoitem "Kup teraz" jest oznaczany na serwerze przez inne urządzenie. Jednak urządzenie Device1 nadal ma todoitem "Kup teraz" w magazynie lokalnym, ponieważ ściąga tylko te elementy, które nie są oznaczone jako zakończone. Przeczyszczanie czyści ten nieaktywnego elementu.