Re: controller question
Re: controller question
- Subject: Re: controller question
- From: Ariel Feinerman <email@hidden>
- Date: Tue, 27 Sep 2011 22:18:23 +0300
Thank you for your letters. So it is good news. Do -insertObject: atIndex:,
-removeObject: or removeObjects: use KVO? I guess they do.
2011/9/27 Quincey Morris <email@hidden>
> On Sep 27, 2011, at 07:40 , Keary Suska wrote:
>
> On Sep 26, 2011, at 9:22 PM, Quincey Morris wrote:
>
> On Sep 26, 2011, at 19:03 , Ariel Feinerman wrote:
>
>
> if I use persistence NSMutableArray as content array in NSArrayController
> so
>
> [arrayController setContent: m_array]; will controller copy one or retain?
>
>
> The array controller will *observe* the array, not copy it.
>
>
> I will take your word for how the controller is internally managing its
> content as I haven't inspected it, but although it is true that the
> controller should not copy the object (otherwise the docs should require
> that the content object conform to NSCopying), how the controller content is
> internally managed is not documented and shouldn't be relied on. Setting
> content is the same as setting any object property, and how the object is
> managed is no business of the setter.
>
>
> Actually, I was using "observe" a bit loosely, because I didn't want to use
> "retain" in response to the question, because *that* would certainly be an
> implementation detail. I should have said that the array controller just
> keeps a reference to the array.
>
> However, since part of an array controller's API contract is to track
> KVO-compliant changes to the content array, I'm pretty sure it *does*
> observe the object, and KVO-observe it too.
>
> So every deletion or addition in the controller will come back to origin.
>
>
> Yes.
>
>
> Again, this isn't guaranteed since it relies to how the controller may be
> managing its content.
>
>
> Every deletion ([NSArrayController removeObject…]) or addition
> ([NSArrayController insertObject…] or [NSArrayController insertObject…])
> *will* cause a corresponding deletion or addition in the content array,
> again by API contract. That's what I understood "come back to origin" to
> mean.
>
> Or we must synchronize one or get from controller to write to url?
>
>
> No, you don't have to either of those things.
>
>
> However, if you modify the array directly, you have to do it KVO
> compliantly, or the array controller won't see the change.
>
>
> Again, same issue. When not using bindings, you shouldn't rely on the
> behavior, even if it happens to work (for now)…
>
>
> There are two facts that are well known, are unquestioningly used by many,
> many applications and are either explicitly or implicitly part of the array
> controller API contract.
>
> 1. Changing the data model array KVO compliantly *will* be reflected in the
> array controller (in 'selection', 'selectedObjects', 'arrangedObjects',
> etc).
>
> 2. Changing the content via the array controller *will* change the data
> model array KVO compliantly (so that other observers of the data model array
> will be notified).
>
> Therefore, if you're about to write the data model array to some file at
> some URL, it isn't necessary to "get" anything from the array controller or
> to perform some synchronization operation first.
>
> In sum, if you want synchronization without glue code, use bindings. If you
> don't need to manage the array outside of the controller you can retrieve
> the array contents when you need it as well...
>
>
> The point is that an array controller is a controller, not a collection.
> Conceptually it does *not* contain the objects in the content array; instead
> it *manages* the content array. Note that an array controller does not
> itself have an array property for the content. Its "content" property is an
> object property, not an array property. It certainly has some array
> properties of its own ('selectedObjects', 'arrangedObjects'), but these are
> derived properties that don't necessarily contain all of the content
> objects.
>
>
>
--
best regards
Ariel
_______________________________________________
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