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 s...@rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada _______________________________________________ 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
