Re: Observing Managed Object Changes. Was: Strange ... behavior
Re: Observing Managed Object Changes. Was: Strange ... behavior
- Subject: Re: Observing Managed Object Changes. Was: Strange ... behavior
- From: Ben Trumbull <email@hidden>
- Date: Wed, 25 Feb 2009 20:16:29 -0800
On 2009 Feb 25, at 17:11, Ben Trumbull wrote:
bug numbers ?
Ben, I will definitely file bug(s) after I get this sorted out. But
in the interim...
The problem is easily stated in terms of DepartmentAndEmployees. I
have views which want to know when various object properties change.
For one example, say I want to add an OrgChart object. My OrgChart
wants to receive a notification or observation when the directReports
of any Employee is changed.
There appear to be solutions to this problem and both are surprisingly
complicated.
Solution 1. Use KVO. Although adding observers is systematic
(awakeFromInsert + awakeFromFetch), removing observers must be done
(1) when deallocating the moc and (2) in the managed object's -dealloc
method (which is not recommended for subclassing). The latter is to
catch objects still on the undo stack or elsewhere.
Solution 2. Use Custom Setters. In each setter, post a
notification. This is not too bad with attributes -- only one setter
per attribute. But for to-many relations you need to override the
four, or is it five, set mutator methods, and what if more are added
in some future version of Mac OS? This requires much code and seems
fragile.
Which solution, or a different one, looks "better" to you?
Well, they are both pretty unappealing. I'd probably go with a case
by case basis, and attempt to stick to the
NSManagedObjectContextObjectsDidChangeNotification notification as
much as possible. You can stash extra bread crumbs in an unmodeled
ivar.
For your specific example of directReports in Employees and
Departments, I'd use custom setters. This case is more complicated
because you want to observe the contents of a specific to-many
relationship, not the relationship itself. I wouldn't do that
wholesale for all kinds of properties.
- Ben
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden