Azure モバイル アプリでのオフライン データ同期Offline Data Sync in Azure Mobile Apps

注意

Visual Studio App Center は、モバイル アプリ開発の中心となるエンドツーエンドの統合サービスをサポートしています。Visual Studio App Center supports end to end and integrated services central to mobile app development. 開発者は、ビルドテスト配布のサービスを使用して、継続的インテグレーションおよびデリバリー パイプラインを設定できます。Developers can use Build, Test and Distribute services to set up Continuous Integration and Delivery pipeline. アプリがデプロイされたら、開発者は分析および診断のサービスを利用してアプリの状態と使用状況を監視し、プッシュ サービスを利用してユーザーと関わることができます。Once the app is deployed, developers can monitor the status and usage of their app using the Analytics and Diagnostics services, and engage with users using the Push service. また、開発者は Auth を利用してユーザーを認証し、データ サービスを利用してクラウド内のアプリ データを保持および同期することもできます。Developers can also leverage Auth to authenticate their users and Data service to persist and sync app data in the cloud.

モバイル アプリケーションにクラウド サービスを統合することを検討している場合は、今すぐ App Center にサインアップしてください。If you are looking to integrate cloud services in your mobile application, sign up with App Center today.

オフライン データ同期についてWhat is offline data sync?

オフライン データ同期は、ネットワーク接続なしで機能するアプリを開発者が作成しやすくする、Azure モバイル アプリのクライアントおよびサーバーの SDK 機能です。Offline data sync is a client and server SDK feature of Azure Mobile Apps that makes it easy for developers to create apps that are functional without a network connection.

アプリがオフライン モードの場合でもデータを作成および変更できますが、それらのデータはローカル ストアに保存されます。When your app is in offline mode, you can still create and modify data, which are saved to a local store. アプリは、オンラインに復帰するとローカルの変更内容を Azure モバイル アプリ バックエンドと同期します。When the app is back online, it can synchronize local changes with your Azure Mobile App backend. この機能には、クライアントとバックエンドの両方で同じレコードが変更された場合の競合検出のサポートも含まれています。The feature also includes support for detecting conflicts when the same record is changed on both the client and the backend. 検出された競合は、サーバーまたはクライアントのどちらでも処理することができます。Conflicts can then be handled either on the server or the client.

オフライン同期には、次のような複数の利点があります。Offline sync has several benefits:

  • サーバー データをデバイスにローカルでキャッシュすることにより、アプリケーションの応答性を向上させる。Improve app responsiveness by caching server data locally on the device
  • ネットワークの問題がある場合でも使用可能な信頼性の高いアプリを作成する。Create robust apps that remain useful when there are network issues
  • エンド ユーザーがネットワークにアクセスできなくてもデータを作成および変更できるようにすることで、接続がほとんどまたはまったく得られないような状況をサポートする。Allow end users to create and modify data even when there is no network access, supporting scenarios with little or no connectivity
  • 複数のデバイス間でデータを同期させ、同じレコードが 2 つのデバイスによって変更されたときに競合を検出する。Sync data across multiple devices and detect conflicts when the same record is modified by two devices
  • 待ち時間の長いネットワークや従量制ネットワークの使用を制限する。Limit network use on high-latency or metered networks

以下のチュートリアルで、Azure モバイル アプリ を使用してモバイル アプリにオフライン同期を追加する方法について説明しています。The following tutorials show how to add offline sync to your mobile clients using Azure Mobile Apps:

同期テーブルについてWhat is a sync table?

Azure Mobile クライアント SDK では、"/tables" エンドポイントにアクセスするために IMobileServiceTable (.NET クライアント SDK) や MSTable (iOS クライアント) などのインターフェイスを提供しています。To access the "/tables" endpoint, the Azure Mobile client SDKs provide interfaces such as IMobileServiceTable (.NET client SDK) or MSTable (iOS client). これらの API は直接 Azure モバイル アプリ バックエンドに接続しているため、クライアント デバイスのネットワーク接続がなくなると機能しなくなります。These APIs connect directly to the Azure Mobile App backend and fail if the client device does not have a network connection.

オフラインでの使用をサポートするには、代わりに IMobileServiceSyncTable (.NET クライアント SDK) や MSSyncTable (iOS クライアント) などの同期テーブル API をアプリで使用する必要があります。To support offline use, your app should instead use the sync table APIs, such as IMobileServiceSyncTable (.NET client SDK) or MSSyncTable (iOS client). 通常の CRUD 操作 (作成、読み取り、更新、削除) はすべて同期テーブル API に対して行われますが、読み取りまたは書き込みをローカル ストアに対して行うようになる点だけが異なります。All the same CRUD operations (Create, Read, Update, Delete) work against sync table APIs, except now they read from or write to a local store. 同期テーブル操作を実行する前に、ローカル ストアを初期化する必要があります。Before any sync table operations can be performed, the local store must be initialized.

ローカル ストアについてWhat is a local store?

ローカル ストアは、クライアント デバイス上のデータ永続化レイヤーです。A local store is the data persistence layer on the client device. Azure モバイル アプリ クライアントの SDK では、既定のローカル ストアの実装を提供します。The Azure Mobile Apps client SDKs provide a default local store implementation. ローカル ストアのベースは、Windows、Xamarin、および Android では SQLite です。On Windows, Xamarin and Android, it is based on SQLite. iOS では Core Data です。On iOS, it is based on Core Data.

Windows Phone または Microsoft Store で SQLite ベースの実装を使用するには、SQLite の拡張機能をインストールする必要があります。To use the SQLite-based implementation on Windows Phone or Microsoft Store, you need to install a SQLite extension. 詳細については、ユニバーサル Windows プラットフォーム:オフライン同期を有効にする方法に関するページを参照してください。Android と iOS では、デバイスのオペレーティング システム自体にあるバージョンの SQLite が同梱されているので、独自のバージョンの SQLite を参照する必要はありません。For more information, see Universal Windows Platform: Enable offline sync. Android and iOS ship with a version of SQLite in the device operating system itself, so it is not necessary to reference your own version of SQLite.

開発者は、独自のローカル ストアを実装することもできます。Developers can also implement their own local store. たとえば、データを暗号化された形式でモバイル クライアント上に保存する必要がある場合は、SQLCipher を使用して暗号化を行うローカル ストアを定義できます。For instance, if you wish to store data in an encrypted format on the mobile client, you can define a local store that uses SQLCipher for encryption.

同期コンテキストについてWhat is a sync context?

同期コンテキストはモバイル クライアント オブジェクト (IMobileServiceClientMSClient など) に関連付けられており、同期テーブルに対して行われた変更を追跡します。A sync context is associated with a mobile client object (such as IMobileServiceClient or MSClient) and tracks changes that are made with sync tables. 同期コンテキストにより、後でサーバーに送信される CUD 操作 (作成、更新、削除) の順序付きリストを保持する "操作のキュー" が維持されます。The sync context maintains an operation queue, which keeps an ordered list of CUD operations (Create, Update, Delete) that is later sent to the server.

同期コンテキストへのローカル ストアの関連付けは、初期化メソッド (.NET クライアント SDKIMobileServicesSyncContext.InitializeAsync(localstore) など) を使用して行います。A local store is associated with the sync context using an initialize method such as IMobileServicesSyncContext.InitializeAsync(localstore) in the .NET client SDK.

オフライン同期のしくみHow offline synchronization works

同期テーブルを使用する場合、クライアント コードによって、ローカルの変更内容が Azure モバイル アプリ バックエンドと同期される時期が制御されます。When using sync tables, your client code controls when local changes are synchronized with an Azure Mobile App backend. ローカルの変更を プッシュする 呼び出しが行われるまで、バックエンドには何も送信されません。Nothing is sent to the backend until there is a call to push local changes. 同様に、ローカル ストアに新しいデータが入力されるのは、データを プルする 呼び出しが行われる場合のみです。Similarly, the local store is populated with new data only when there is a call to pull data.

  • プッシュ:プッシュは同期コンテキストに対する操作であり、最後のプッシュ以降の CUD に関するすべての変更を送信します。Push: Push is an operation on the sync context and sends all CUD changes since the last push. 個々のテーブルの変更だけを送信すると操作の順番が間違って送信される可能性があるため、このような送信を行うことができないことに注意してください。Note that it is not possible to send only an individual table's changes, because otherwise operations could be sent out of order. プッシュは Azure モバイル アプリ バックエンドに対して一連の REST 呼び出しを実行し、呼び出しを受けたバックエンドがサーバー データベースを変更します。Push executes a series of REST calls to your Azure Mobile App backend, which in turn modifies your server database.

  • プル:プルはテーブルごとに実行され、クエリを使用してサーバー データのサブセットのみを取得するようにカスタマイズできます。Pull: Pull is performed on a per-table basis and can be customized with a query to retrieve only a subset of the server data. その後、Azure Mobile クライアント SDK が結果のデータをローカル ストアに挿入します。The Azure Mobile client SDKs then insert the resulting data into the local store.

  • 暗黙的なプッシュ:保留中のローカルの更新があるテーブルに対してプルが実行された場合、プルはまず同期コンテキストに対して push() を実行します。Implicit Pushes: If a pull is executed against a table that has pending local updates, the pull first executes a push() on the sync context. このプッシュにより、キュー済みの変更とサーバーの新規データとの競合が最小限に抑えられます。This push helps minimize conflicts between changes that are already queued and new data from the server.

  • 増分同期: プル操作の最初のパラメーターは クエリ名 であり、これはクライアントでのみ使用されます。Incremental Sync: the first parameter to the pull operation is a query name that is used only on the client. null 以外のクエリ名を使用すると、Azure Mobile SDK は 増分同期を実行します。プル操作で結果のセットが返されるたびに、その結果セットから最新の updatedAt タイムスタンプが SDK ローカル システム テーブルに格納されます。If you use a non-null query name, the Azure Mobile SDK performs an incremental sync. Each time a pull operation returns a set of results, the latest updatedAt timestamp from that result set is stored in the SDK local system tables. それ以降のプル操作では、そのタイムスタンプより後のレコードだけが取得されます。Subsequent pull operations retrieve only records after that timestamp.

    増分同期を使用するには、サーバーが意味のある updatedAt 値を返すとともに、このフィールドでの並べ替えをサポートしている必要があります。To use incremental sync, your server must return meaningful updatedAt values and must also support sorting by this field. ただし、SDK はupdatedAt フィールドに独自の並べ替えを追加するため、固有の orderBy 句を含むプル クエリは使用できません。However, since the SDK adds its own sort on the updatedAt field, you cannot use a pull query that has its own orderBy clause.

    クエリ名は任意の文字列にすることができますが、アプリ内の論理クエリごとに一意である必要があります。The query name can be any string you choose, but it must be unique for each logical query in your app. 一意でない場合、異なるプル操作によって同じ増分同期のタイムスタンプが上書きされて、クエリが誤った結果を返す可能性があります。Otherwise, different pull operations could overwrite the same incremental sync timestamp and your queries can return incorrect results.

    クエリでパラメーターを使用する場合、一意のクエリ名を作成する 1 つの方法はパラメーター値を組み込むことです。If the query has a parameter, one way to create a unique query name is to incorporate the parameter value. たとえば、userid でフィルター処理をする場合、クエリ名は次のようにすることができます (C# を使用)。For instance, if you are filtering on userid, your query name could be as follows (in C#):

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

    増分同期を無効にする場合は、 null をクエリ ID として渡します。If you want to opt out of incremental sync, pass null as the query ID. この場合、PullAsync への呼び出しごとにすべてのレコードが再取得されるため、場合によっては非効率となります。In this case, all records are retrieved on every call to PullAsync, which is potentially inefficient.

  • 消去:ローカル ストアのコンテンツは IMobileServiceSyncTable.PurgeAsync を使用して削除できます。Purging: You can clear the contents of the local store using IMobileServiceSyncTable.PurgeAsync. 消去は、クライアント データベースに古くなったデータがある場合、または保留中の変更をすべて破棄する場合に行う必要があります。Purging may be necessary if you have stale data in the client database, or if you wish to discard all pending changes.

    消去により、ローカル ストアからテーブルがクリアされます。A purge clears a table from the local store. サーバー データベースとの同期待ちの操作がある場合、force purge パラメーターを設定しない限り消去では例外がスローされます。If there are operations awaiting synchronization with the server database, the purge throws an exception unless the force purge parameter is set.

    クライアント上の古くなったデータの例として、"todo list" サンプルでデバイス 1 が未完了のアイテムだけを取得するとします。As an example of stale data on the client, suppose in the "todo list" example, Device1 only pulls items that are not completed. 別のデバイスによって、サーバー上の TodoItem "Buy milk" が完了とマークされたとします。A todoitem "Buy milk" is marked completed on the server by another device. ただし、デバイス 1 は完了とマークされていないアイテムだけをプルするので、デバイス 1 はローカル ストアに "Buy milk" TodoItem を残しています。However, Device1 still has the "Buy milk" todoitem in local store because it is only pulling items that are not marked complete. 消去により、この古い項目がクリアされます。A purge clears this stale item.

次の手順Next steps