On Mar 31, 2011, at 14:13, Sean McBride wrote: > Still, I'm hesitant to do KVO observation from one managedobject to > another. I currently don't do that anywhere. Do you use this technique > frequently?
Frequently? Yes. With Core Data? Not recently, but in the past, similar things. > It's unclear to me where to start and stop observation, in > general. If you handle this in the window controller, you typically start in 'windowDidLoad' and stop in 'windowWillClose'. > If I turn into a fault, must I stop observing? No. Faults are about backing storage, not about object behavior (he said bravely). > If I'm deleted? If the delete is undone, do I start observing again? And > redo? KVO notifications will take care of this. Consider what happens if you display (all of the members of) this relationship in a table view. The bindings are using KVO, and the table always shows the correct data, doesn't it? KVO is behaviorally orthogonal to Core Data weirdness, at least on your side of the API. However, undo/redo is the test. If your mechanism survives that, then it will work everywhere. :) > For these reasons I tend to prefer overriding relationship setters/ > mutators and updating my caches/transients there. In this case, by > implementing addEmployeesObject: and removeEmployeesObject: to set/clear > my department's cache of the 'employee id 0' object. I don't see anything wrong with that approach, if it seems safer, or more concrete. Overriding Core Data accessors has its own quirks, though well documented in the programming guide. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
