8

これが Magical Record のセーブ方法の問題なのか、それともどこかで単純なミスを犯しているだけなのかはわかりません。

NSFetchedResultController (FRC) と UITableView を使用してエンティティのリストを表示しています。ユーザーがエディタで新しいビュー コントローラを [追加] をタップすると、新しいエンティティが で作成され[MyEntity MR_createEntity]ます。ユーザーは、関係を介してメイン エンティティに追加される追加のエンティティをここに追加できます。ユーザーがこのView Controllerで「保存」をタップすると、コンテキストが保存されます[[NSManagedObjectContext MR_contextForCurrentThread] MR_save]

NSFetchedResultsController は更新されているように見えますが、タップしてエンティティを編集すると、子エンティティはありません。デバッグは、エンティティが保存されていても、FRC には一時 ID を持つエンティティがまだあることを示しているようです。

[self.tableView reloadData]FRCcontrollerDidChangeContentデリゲートメソッドで素朴にやっています。

アプリケーションを再起動すると、正しいエンティティが読み込まれ、子エンティティがエディター ビュー コントローラーに正しく表示されます。

FRC は「メイン スレッド」の保存イベントに応答しているように見えますが、保存は実際にはバックグラウンド スレッドで行われているため、FRC はそれを認識していません。確認したところ、すべての「自分の」操作 (FRC の設定、エンティティの作成とフェッチ) はすべてメイン スレッド コンテキストで行われています。

MR_rootSavingContext で変更通知をリッスンし、それらをメイン スレッド コンテキストとマージしようとしましたが、これはうまくいきましたが、FRC で行が重複してしまいました (1 つは正しい「永続的な」エンティティで、もう 1 つは一時的なエンティティでした)。

4

2 に答える 2

8

OK、これが「正しい方法」かどうかはわかりませんが、「inContext」バージョンのMR_fetchAllSortedBy.

これは、FRC がその子の 1 つではなく rootSavingContext を監視しているという観点からは理にかなっていると思います。それでも、同じスレッドですべての操作を行っているので、問題にはならないと思っていました。

更新:このアプローチの唯一の落とし穴は、エンティティを取得[frc objectAtIndexPath:]して編集ビュー コントローラーに渡すと、デフォルトのコンテキストではなくなることです。NSManagedObjectContext のexistingObjectWithID. まだすべてが完全に正しいとは感じていませんが、私にとってはうまくいっています。

于 2012-06-11T05:35:21.137 に答える