Re: NSArrayController - error inserting object at arranged object index N
Re: NSArrayController - error inserting object at arranged object index N
- Subject: Re: NSArrayController - error inserting object at arranged object index N
- From: Quincey Morris <email@hidden>
- Date: Thu, 23 Jun 2016 09:51:41 -0700
- Feedback-id: 167118m:167118agrif8a:167118sqZWfVPZxk:SMTPCORP
On Jun 23, 2016, at 08:32 , Jonathan Mitchell <email@hidden> wrote:
>
> It would seem there is some intention here according to the header:
>
> - (void)insertObject:(id)object atArrangedObjectIndex:(NSUInteger)index; // inserts into the content objects and the arranged objects (as specified by index in the arranged objects) - will raise an exception if the object does not match all filters currently applied
>
> -addObject: obviously calls - insertObject: atArrangedObjectIndex: (the exception stack trace agrees)
>
> The logic of this is a bit puzzling …
Why is this puzzling? Arranged objects are *necessarily* filtered objects, so a would-be-filtered-out new object has no meaningful arranged object index. You could perhaps argue that ‘addObject:’ shouldn’t use ‘insertObject:atArrangedObjectIndex:’ for exactly this reason, but since the current behavior is documented in the header it seems that the API has already picked its functional horse to run.
> My workaround was to set controller.clearsFilterPredicateOnInsertion == YES and reset the filterPredicate following -addObject:
>
> It might be possible to subclass NSArrayController …
There’s no need to work around at all. The correct, straightforward solution is to update the content array (i.e. the unfiltered objects being managed via the array controller) directly in a KVO compliant manner, using ‘mutableArrayValueForKey:’.
The way you’ve shown your setup code fragment suggests you’re thinking of the content array being “inside” the array controller. I would suggest this is the wrong conceptualization. It’s much better to think of it is an indexed collection property of your data model, with the array controller merely being a glue object between parts of the MVC design.
Editorializing a bit further, if you’ll forgive me …
Your problem is a good example of why IMO it’s poor practice to use array controllers in code, except where you’re absolutely forced to. NS…Controller works fine as a standard connector piece between code and IB-based objects, but when you try to use it as API within a code design, you quickly run into inscrutable or inflexible behavior. You’ll end up writing more code *around* the NS…Controller than it would take to do what it does directly.
_______________________________________________
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