On 31/10/2009, at 9:01 AM, Sean McBride wrote:
Hi all,
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?
In situations like these I personally tend to avoid KVO. It's too
noisy and in some cases incurs too much of a performance overhead.
But, I have a solution which I describe below.
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...
Perhaps make a property that represents the state of the value these
dependent properties contribute to? For example, is it possible to
have a "requires redraw" property of the Rectangle? You could simply
change the value of that property (in the overridden setColor:,
setWidth:, setLength: methods *sigh*) to indicate the Rectangle object
requires a redraw? Then, when a third party wants the value of the
dependent property, you can recalculate it. In the given example, the
rectangle will only re-draw when it's needed.
Just a few ideas, not sure if they're of any help. They're not coming
from a Core Data perspective either, just a general one - but I
wouldn't expect it to be much different?
Kiel
_______________________________________________
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
