2

NSPrivateQueueConcurrencyType コンテキストは、-performBlock および -performBlockAndWait 内でのみ動作するのだろうか。および NSPrivateQueueConcurrencyType コンテキストから返される NSManagedObject は、performBlock の外ではアクセスできませんか?

アップルのドキュメント「iOS 5.0 の新機能」から次の文を見つけました。

キューの関連付けで作成されたコンテキストにメッセージを送信する場合、コードがそのキュー (メイン キュー タイプの場合) または performBlock... 呼び出しのスコープ内でまだ実行されていない場合は、 performBlock: または performBlockAndWait: メソッドを使用する必要があります。 (プライベート キュー タイプの場合)。これらのメソッドに渡されたブロック内で、NSManagedObjectContext のメソッドを自由に使用できます。

もしそうなら、なぜ MagicalRecord と XMPPFramework はブロック内のコンテキストと NSManagedObject を操作しないのですか?

4

1 に答える 1

4

MagicalRecord と XMPPFramework のコードが何をするのか、何をしないのか、私にはわかりません。通常のサポート手段を通じて連絡する必要があります。

ただし、NSPrivateQueueConcurrencyType で MOC を作成する場合、その MOC またはその MOC が所有する管理対象オブジェクトにアクセスする唯一の方法は、performBlock* API を使用することです。

NSMainQueueConcurrencyType で MOC を作成すると、メイン スレッドで実行している場合、または performBlock* API を介して MOC にアクセスできます。

NSConfinementConcurrencyType で MOC を作成する場合、MOC が作成されたスレッドからのみ MOC にアクセスする必要があります。同時実行性が指定されていない場合、制限がデフォルトとして使用されます。

これらは、MOC を作成する現在の唯一の方法であり、それらを使用するためのルールの概要です。

MagicalRecord は制限を使用し、スレッドごとに MOC を保持していると思いますが、私はそれを使用したことがなく、古いバージョンのコード ベースしか見ていないため、ネストされたコンテキストの出現で大きく変化した可能性があります。

于 2012-07-11T16:42:37.663 に答える