Автономная синхронизация данных в мобильных приложениях Azure

Статья
10/30/2016

Что такое автономная синхронизация данных?

Автономная синхронизация данных — это функция клиентского и серверного пакета SDK для мобильных приложений Azure, которая упрощает разработчикам создание приложений, предназначенных для работы без подключения к сети.

Когда приложение находится в автономном режиме, вы по-прежнему можете создавать и изменять данные, которые будут сохранены в локальном хранилище. Когда приложение вернется в сеть, оно сможет синхронизировать локальные изменения с серверной частью мобильного приложения Azure. Эта функция также поддерживает обнаружение конфликтов при изменении одной и той же записи на клиенте и сервере. Такие конфликты могут быть обработаны на сервере или клиенте.

Автономная синхронизация имеет несколько преимуществ.

Повышение скорости реагирования приложений путем локального кэширования данных сервера в устройстве
Создание надежных приложений, которые остаются полезными при проблемах с сетью.
Предоставление пользователям возможности создания и изменения данных даже в том случае, когда отсутствует сетевой доступ, поддерживая сценарии с минимальной связностью или при отсутствии связности.
Синхронизация данных между несколькими устройствами и обнаружение конфликтов, когда два устройства изменяют одну и ту же запись
Ограничение использования сетей с высокой задержкой или лимитным тарифным планом.

В следующих учебниках показано, как добавить автономную синхронизацию в мобильные клиенты с помощью мобильных приложений Azure:

Что такое таблица синхронизации?

Для доступа к конечной точке /tables клиентские пакеты SDK для мобильных приложений Azure предоставляют интерфейсы, такие как IMobileServiceTable (пакет SDK для клиента .NET) или MSTable (клиент iOS). Эти API подключаются непосредственно к серверной части мобильного приложения Azure и выдают ошибку, если у клиентского устройства нет сетевого подключения.

Для поддержки автономной работы в приложении следует использовать интерфейсы API таблицы синхронизации, такие как IMobileServiceSyncTable (пакет SDK для клиента .NET) или MSSyncTable (клиент iOS). Все те же операции CRUD (Create, Read, Update, Delete — создание, чтение, обновление и удаление) работают с API таблицы синхронизации, за исключением того, что теперь чтение и запись осуществляются в локальном хранилище. Прежде чем можно будет выполнить операции с таблицей синхронизации, необходимо инициализировать локальное хранилище.

Что такое локальное хранилище?

Локальное хранилище — это уровень сохраняемости данных на клиентском устройстве. Клиентские пакеты SDK для мобильных приложений Azure предоставляют реализацию локального хранилища по умолчанию. В Windows, Xamarin и Android она основана на SQLite. В IOS реализация основана на Core Data.

Чтобы использовать реализацию на основе SQLite для Windows Phone или Microsoft Store, необходимо установить расширение SQLite. дополнительные сведения см. в разделе универсальная платформа Windows: включение автономной синхронизации. Android и iOS поставляются с версией SQLite в самой операционной системе устройства, поэтому нет необходимости ссылаться на собственную версию SQLite.

Разработчики также могут реализовать собственное локальное хранилище. Например, если вы хотите хранить данные в зашифрованном виде в мобильном клиенте, можно определить локальное хранилище, которое для шифрования использует SQLCipher.

Что такое контекст синхронизации?

Контекст синхронизации связан с объектом мобильного клиента (таким как IMobileServiceClient или MSClient) и отслеживает изменения, внесенные с помощью таблиц синхронизации. Контекст синхронизации обеспечивает очередь операций, содержащую упорядоченный список операций CUD (Create, Update, Delete — создание, обновление, удаление), который позднее будет отправлен на сервер.

Локальное хранилище связывается с контекстом синхронизации с помощью метода Initialize, например IMobileServicesSyncContext.InitializeAsync(localstore) в КЛИЕНТСКОМ пакете SDK для .NET.

Как работает автономная синхронизация

При использовании таблиц синхронизации код клиента определяет, когда локальные изменения будут синхронизированы с серверной частью мобильного приложения Azure. Ничего не отправляется в серверную часть, пока не осуществляется вызов отправки локальных изменений. Аналогично, локальное хранилище заполняется новыми данными только в том случае, если осуществляется вызов извлечения .

Отправка: представляет собой операцию в контексте синхронизации и передает все изменения, внесенные операциями CUD с момента последней отправки. Обратите внимание, что нельзя передать только изменения в отдельной таблице, так как в противном случае операции могут быть отправлены не по порядку. Операция отправки выполняет серию вызовов REST к серверной части мобильного приложения Azure, которая, в свою очередь, изменяет сервер базы данных.
Извлечение: выполняется отдельно для каждой таблицы и может настраиваться с помощью запроса для получения подмножества данных сервера. Клиентские пакеты SDK для мобильных приложений Azure вставляют результирующие данные в локальное хранилище.
Неявные отправки: если для таблицы с ожидающими локальными обновлениями выполняется извлечение, то сначала будет выполнена операция push() в контексте синхронизации. Это позволяет свести к минимуму конфликты между изменениями, которые уже поставлены в очередь, и новыми данными с сервера.
Добавочная синхронизация: первый параметр операции извлечения — имя запроса , которое используется только на стороне клиента. При использовании имени запроса, отличного от NULL, пакет SDK для мобильных приложений Azure выполняет добавочную синхронизацию. Каждый раз, когда операция извлечения возвращает набор результатов, последняя updatedAt Метка времени из этого результирующего набора сохраняется в локальных системных таблицах SDK. Последующие операции извлечения будут получать только записи после этой метки времени.

Для использования добавочной синхронизации ваш сервер должен возвращать осмысленные значения updatedAt, а также поддерживать сортировку по этому полю. Но так как пакет SDK добавляет собственную сортировку по полю updatedAt, нельзя использовать запрос на извлечение, в котором есть собственное предложение orderBy .

Именем запроса может быть любая строка на ваш выбор, но оно должно быть уникальным для каждого логического запроса в приложении. В противном случае разные операции извлечения могут перезаписать одну и ту же метку времени добавочной синхронизации, и запросы могут возвращать неправильные результаты.

Если в запросе есть параметр, один из способов создать уникальное имя запроса — включить в него значение параметра. Например, при фильтрации по userid имя запроса может быть следующим (в C#):
```
  await todoTable.PullAsync("todoItems" + userid,
      syncTable.Where(u => u.UserId == userid));
```
Если вы хотите явно отказаться от добавочной синхронизации, передайте null в качестве идентификатора запроса. В этом случае при каждом вызове PullAsync извлекаются все записи, что может снижать уровень производительности.
Очистка: можно очистить локальное хранилище с помощью IMobileServiceSyncTable.PurgeAsync. Это может потребоваться, если в базе данных клиента есть устаревшие данные или вы хотите отменить все ожидающие изменения.

Данная операция очищает таблицу в локальном хранилище. При наличии операций, ожидающих синхронизации с базой данных сервера, очистка породит исключение, если только не задан параметр force purge.

Пример устаревших данных на клиенте: предположим, что в примере «todo list» устройство Device1 извлекает только элементы, которые не завершены. Элемент Todoitem "Купить молоко" помечается на сервере как завершенный другим устройством. Однако устройство Device1 по-прежнему хранит элемент Todoitem "Купить молоко" в локальном хранилище, так как оно извлекает только элементы, которые не помечены как завершенные. Очистка позволяет удалить этот устаревший элемент.