views:

3663

answers:

3

I'm used to coding Java Swing UIs, and in those if you have some properties that change, and you want your UI to update, you would implement the observer/observable pattern. In Java you do this normally by having your class maintain a list of listeners that it notifies of different events.

I've played with Objective-C on the Mac, and that has KVC and binding which seems to work very nicely, and requires less code. The iPhone SDK doesn't seem to have this functionality though, so my question is: If I have a class that holds data that changes, what's the best way for me to register a UI component with that class so that it can be notified of changes in the data that it needs to display?

A: 

That's not generally the way that it's done. Take a look at the discussion here, in particular the link to the Apple documentation.

If you still want to do it the way you say you do, it's not particularly hard to implement something like bindings "by hand". You'd just create a "binding" object that knows how to subscribe to changes, and connects to a property of a view.

To actually answer how it's done - normally, you have a controller object that monitors the state of the model (acting something like an Observer), and updates the view object(s) as necessary.

Mark Bessey
I'm just asking what way is best, and giving a JAVA example. I'm not particularly fussed if the Objective-C way is totally different, I just want to know what it is.
rustyshelf
Got it. I edited my answer to make it clearer what I was talking about.
Mark Bessey
+16  A: 

There are two built-in ways of doing observation in Cocoa: Key-Value Observing and notifications. In neither system do you need to maintain or notify a collection of observers yourself; the framework will handle that for you.

Key-Value Observing (KVO) lets you observe a property of an object — including even a property that represents a collection — and be notified of changes to that property. You just need to send the object -addObserver:forKeyPath:options:context: passing the object you want to receive updates, the key path of the property (relative to the receiver) for which you want to receive updates, and the types of updates you want to receive. (There are similar methods you can use if you want to observe a property representing a collection.)

Notifications are older and heavier-weight. You register with an NSNotificationCenter — usually the default center — an object and selector pair to be passed a notification when an event occurs. The notification object itself can contain arbitrary data via its userInfo property, and you can choose to observe all notifications of a specific name rather than those that apply to a particular object.

Which should you use in any particular case? In general, if you care about changes to a specific property of a specific object, use Key-Value Observing. That's what it's designed for and it's intentionally lightweight. (Among other uses, it is the foundation on which Cocoa Bindings are built.) If you care about a change in state that isn't represented by a property, then notifications are more appropriate.

For example, to stay in sync when the user changes the name of a model object, I'd use KVO. To know when an entire object graph was saved, I'd use notifications.

Chris Hanson
Great answer - but with the KVO approach, how do you remove an observer that has registered with many objects? I thought (wrongly) that KVO used notifications under the hood - but I don't think it does. Thus after using addObserver:X forKeyPath:..., if you try to later do: [[NSNotificationCenter defaultCenter] removeObserver: X] this doesn't work? It seems to imply that you have to keep a separate list of all objects that X is observing so you can remove the observation. Or am i missing something?
TimM
+1  A: 

I also found that you can do:

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(_handleWhateverChange) name:@"whateverChange" object:nil];

To register for change events, and

[[NSNotificationCenter defaultCenter] postNotificationName:@"whateverChange" object:nil];

To fire them. I might be a N00b but I just couldn't get the observer for key path thing to work for me.

rustyshelf