0

アプリを最初に実行したときに0セクションを返すNSFetchedResultsControllerに問題がありますが、その後アプリを閉じてリロードすると正しいセクション数になります。

配列[[self.fetchedResultsControllerfetchedObjects]description]をNSLogすると、最初の時間とそれ以降の時間でわずかに異なる結果が得られることに気付きました。これが全体的な問題の把握に役立つことを願っています。

ファーストラン：

"<Contact: 0x1fc7a000> (entity: Contact; id: 0x1fc79cb0 <x-coredata:///Contact/tC060241D-2C37-4F78-AA69-5FBE3CB9DDFB364> ; data: {\n    email = nil;\n    emails =     (\n    );\n    name = \"AIB Dundrum\";\n    nameInitial = A;\n    parseID = nil;\n    phoneNumber = 012983777;\n    signedUp = 0;\n})"

2回目の実行：

"<Contact: 0x1e35f3f0> (entity: Contact; id: 0x1e2ab020 <x-coredata://FD1A50BA-9A08-452D-B4B4-2072FA1B190C/Contact/p337> ; data: <fault>)"

これらの出力の違い、2回目にアプリを実行したときにデータに障害が発生した理由、および最初にこれを実行する方法を誰かに説明してもらえますか？

ありがとう

4

1 に答える 1

2

2 回目の実行で、faultが表示されます。これは、Core Data がこのオブジェクトがグラフに存在することを認識しているが、それ以外のことを認識していないことを意味します。他の情報を取得するには、永続ストアに戻る必要があります。障害オブジェクトを使用することにより、Core Data はメモリ内のオブジェクト グラフのサイズを制限できます。「障害を発生させる」方法の 1 つは、オブジェクトのプロパティの 1 つにアクセスすることです。Contact NSManagedObject の説明をログに記録する前に、ブレークポイントを設定することにより、デバッガーでこれを行うことができます。ブレーク ポイントに到達したら、デバッガ コンソールに次のように入力します。

po [myContact willAccessValueForKey:nil]これにより障害が発生し、説明をログに記録すると、表示されませんdata: <fault>が、「最初の実行」で表示されているすべてのプロパティとその値が表示されます。

よくわからないことの 1 つはx-coredata:///Contact/tC060241D-2C37-4F78-AA69-5FBE3CB9DDFB364、First Run とx-coredata://FD1A50BA-9A08-452D-B4B4-2072FA1B190C/Contact/p337Second Run で表示される理由です。最初の実行では連絡先がまだ保存されていないようにp337見えますが、2 番目の実行で表示されるのは、実際にはバッキング永続ストアのレコード ID を表しています。この ID に依存するべきではありませんが、私のデバッグと分析の経験から、これは常に当てはまります。そうは言っても、First Run にログインしている連絡先がまだ永続ストアに保存されていないと私が信じるようになったのはそのためです。

それが役立つことを願っています。

于 2013-01-24T05:51:31.667 に答える