On 2009 Feb 24, at 10:25, Karolis Ramanauskas wrote:
Weird behavior: After adding a few objects whenever I move a mouse
over the
NSTableViews (or more accurately NSScrollViews enclosing them), the
NSManagedObjectContextObjectsDidChangeNotification is triggered!
Actually it
gets triggered by more than that, but I'm not doing anything to change
NSManagedObjectContext. Why would simply moving a mouse over certain
areas
of the before mentioned views trigger that event to fire?
I don't know Karolis, but you can find out yourself and tell us by
adding some NSLogs to your notification-observer's selector method...
- (void)myChangeObserver:(NSNotification*)n {
NSSet* insertedObjects = [[n userInfo]
objectForKey:NSInsertedObjectsKey] ;
NSSet* deletedObjects = [[n userInfo]
objectForKey:NSDeletedObjectsKey] ;
NSSet* updatedObjects = [[n userInfo]
objectForKey:NSUpdatedObjectsKey] ;
NSLog(@"inserted: %@", insertedObjects) ;
NSLog(@"deleted: %@", deletedObjects) ;
NSLog(@"updated: %@", updatedObjects) ;
...
}
Theoretically, you can also use that information to filter out changes
that you're not interested in.
But, just a warning. I originally had this grand plan which may be
similar to yours -- I was going to simply observe
NSManagedObjectContextObjectsDidChangeNotification, decode whatever
happened as I just advised you to do, and then implement all my
business logic in that observer. But it got to be more and more
painful. The deal-breaker was last week when I learned that -
[NSManagedObject changedValues] continues to include changed keys that
had already been noted in previous notifications, until the document
is saved. So I would decode the same change repeatedly. With that
discovery, I decided to bite the bullet and use KVO for most of the
changes instead of NSManagedObjectContextObjectsDidChangeNotification.
It turned out to be not so bad, after I invented (or maybe re-invented
-- someone will correct me) a little idea which I call "class
observers", implemented it in my NSManagedObject subclass, and made
all my managed object classes a subclass of this. Each subsubclass
(i.e. Employee, Recipe, whatever) overrides +classObservers, providing
a dictionary of "observer dictionaries", each one giving a keyPath,
observer, options and context. Whenever an instance object of this
subsubclass is created, it has all these "class observers" set
automatically (during -awakeFromInsert or -awakeFromFetch), and
whenever it's destroyed (-didBecomeFault in Core-Data-speak), these
observers are removed. So I'm not afraid of forgetting to remove
observers any more. Let me know if you want the code for this.
_______________________________________________
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
