Re: NSArrayController not rearranging correctly
Re: NSArrayController not rearranging correctly
- Subject: Re: NSArrayController not rearranging correctly
- From: Quincey Morris <email@hidden>
- Date: Thu, 19 Jul 2012 01:11:10 -0700
On Jul 18, 2012, at 23:22 , Markus Spoettl wrote:
> The array controller is used by views directly, they bind to arrangedObjects (like in the example). Since when is it recommended to insert an intermediate object between table view and NSArrayController?
Ugh, I didn't pay enough attention to what you actually said. Yes, you can't just prevent the KVO notifications getting through when you're using bindings.
So let me rephrase and see if I can say something sensible…
To use bindings at all, you're basically buying into the idea that your bound view can reasonably respond to each KVO notification individually (from the data model, via the binding). You have no real control over the timing and granularity** and [non]redundancy of the KVO notifications. If the response is very expensive, bindings are not a reasonable solution.
If the response to the notifications is simply to redraw, and redrawing is expensive, one way out is to move the expensive calculation into a background thread, leaving the redrawing itself to be quite cheap. This is the sort of "concurrent user interface" approach that's more usual in iOS apps, with the effect that content "pops" into view asynchronously. (There's a session on this in the 2012 WWDC videos.)
Another way out is to bind the view to an intermediate object, such as a window controller, which is more careful about when it triggers the KVO notifications that affect the view.
A third way is to use a data source/control action approach, instead of using bindings. This is a perfectly fine alternative, and is *better* than bindings when you need a more controlled form of communication between the source and the view.
In the latter two approaches, you might end up asking yourself if using array controllers at all makes sense. It's easy to end up writing more code working around array controller assumptions than just writing glue code that really works. The main benefits of array controllers are (a) sorting; (b) filtering; and (c) oversight of the NSEditor/NSEditorRegistration protocols. Chances are you can do those things yourself without much trouble.
FWIW
** For example, it would be perfectly legal, when you change the array controller's filter predicate, for there to be pairs of KVO notifications, one specifying just object deletions and one specifying just object insertions. If you've been getting a single generic "property changed" notification, that's almost more by luck than by design.
_______________________________________________
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