The Role of Bindings

Emails sent to Cocoa Dev Central and various mailing lists suggest people are a bit unclear on how Cocoa Bindings relates to views. Using bindings to supply a table view with data does not prevent you from using delegate methods, datasource methods or using a custom subclass.

A lot of emails that I get are of the nature "how do I save user data in bindings app?" Or "how to I interpet key events in a table view that uses bindings?" These issues are independent of bindings. You can just do whatever you would do in a non-bindings app. Cocoa is designed to be modular in this way.

At the other extreme, there are people that are hesitant to use bindings because it uses a different model. It seems easier to just write datasource methods. It's true that in the grand scheme of things, the amount of datasource code to populate a table is small. But that's a rather simplistic example.
                                                                                                                                        
Looking at the bigger picture, it's pretty common to have UI that allows you to enter data and have it show up in a popup somewhere. Or you have multiple tables to keep in sync and one of them can be filtered by a keyword search.

Independently, these aren't all that difficult to pull off using traditional methods. It's when you need them to all work together seamlessly that Cocoa Bindings really shines. This is what things like NSArrayController and KVO were designed for. This stuff is there to help you! Not to mention applications that use bindings can actually be faster than those that do not.

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.