Should I use Cocoa bindings for my latest project?

Question

I'm starting a project which I think would benefit from bindings (I've got a source list table, several browser views, etc), but I think it would also be quite doable, and perhaps more understandable, without them. From my limited experience I've found bindings to be difficult to troubleshoot and very "magic" (e.g. it's difficult to insert logging anywhere to figure out where stuff is breaking, everything either works or it doesn't).

Is this just my inexperience talking (in which case I could sit down and spend some time just working on my understanding of bindings and expect things to start becoming clearer/easier) or would I be better off just writing all the glue code myself in a manner which I was sure I could understand and troubleshoot.

Answer 1

Bindings can seem magical in nature. To understand the magic behind bindings, I think one must understand KVC/KVO thoroughly. I really do mean thoroughly.

However, in my case (new to Obj-C -- 9 months), once I got KVC/KVO bindings was a thrill. It has significantly reduced my glue code and made my life significantly easier. Debugging bindings became a case of making sure my key-value changes were observable. I find that I am able to spend more time writing what my app is supposed to do rather than making sure the view reflects the data.

I do agree though that bindings is highly intimidating at first.

Answer 2

Use Bindings.

Note that you must follow the MVC pattern to get the most from bindings. This is easier than it seems, as Cocoa does almost everything for you nowadays:

1. View: NSView and subclasses (of course), NSCell and subclasses, NSWindow and subclasses
2. Controller: NSController and subclasses (especially NSArrayController)
3. Model: Core Data

If you're not going to use Core Data, then you get to roll your own model objects, but this is easy. Most of these objects' methods will be simple accessors, which you can just @synthesize if you're targeting Leopard.

You usually can't get away with not writing any code, but Bindings can enable you to write very little code.

Recommended reading:

• Key-Value Coding (KVC) Programming Guide
• Key-Value Observing (KVO) Programming Guide
• Model Object Implementation Guide
• KVC Accessor Methods (part of the aforementioned KVC Programming Guide) and my complete list of KVC-compliant accessor selector formats

Answer 3

My general approach is to start out as much as possible using bindings and see how things go. However, if a particular interface element start to become problematic using bindings, or more effort than it's worth, then I don't hesitate to fall back to using more traditional methods (e.g. data sources, actions) when it makes sense. I've found these things can be pretty hard to predict ahead of time, but I think favoring bindings is better in the long run, as long as you don't get too dogmatic about sticking with them in situations when they don't provide any benefit.

Answer 4

After a while of working with Bindings I've found that it's not magic at all, thought it is sufficiently advanced technology. Debugging a bound interface takes different techniques than a glued interface, but once you have those techniques, the advantages in terms of reuse, maintainability and consistency are IMO significant.

Answer 5

It seems like I use bindings, KVO and data source methods all about equally in my applications. It really depends on the context. For example, in one of my projects I use bindings just about everywhere except the main window's outline view, which is complex enough that I wouldn't want to even try to fit it into an NSTreeController. At the same time I also use KVO to reload UI objects and track dependancies in my model objects.

The important thing to keep in mind when learning advanced Cocoa topics like Bindings or Core Data is that you must understand all the technologies behind them; everything from data source protocols, notifications KVO, and so one. Once you've had enough experience working with them to know how the "magic" works, you'll be able to integrate the higher level stuff into your application with ease.

In your particular case, you'll have to decide if it's worth the extra time to learn bindings on top of developing your application. If possible, it might benefit you to develop a simplified prototype of your application using bindings, so you know how to best fit the pieces together when you start the actual project.

Answer 6

For the curious, I did end up using bindings and after a couple of days they suddenly just started "making sense". So I would definitely recommend just going ahead and taking the time to learn them.

I also found the advice of Brian Webster quite helpful, as I did indeed end up doing a handful of things the old fashioned way either because bindings couldn't do what I wanted or because it would have been prohibitively complicated to do what I needed using bindings.

Answer 7

My opinion is that yes, you should adopt bindings; the technology is well-understood and stable now, and it's worth doing for the amount of code you no longer need to write. When I first switched to bindings, I had quite a bit of trouble with getting the lifetime of observing and observed objects to match up, and with UI breakages because it was observing a valid object, but the incorrect one. Once you've seen those problems a couple of times, knowing how to avoid them and how to spot them if they do appear becomes straightforward. Ish. I still wish for "this event here caused this update here" traces in the debugger, but I'm still glad I made the move.