Re: controller question
Re: controller question
- Subject: Re: controller question
- From: Quincey Morris <email@hidden>
- Date: Tue, 27 Sep 2011 10:29:59 -0700
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.
_______________________________________________
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