iPhone のコアデータを Web サーバーと同期し、他のデバイスにプッシュする方法 [closed] 質問する

iPhone のコアデータを Web サーバーと同期し、他のデバイスにプッシュする方法 [closed] 質問する

私は、iPhone アプリケーションに保存されているコア データを iPad や Mac などの複数のデバイス間で同期する方法に取り組んできました。iOS の Core Data で使用する同期フレームワークは、ほとんどありません (まったくない場合もあります)。しかし、私は次のようなコンセプトについて考えていました。

  1. ローカル コア データ ストアに変更が加えられ、変更が保存されます。(a) デバイスがオンラインの場合、変更セットを送信したデバイスのデバイス ID を含め、変更セットをサーバーに送信しようとします。(b) 変更セットがサーバーに到達しない場合、またはデバイスがオンラインでない場合は、アプリは変更セットをキューに追加し、オンラインになったときに送信します。
  2. クラウド内にあるサーバーは、受信した特定の変更セットをマスター データベースとマージします。
  3. 変更セット (または変更セットのキュー) がクラウド サーバー上でマージされた後、サーバーは何らかのポーリング システムを使用して、それらの変更セットすべてをサーバーに登録されている他のデバイスにプッシュします。(Apple のプッシュ サービスを使用することを考えましたが、コメントによると、どうやらこれは実行可能なシステムではないようです。)

何か特別なことを考える必要があるでしょうか?私はRESTフレームワークなどを見てきました。目的リソースコアリソース、 そしてRestfulコアデータもちろん、これらはすべて Ruby on Rails で動作しますが、私はこれに縛られているわけではありません。しかし、これは出発点にはなります。私のソリューションに求める主な要件は次のとおりです。

  1. 変更は、メイン スレッドを一時停止せずにバックグラウンドで送信する必要があります。
  2. 帯域幅の使用はできる限り少なくする必要があります。

私はいくつかの課題について考えました:

  1. 異なるデバイス上の異なるデータ ストアのオブジェクト ID がサーバーにアタッチされていることを確認します。つまり、オブジェクト ID とデバイス ID のテーブルがあり、これらはデータベースに格納されているオブジェクトへの参照を介して結び付けられます。レコード (DatabaseId [このテーブルに一意]、ObjectId [データベース全体のアイテムに一意]、Datafield1、Datafield2) があり、ObjectId フィールドは別のテーブル AllObjects: (ObjectId、DeviceId、DeviceObjectId) を参照します。次に、デバイスが変更セットをプッシュすると、ローカル データ ストアのコア データ オブジェクトからデバイス ID とオブジェクト ID が渡されます。次に、クラウド サーバーは AllObjects テーブルのオブジェクト ID とデバイス ID をチェックし、初期テーブルで変更するレコードを見つけます。
  2. すべての変更にはタイムスタンプを付けて、マージできるようにする必要があります。
  3. デバイスは、バッテリーをあまり消費せずにサーバーをポーリングする必要があります。
  4. ローカル デバイスは、サーバーから変更を受信した場合、メモリに保持されているすべての内容を更新する必要があります。

他に何か見落としている点はありますか? これを可能にするには、どのようなフレームワークを検討すればよいでしょうか?

ベストアンサー1

私はあなたがやろうとしていることと似たようなことをやったことがあります。私が学んだことと、それをどうやってやったかをお話ししましょう。

Core Data オブジェクトとサーバー上のモデル (または DB スキーマ) の間に 1 対 1 の関係があると想定しています。サーバーのコンテンツをクライアントと同期させたいだけですが、クライアントもデータを変更したり追加したりできます。それが正しい場合は、読み続けてください。

同期を支援するために 4 つのフィールドを追加しました。

  1. sync_status - このフィールドはコア データ モデルにのみ追加します。アプリは、このフィールドを使用して、アイテムに保留中の変更があるかどうかを判断します。次のコードを使用します: 0 は変更なし、1 はサーバーに同期するためにキューに入れられている、2 は一時オブジェクトであり削除できることを意味します。
  2. is_deleted - これをサーバーとコア データ モデルに追加します。削除イベントは、データベースまたはクライアント モデルから行を実際に削除すべきではありません。削除すると、同期するものがなくなるためです。この単純なブール フラグを使用することで、is_deleted を 1 に設定して同期すれば、誰もが満足することになります。また、サーバーとクライアントのコードを変更して、削除されていないアイテムを "is_deleted=0" でクエリする必要があります。
  3. last_modified - これをサーバーとコア データ モデルに追加します。このフィールドは、レコードに変更があったときにサーバーによって現在の日付と時刻で自動的に更新されます。クライアントによって変更されることはありません。
  4. guid - グローバルに一意のIDを追加します(http://en.wikipedia.org/wiki/グローバルユニーク識別子) フィールドをサーバーとコア データ モデルに追加します。このフィールドは主キーとなり、クライアントで新しいレコードを作成するときに重要になります。通常、主キーはサーバー上で増加する整数ですが、コンテンツはオフラインで作成され、後で同期される可能性があることに留意する必要があります。GUID を使用すると、オフラインでもキーを作成できます。

クライアントでは、何かが変更されてサーバーと同期する必要がある場合はいつでも、モデル オブジェクトの sync_status を 1 に設定するコードを追加します。新しいモデル オブジェクトは GUID を生成する必要があります。

同期は単一のリクエストです。リクエストには次のものが含まれます。

  • モデル オブジェクトの MAX last_modified タイムスタンプ。これにより、このタイムスタンプ以降の変更のみが必要であることがサーバーに通知されます。
  • sync_status=1 のすべての項目を含む JSON 配列。

サーバーはリクエストを受け取り、次の処理を実行します。

  • JSON 配列からコンテンツを取得し、そこに含まれるレコードを変更または追加します。last_modified フィールドは自動的に更新されます。
  • サーバーは、リクエストで送信されたタイムスタンプよりも大きい last_modified タイムスタンプを持つすべてのオブジェクトを含む JSON 配列を返します。これには、受信したばかりのオブジェクトが含まれ、レコードがサーバーに正常に同期されたことの確認として機能します。

アプリは応答を受信して​​次の処理を実行します。

  • JSON 配列からコンテンツを取得し、そこに含まれるレコードを変更または追加します。各レコードの sync_status は 0 に設定されます。

「記録」と「モデル」という言葉を同じ意味で使用しましたが、その意味は理解できたと思います。

おすすめ記事