コアデータとサーバー リクエストを組み合わせるアプリの大きなコードを書き直しています。そして、新しいサーバー要求が新しい JSON で返されたらすぐにオブジェクトを同時に更新できるように、最善の方法を見つけようとしています。ところで、iOS7 がソリューションを改善する場合、コードは iOS7 と互換性があるだけでよいと思い込んでください。
基本的な使用例は次のとおりです。
属性と 2 つの M2M (ユーザー/ユーザー) 関係を持つUserエンティティがあるidとします。もちろん。namefriends.fiends
というわけでアプリ起動。インメモリ グラフにも SQL 永続ストアにも何もありません。ID 15 のユーザーとその友達や悪魔を取得するように依頼します。
次に起こることは次のとおりです。
- CD は
Usertype の述語でフェッチを行いid = 15ます。 - 何も戻ってこないので、次のサーバー エンドポイントの 3 つの AFRequest をキューに入れます: A:
/users/15(これはユーザー属性を取得しますid)name、B:users/15/friends(関係)、およびC:users/15/fiends(関係)。これら 3 つの要求は同時に発生します。 - これらの要求のいずれかが (ユーザーの JSON 表現または関係の友人/悪魔の配列と共に) 返されるとすぐに、CD コンテキストをクエリして、JSON ペイロード内のオブジェクトが既に CD に存在するかどうかを確認します。その場合 (後続のサーバー呼び出しで発生します)、サーバーからの新しいデータでそれらを更新します (該当する場合は関係の確立を含む)。そうでない場合は、CD コンテキストで新しい管理対象オブジェクトを作成し、JSON から属性/関係を設定します。
idこの場合のオブジェクトの作成と識別は、常にその属性に基づいています。 - いずれにせよ、完了したら、CD コンテキストを保存します。
上記から、JSON がサーバーから返されるたびに、対応する管理対象オブジェクトを作成または更新して保存します。この例の問題は、同じコンテキストが 3 つの潜在的な同時呼び出しを取得することです: ユーザー 15 の作成および/またはそのfriendsへの入力、ユーザー 15 の作成および/またはその への入力、fiendsユーザー 15 の作成および/またはその名前と ID の更新。
私の当初の計画は次のとおりでした。
- 3つのAFRequestを次々に作成します（これは同時キューに入ると想定しているため、同時に実行されます）
- リクエストの完了ブロックをすべて同じ GCD 同時キューにディスパッチします。
- 各 GCD ブロックに新しい CD コンテキストを作成させ、挿入/更新を行ってから保存を呼び出します
- メイン CD コンテキストにメイン スレッドの変更をマージさせます。
NSManagedObjectContextしかし、今、子コンテキストの概念と同様に、2 つのキュー同時実行タイプについて少し読んだだけで、-performBlock:まだ完全には理解していません。だから私は疑問に思っていました、私の当初の計画は実行可能に聞こえますか?
私が考えることができるいくつかの質問は次のとおりです。
NSPrivateQueueConcurrencyType代わりに、ステップ 3 で、 GCD ブロックごとにメイン コンテキストの子コンテキストを作成する方がよいでしょうか?- もしそうなら、私はまだGCDキューが必要ですか? つまり、
NSPrivateQueueConcurrencyTypeGCD を介してディスパッチする代わりに、単一のコンテキストを使用する必要があります-performBlock:か?