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 (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to