On 2009 Feb 24, at 20:02, Dave Fernandes wrote:
I can't say I have the ideal solution, and I am also using KVO, but
one might want to heed Ben Trumbull's warning before going down this
path...
Complex KVO observer actions need to be carefully constrained. If
they simply grow organically, then it's pretty easy to fall into
the trap of observers creating side effects that trigger other
observers that cascade to yet more observers. [1]
Thanks, Dave. I was worried about that, but didn't see any
performance hit after implementing it. Certainly you want to keep
observations to a canonical minimum, but if indeed A could cause B to
change which could cause C to change, if you ^really^ want to view C,
you've got to observe A and B.
I'm only just getting familiar with the idiosyncrasies of Leopard,
however, in Tiger didTurnIntoFault might be called many times, but
awakeFromInsert or awakeFromFetch was only called once for the
lifetime of the MOC (not the lifetime of the object). Thus, if you
delete the object, and then undo that action, your observers will be
removed by didTurnIntoFault and not added back since awakeFromFetch
is not called again.
Well, that was easy to test and indeed I found that you found a bug in
my idea. The only way to fix it would be if we Apple had given us a -
didUnturnIntoFault method, but they did not.
So, it looks like, for observing changes to the properties of managed
objects ---
* Using NSManagedObjectContextObjectsDidChangeNotification is no good
since it doesn't give you specific information on the current
change
which actually caused the notification.
* Using KVO is no good because observers must be removed before an
object becomes a fault, and there is no mechanism to find out
when the object un-becomes a fault, which you need to restore
your observers.
So, my conclusion is that writing Custom Setters for any properties
that need to be observed and posting a notification (coalesced, for
efficiency) within the custom setter is the only viable technique.
Does anyone have any better ideas?
Jerry
[1] http://www.cocoabuilder.com/archive/message/cocoa/2008/3/28/202594
_______________________________________________
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
