Re: NSArrayController + KVO + Core Data Question
Re: NSArrayController + KVO + Core Data Question
- Subject: Re: NSArrayController + KVO + Core Data Question
- From: Quincey Morris <email@hidden>
- Date: Sun, 22 Aug 2010 23:28:29 -0700
On Aug 22, 2010, at 15:55, Ajay Sabhaney wrote:
> In my Core Data based application, I have an NSArrayController, and it was necessary for me to receive a KVO notification when either a new item was added to the array controller, or removed from the array controller.
Necessary for *what object* to receive a KVO notification? The only kind of object that should (normally) depend on a NSArrayController notification is something in your user interface -- a view, a control, a table, etc.
If it's a managed object or a controller in your data model that needs to know, it should be monitoring the property (relationship) in your data model that is actually being updated -- it should observe what the NSArrayController is bound to, not the NSArrayController itself.
> By looking in to some forums, I found out that I cannot do this by observing the arrangedObjects property in NSArrayController - some say this is a bug.
Observing arrangedObjects works, but in this case the KVO notification doesn't provide you with the object value before the change. This doesn't matter here, because you shouldn't be observing the NSArrayController anyway (see above).
> So instead, I binded the contentArray to a mutable array that I used to add and removed objects to or from. In addition, I added array accessors for the mutable array so that the KVO would work as expected.
You added this array property to what object?
> This now works beautifully, and I receive KVO notifications for object insertion and removal, as well as have the ability to see which objects were added or removed when observeValueForKeyPath:ofObject:change:context: is invoked.
>
> However, in doing this, I lost some of the functionality that came for free with Core Data: undo/redo, load/save, etc. I suppose this is because Core Data makes the changes to arrangedObjects (and the mutable array binded to contentArray is not touched), and I am no longer observing arrangedObjects.
Nope. That's completely wrong. It's because Core Data doesn't support array properties as modeled properties directly. If you add a non-modelled property to a managed object, it's not going to participate in "undo/redo, load/save, etc" because Core Data simply doesn't know what the property is.
Since you started by wanting to observe a NSArrayController, I assume there's already a *real* Core Data property -- the one that the NSArrayController was bound to -- a NSSet, not a NSArray. That set is what you should be observing.
> I manually added some undo/redo functionality in the array accessors, but now thinking about how to do loading documents. I would like to stay away from observing arrangedObjects, as then I would receive two KVO notifications for adding and removing objects in to the NSArrayController (one through the contentArray observation and one through the arrangedObjects observation).
>
> I also thought about subclassing NSArrayController so that addObject: performs a KVO notifications like so:
>
> [self willChange:NSKeyValueChangeInsertion valuesAtIndexes:indexes forKey:@"arrangedObjects"];
> [super addObject:object];
> [self didChange:NSKeyValueChangeInsertion valuesAtIndexes:indexes forKey:@"arrangedObjects"];
>
> This would alleviate the need to use the contentArray property. However, I am assuming this would generate two KVO events - the new insertion notification (NSKeyValueChangeInsertion), and the existing change notification (NSKeyValueChangeSetting). I would like to avoid this.
Nope. Forget about trying to program or subclass NSArrayController. It's the wrong approach.
I'm guessing, but you seem to have a managed object with a to-many relationship, and you want to be notified whenever anything is added to or removed from that relationship property. So, observe that property of the managed object, and you're done.
If there's something more complicated going on in the data model, your solution may be more complex, but throwing NSArrayController at the problem is highly unlikely to help with the solution.
_______________________________________________
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