• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Core Data design question: receiving KVO notifications of partially mutated objects
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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: Kiel Gillard <email@hidden>
  • Date: Sat, 31 Oct 2009 09:46:03 +1100

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 (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


References: 
 >Core Data design question: receiving KVO notifications of partially mutated objects (From: "Sean McBride" <email@hidden>)

  • Prev by Date: Re: Scripting Bridge running method passing an array
  • Next by Date: Re: Scripting Bridge and Xcode rule problem
  • Previous by thread: Core Data design question: receiving KVO notifications of partially mutated objects
  • Next by thread: Re: Core Data design question: receiving KVO notifications of partially mutated objects
  • Index(es):
    • Date
    • Thread