core-data - Parse によるコア データの同期

Question

Parse モバイル バックエンドを介してデバイス間でコア データ モデルを同期するライブラリの開発に興味があります。iCloud コア データ同期が提供しようとしている機能をミラーリングしたいと考えています。

なぜ iCloud やEnsemblesを使わないのですか? 現在、本番アプリで iCloud コア データ同期を使用していますが、うまく機能していません。また、Apple ID とは独立した認証を提供したいと考えています。これは、iCloud から離れたいもう 1 つの理由です。Ensembles に関する限り、Dropbox 同期 API が廃止されたため、これが引き続き Dropbox で機能するかどうかはわかりません。  

私はライブラリの開発を始めていません。以下に概説する私の計画についてのフィードバックを探しています。この設計は、この SO answerに基づいています。 

ライブラリの一般的な設計:

1. ライブラリは、永続ストア コーディネーターと管理オブジェクト コンテキストを設定する標準コア データ スタックを提供します。すべての標準コア データ CRUD 操作は、ライブラリによって提供されるインターフェイスを介して処理されます。

2. CUD 操作が行われるたびに、操作の再現に必要なすべての情報を含む同期操作オブジェクトがバックグラウンドで Parse に保存されます。これには、実行された操作のタイプ、操作されたオブジェクトの一意の識別子、作成操作の場合は親オブジェクトと関係が提供されます。

3. 各操作には、change_id 番号が関連付けられています。デバイスが操作をダウンロードして実行するたびに、その操作に関連付けられた最新の change_id が保存されます。
4. 各同期操作をアップロードする前に、デバイスはサーバーにリクエストを送信して、保存されている change_id 番号がローカルに保存されている番号と一致することを確認します。サーバーの change_id の方が大きい場合、最初にすべての同期操作をダウンロードして実行し、次に独自の同期操作をアップロードします。
5. 競合 (2 つのデバイスがオフライン中に同じ値を編集すること) は、どちらのデバイスが最後に値を変更したかを判別することによって解決されます。 

ここで何か不足していますか？このアプローチの潜在的な落とし穴は何ですか? 同期は難しいと聞きましたが、この種の作業は経験豊富な開発者に任せるべきでしょうか?

Answer 1

私は Ensembles フレームワークの開発者であるため、偏見の少ないレスポンダーではありませんが、いくつかの考えを提案させてください。

Ensembles 自体に関しては、バックエンドに依存しないフレームワークです。はい、iCloud および Dropbox Sync API で動作しますが、CloudKit、Dropbox Core API (非推奨ではない)、および WebDAV でも動作します。Heroku と S3 を使用して自分でデータをホストできるようにする 1 つのパッケージで利用できるカスタム Node.js サーバーもあります。

したがって、Apple に固執したくない場合でも、他の選択肢があります。さらに、独自のバックエンド アダプター クラスを作成できます。ほとんどのコードは約 500 行で、既存のクラスの 1 つをベースにすることができます。これにより、データを保存して Parse で認証するバックエンドを作成し、データのマージを Ensembles に任せることができます。これのもう 1 つの利点は、将来他のバックエンドに簡単に移行したり、オプションとして提供したりできることです。(CloudKit は一見の価値があります。)

しかし、あなたが他人のフレームワークを使用しないと決心していると仮定しましょう。そうであれば、あなたのアプローチは世界的に正しいように聞こえます。

CRUD 操作をインターフェイス経由で行うのではなく、ディクショナリNSManagedObjectContextDidSaveNotificationから変更を観察して抽出するだけです。userInfo

思いもよらなかった小さなことがたくさん見つかると思いますが、これらの詳細が同期を難しくする傾向があります。そのような例の 1 つは、アプリが終了する前に解析操作が完了しないなどの障害を処理するのに十分な堅牢なものを構築する必要があることです。最後の同期以降に変更されたものを取得できるように、おそらくすべてのオブジェクトに変更タグが必要です。

アプリのデータ量が少ない場合、このシステムを構築することはそれほど難しくありませんが、データが大きくなり始めると、iOS でメモリ内データを低く保つためにバッチ処理などを使用し始める必要があります。この種のことには、多くの時間がかかる場合があります。たとえば、Ensembles 2 には Ensembles 1 とほとんど同じ API がありますが、バッチ処理などをメモリ効率的に書き直すだけで約 4 か月を費やしました。

あなたが説明したアプローチを使用してプロトタイプアプリを作成しました（アプリはソーシャルであり、同期していないため、アンサンブルはありません）。Parse に非常によく似た CloudKit を使用しました。ローカルの Core Data キャッシュを使用して、データのアップロード/ダウンロード全体を正常に動作させるには、約 1000 行の Swift コードが必要でした。特にCore Dataをよく知っている場合は特に、それは確かに実行可能です. そうしないと、学習曲線が発生する可能性があります。

私が Ensembles のようなフレームワークを推奨しているのは、解決が必要な細部の多くがすでに解決されており、特定のバックエンドに縛られることはないということです。Parse が料金を引き上げることを決定した場合、他の場所に自由に移動できます。