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: Graham Cox <email@hidden>
- Date: Sat, 31 Oct 2009 12:02:26 +1100
Hi Sean,
I'd say you're going down the wrong path there.
Set each property individually. Yes, it will trigger a notification
for each one - doesn't or shouldn't matter, and unless you can show it
causes a performance problem, shouldn't be a cause for worry on that
score. It won't cause multiple redrawing, because even if each one
posted a -setNeedsDisplayInRect:, the actual drawing will not get
processed until the next update cycle and invalidating the same area
three times still only results in one redraw, by which time all the
properties will be set. Drawing performance is not an issue here
(unless you are bypassing the update mechanism and forcing the drawing
on a notification, but that's a different wrong, so you're not doing
that, are you?).
The question of whether the separate notifications lead to an invalid
intermediate state is a more reasonable problem to consider, but it
normally shouldn't matter either. Normally KVO will be used to update
your UI and/or maintain undo. You mention Core Data so that will
handle undo for you but even if you were doing that yourself it
shouldn't matter. Undo will record each property change and group
them, so you end up with one undo that undoes all three property
changes. Any UI that represents each property will also update all at
once (or appear to) because the drawing update cycle won't actually
show changes until the update runs and flushes the changes to the
backing store.
As a general rule you can and should treat each property in isolation.
Even if some command sets several at once, you should find that it all
works correctly unless you've gone out of your way to depend on some
property state always being paired with some other property state, in
which case you should probably make that state pair a separate
property. I think as a general rule the approach you're proposing is
unnecessary and untidy.
--Graham
On 31/10/2009, at 9:01 AM, Sean McBride wrote:
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:...];
This is short and readable. But observers will be notified after each
setter. This could be a problem if intermediate states are not self-
consistent and could also lead to unnecessary redrawing. In the
general
case, I might not even know who is observing.
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?
I can see it getting ugly with more than 3 or so properties...
_______________________________________________
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