Re: Core Data design question: receiving KVO notifications of partially mutated objects
Re: Core Data design question: receiving KVO notifications of partially mutated objects
- Subject: Re: Core Data design question: receiving KVO notifications of partially mutated objects
- From: "Sean McBride" <email@hidden>
- Date: Mon, 2 Nov 2009 18:11:12 -0500
- Organization: Rogue Research Inc.
On 11/2/09 12:58 PM, Ben Trumbull said:
>> What is considered best practice when it comes to mutating many
>> properties of a managed object, specifically with regard to KVO
>> observers getting notified before all mutations are finished?
>
>This is a problem intrinsic to the design of KVO. KVO is all about fine
>grained per property notifications. It's very well suited to that.
>However, it's common for complex objects to be in an intermediate state
>during a KVO notification.
>
>There's no better notion of cross-property coherence than refactoring
>into a different property object that encapsulates everything.
>
>> Let's say I have an Rectangle object. It has properties: colour, width,
>> height. Imagine some controller observing all these properties, perhaps
>> to trigger a redraw.
>>
>> If I do:
>>
>> [rect setColour:...];
>> [rect setWidth:...];
>> [rect setHeight:...];
>
>In this example, the best KVO can do is work with a "colored rectangle"
>object that in turn is the 1 property you work with here. So, this
>would be an example of a granularity of notification that works better
>with NSNotificationCenter
>
>> This is short and readable. But observers will be notified after each
>> setter.
>
>yup
>
>> This could be a problem if intermediate states are not self-
>> consistent and could also lead to unnecessary redrawing.
>
>And many other performance issues if observers recalculate things too
>aggressively.
>
>> In the general case, I might not even know who is observing.
>
>Well, that's the point of the notification pattern.
>
>>
>> I guess it's safer to create a setColour:width:height: method in my
>> NSManagedObject subclass that does:
>>
>> [self willAccessValueForKey:@"colour"];
>> [self willAccessValueForKey:@"width"];
>>
>> [self setPrimitiveColour:...];
>> [self setPrimitiveWidth:...];
>>
>> [self didAccessValueForKey:@"width"];
>> [self didAccessValueForKey:@"colour"];
>>
>> Is this what I should be doing?
>
>Generally, no. (setting aside, the calls should be to
>willChangeValueForKey:, btw)
Ben,
Thanks for all the above comments, they have each connected a few dots
in my mind.
>If your issue is that drawing or recalculation is occurring too
>frequently after KVO changes, you can consider coalescing and deferring
>the observers' actions instead of performing them synchronously. This
>can be valuable even for less complex KVO issues.
>
>You could also refactor the 3 properties into 1 object.
Alas, that would require 1) persistent store migration (painful on 10.5)
and 2) I find it very handy to be able to bind 'colour' to a colourwell
and 'width' and 'height' to text fields. Perhaps I have bent my model
too much in favour of my UI also. :) But anyway, this 'Rectangle'
object was just an example. My real app is a bit harder to explain.
>Or use an
>NSNotification instead of KVO to adjust the granularity of notifications
>to better suit your drawing code.
>
>This doesn't really have anything to do with Core Data. However, for
>NSManagedObject, Core Data already provides the change coalescing and
>NSNotifications for you. You can respond within
>NSManagedObjectContextObjectsDidChangeNotification instead.
Perhaps NSManagedObjectContextObjectsDidChangeNotification is the thing
I have overlooked! I currently use it almost nowhere but have tonnes
and tonnes of KVO observing going on.
I'll have to RTFM on NSManagedObjectC
ontextObjectsDidChangeNotification. Questions that pop to mind though:
is it safe for me to fetch? to create/delete/mutate ManagedObjects?
Ultimately, my recent problem with 'dangling reference to an invalid
object' made me realise I probably have some design problems, which I
can't quite put my finger on. I'm pretty sure I'm misusing/abusing KVO
however.
Thanks,
--
____________________________________________________________
Sean McBride, B. Eng email@hidden
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
_______________________________________________
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