Wednesday, February 4, 2009

KVO and the iPhone SDK

One of the common misconceptions about the iPhone SDK is that it doesn't support Key-Value Observation, or KVO. I suspect that the reason for this misconception is that the most conspicuous uses of KVO in Cocoa—Core Data and Bindings—has not been brought to the iPhone.

Now, KVO is not used much in the iPhone SDK. I don't think we ever mentioned it in the book. But it is available. The NSKeyValueObservation informal protocol is part of the iPhone SDK. It's completely opt-in on the iPhone, however. When you create an application project in Xcode, none of your objects are observing any other. Well, there might be some KVO being used behind the scenes (in fact, I suspect there is), but most people won't encounter it.

But, any Objective-C object can register to receive notifications when a property of another object is changed. An object can even observe itself. Here is how you register to observe an object. In this example, theObject is being told to notify theObserver any time the property called name

[theObject addObserver:theObserver forKeyPath:@"name" options:0 context:nil];

Now, theObserver just has to implement this method to find out when theObject.name changes:

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context
{

}

This is really quite a flexible bit of functionality. When registering as an observer, you can use the options: argument to tell the KVO system whether you want the old value, the new value, or the original value of the property being changed. You can even use keypaths, not just keys. So, if name weren't a string, but were actually another object with component string properties called firstName and lastName, we could pass in a key path of @"name.firstName" to indicate that we want to get notified when the firstName property of name changes.

This is some pretty cool stuff. I used this functionality recently in SQLitePersistentObjects to set the dirty flag on objects so that they only get saved when something has changed since it was loaded, or the last time it was saved. In the init method, I simply iterate through the properties of the object (including those declared in superclasses), and for any property that isn't read-only, I register it as an observer of itself. Then, when the object gets notified of any change, I mark the object as dirty, which lets me know to actually save the data when the save method is called.

In the future, I may implement a more sophisticated version that only updates the actual properties that are dirty rather than saving the whole object.

No comments:

Post a Comment