Why would I use NSObjectController?

Question

Although I have searched for many information about Cocoa Bindings, I still remain relatively unsatisfied with information I have and got. It seems that topic is somewhat troublesome for many and many are just avoiding this pattern, which I believe should not be.

Of course, it may seem that bindings are sometimes too complicated or perhaps designed with too much overhead...

However, I have one very direct and specific question: Why is NSObjectController needed if I can establish bindings directly?

For example, the code:

[controller bind:@"contentObject" toObject:self withKeyPath:@"numberOfPieSlices" options:nil];

[slicesTextField bind:@"value" toObject:controller withKeyPath:@"content" options:nil];
[stepperControl bind:@"value" toObject:controller withKeyPath:@"content" options:nil];

Does exactly the same as:

[slicesTextField bind:@"value" toObject:self withKeyPath:@"numberOfPieSlices" options:nil];
    [stepperControl bind:@"value" toObject:self withKeyPath:@"numberOfPieSlices" options:nil];

In my case here, we are talking about property of the class inside which everything is happening, so I am guessing the need for NSObjectController is when:

• key path for controller is object and binding of other controls is needed to its properties, not to its value as with primitives and wrappers around them is the case (numberOfPiesSlices in my case is NSInteger)

• or when binding is needed from other outside objects, not only between objects within one

Can anybody confirm or reject this?

Answer 1

One of the benefits/points of bindings is to eliminate code. To that end, NSObjectController etc. have the benefit that they can be used directly in interface builder and set up with bindings to various UI elements.

Bindings only represent part of the functionality on offer. The *ObjectController classes can also automatically take care of a lot of the other more repetitive controller (as in Model, View, Controller) code that an application usually needs. For example they can:

• connect to your core data store and perform the necessary fetches, inserts and deletes
• manage the undo / redo stack
• Pick up edited but not committed changes to your UI and save them (e.g. if a window is closed while focus is still on an edited text field - this was a new one to me, I found it from mmalc's answer in the thread below).

If you're doing none of this, then it probably isn't worth using NSObjectController. Its subclasses (NSArrayController etc) are more useful.

Also see here for a discussion of your exact question!

Answer 2

Why is NSObjectController needed if I can establish bindings directly?

I read this question a few days ago while looking for some information about NSObjectController, and today while continuing my search, I found the following passage which seemed relevant to the question:

There are benefits if the object being bound to implements NSEditorRegistration. This is one reason why it’s a good idea to bind to controller objects rather than binding directly to the model. NSEditorRegistration lets the binding tell the controller that its content is in the process of being edited. The controller keeps track of which views are currently editing the controller’s content. If the user closes the window, for example, every controller associated with that window can tell all such views to immediately commit their pending edits, and thus the user will not lose any data. Apple supply some generic controller objects (NSObjectController, NSArrayController, NSTreeController) that can be used to wrap your model objects, providing the editor registration functionality.

Using a controller also has the advantage that the bindings system isn’t directly observing your model object — so if you replace your model object with a new one (such as in a detail view where the user has changed the record that is being inspected), you can just replace the model object inside the controller, KVO notices and the binding updates.