Re: Bindings vs MOC change notification

2009-11-14 Thread jonat...@mugginsoft.com
On 14 Nov 2009, at 02:11, David Catmull wrote:

> In my Core Data app, I have objects with a date property, and I want to 
> maintain a list of all years that I have objects in. I'm having trouble 
> settling on an approach.
> 
> Currently, I'm listening for 
> NSManagedObjectContextObjectsDidChangeNotification. This is working fine for 
> additions and deletions, but it's harder for changes, mainly because I don't 
> know the old value. If I did, I could check if the old year still has any 
> other objects in it. As it is I have to refresh the whole list. I also get 
> more notifications than I need, since I only care about date changes on this 
> one entity.
You could cache the old year in a transient property and detect the change that 
way.

> 
> Another option is to use KVO so I can be notified only of date changes. I'm 
> assuming that registering as an observer for potentially thousands of Core 
> Data objects doesn't carry too much overhead. The down side is that if lots 
> of objects change at once, I get lots of individual callbacks, and I worry 
> that that would be a bottleneck.
> 
I find it hard to get a combination of KVO, bindings, CoreData and undo that 
works cleanly and efficiently.
I faced a perhaps similar situation and implemented a system of coalescing 
notifications.

My NSManagedObject subclass raises manual KVO notifications for use in bindings 
put each property modified also calls subclass method 
-postPropertyChangeNotification: (see below).
This sends a single notification for each modified keypath at the end of the 
runloop.
This means you get one notification regardless of how many changes there are.
So regardless of how many objects get their Year property modified you get one 
notification and can form your year list.

Another subclass method +keyPathsThatDoNotEnqueueCoalescingNotifications 
provides a way of overriding the coalescing for individual keypaths.

One point would be to consider if you want to support undo.
CoreData will undo your changes to your data model and post KVO notes but it 
won't access your model accessor's during undo.
Its possible to build a series of observations and notifications that works 
when doing, but fails when undoing.
So if you want undo support I would try to implement it now.

To get undo support to function so that the GUI was always in sync with the 
model i found it necessary to listen for 
NSManagedObjectContextObjectsDidChangeNotification as well.

/*
 
 post property change notification

 provides an alternative to observing all model properties
 
 */
- (void)postPropertyChangeNotification:(NSString *)keyPath
{   
// build our notification
NSDictionary *userInfo = [NSDictionary 
dictionaryWithObjectsAndKeys:keyPath, @"keyPath", nil];
NSNotification *notification = [NSNotification 
notificationWithName:@"MGSUnitEntryUpdated" object:self userInfo:userInfo];

// the default is that we shall coalesce these notifications
NSUInteger coalesceMask = NSNotificationCoalescingOnName;

// determine any keyPaths that require distinct notifications
// eg: date as the receiver of the notification treats it differently 
to all other keypaths
NSSet *nonCoalescingKeypaths = [[self class] 
keyPathsThatDoNotEnqueueCoalescingNotifications];
if ([nonCoalescingKeypaths containsObject:keyPath]) {
coalesceMask = NSNotificationNoCoalescing;
}

// enqueue the notification
[[NSNotificationQueue defaultQueue] enqueueNotification:notification 

postingStyle:NSPostASAP // run at end of runloop

coalesceMask:coalesceMask 

forModes:nil];
}

/*
 
 keypaths that do not enqueue coalescing notifications
 
 */
+ (NSSet *)keyPathsThatDoNotEnqueueCoalescingNotifications
{
NSSet *keyPaths = [super 
keyPathsThatDoNotEnqueueCoalescingNotifications];

// we require that separate uncoalesced notifications are sent for 
these property changes
keyPaths = [keyPaths setByAddingObjectsFromSet: [NSSet setWithObjects: 
@"date", nil]];

return keyPaths;
}


> Recommendations? Other options?
> 
> Thanks,
> 
> -- 
> David Catmull
> uncom...@uncommonplace.com
> http://www.uncommonplace.com/
> 
> ___
> 
> 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/jonathan%40mugginsoft.com
> 
> This email sent to jonat...@mugginsoft.com

___

Cocoa-dev mai

Re: Bindings vs MOC change notification

2009-11-13 Thread Kyle Sluder
On Fri, Nov 13, 2009 at 6:11 PM, David Catmull
 wrote:
> Currently, I'm listening for 
> NSManagedObjectContextObjectsDidChangeNotification. This is working fine for 
> additions and deletions, but it's harder for changes, mainly because I don't 
> know the old value. If I did, I could check if the old year still has any 
> other objects in it. As it is I have to refresh the whole list. I also get 
> more notifications than I need, since I only care about date changes on this 
> one entity.

1) You could model the years as well.  To crib Michael Jurewitz's
theme from the iPhone tech talks, "Normalize as much as possible, then
denormalize as necessary."
2) There are data structures you can use to make it relatively
efficient even when you don't know the previous value.  You're already
given the changed-object set as it is, that's the best optimization
you can make.
3) The notification approach will eventually be much faster than the
KVO approach.  "Eventually" is to be determined.

For your case, think of # of objects / # of possible years.  I can't
imagine you have more than a 10 year range?  Just keep an array of
sets around and add/remove as dictated by the change notification.

--Kyle Sluder
___

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


Re: Bindings vs MOC change notification

2009-11-13 Thread Jerry Krinock
First of all, after reading your message, I believe the subject of  
your message should be "KVO vs MOC change notification".  But we all  
get our terms mixed up once in awhile :)


On 2009 Nov 13, at 18:11, David Catmull wrote:


Recommendations? Other options?


I believe there is no easy answer for this.  The two options you  
mentioned have issues -- not the performance issues you expect, but  
things that don't work.  I therefore use a third option, which is to  
implement custom setters so I can hook into them and post my own  
notification.


The additional issues which you have not discovered yet are explained  
in these threads:


http://lists.apple.com/archives/Cocoa-dev/2009/Feb/msg01698.html
http://lists.apple.com/archives/Cocoa-dev/2009/Feb/msg01814.html
http://lists.apple.com/archives/cocoa-dev/2009/Aug/msg2.html

___

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


Bindings vs MOC change notification

2009-11-13 Thread David Catmull
In my Core Data app, I have objects with a date property, and I want to 
maintain a list of all years that I have objects in. I'm having trouble 
settling on an approach.

Currently, I'm listening for 
NSManagedObjectContextObjectsDidChangeNotification. This is working fine for 
additions and deletions, but it's harder for changes, mainly because I don't 
know the old value. If I did, I could check if the old year still has any other 
objects in it. As it is I have to refresh the whole list. I also get more 
notifications than I need, since I only care about date changes on this one 
entity.

Another option is to use KVO so I can be notified only of date changes. I'm 
assuming that registering as an observer for potentially thousands of Core Data 
objects doesn't carry too much overhead. The down side is that if lots of 
objects change at once, I get lots of individual callbacks, and I worry that 
that would be a bottleneck.

Recommendations? Other options?

Thanks,

-- 
David Catmull
uncom...@uncommonplace.com
http://www.uncommonplace.com/

___

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