Cocoa Tutorial: Get The Most Out of Key Value Coding and Observing

by Marcus Zarra

Key Value Observing/Key Value Coding (KVO/KVC) is probably one of the most powerful and most under-utilized features of Objective-C. Here are a couple of examples of how to get the most out of it

When a call is made on an object through Key Value Coding such as [self valueForKey:@”someKey”], numerous attempts are made to resolve the call. First, the method someKey is looked for. If that is not found then the iVar someKey is looked for. If neither of those are found, then one last attempt is made before presenting an error. That last attempt is a call to the method -(id)valueForUndefinedKey:. If that method is not implemented then an NSUndefinedKeyException is raised.

valueForUndefinedKey: is designed so that when you request a value from an object using -(id)valueForKey: the object has a last chance to respond to that request before an error occurs. This has many benefits and I have included two examples of those benefits in this post–Core Data Parameters and Data Formatting.

Core Data Parameters

One of the ways in which I use this method is by making a singleton object that responds to parameter requests. This allows any part of the application to ask the singleton for parameters and get them back in a clean block of code rather than having to build an NSFetchRequest each time a parameter is needed. This allows others parts of the application to make simple calls like:

and avoid messy calls like this:

Worse is when I want to set a parameter value:

As you can see, after the 5th or 6th time of plugging that block of code in just to get a parameter out of the Core Data store — it gets old. Therefore, I turned to KVC/KVO.

Not: These parameters are different from using NSUserDefaults. NSUserDefaults are great for application level parameters. However, if you need to store document level parameters then NSUserDefaults is the wrong place.

Instead of writing tons of code to access the Core Data Stack, parameter access can be centralized in a singleton. That singleton can then be exposed to the entire application and any portion of the application can then request or set parameters. The parameters are then read and set via the valueForUndefinedKey: and setValue:forUndefinedKey: methods as shown:

As you can see this code is pretty much identical to the blocks listed above. However, now it is only in one place in the code and not littered around the entire application. In addition, if I ever decide to move the location where parameters are stored, I only have to alter that code once. By using the valueForUndefinedKey: method, I can avoid having to alter the code every time I want to store another parameter. Lastly, since the parameter key is considered a value on the singleton object, I can observe it and receive notifications when it changes. This allows me to hook IB bindings directly to the singleton.

Date Formatting

While I do not have an axe to grind against dates in Cocoa, in my opinion the formatters could use some work. Localizing dates directly in Interface Builder (along with currency formatters) is a hit or miss situation. For the display of dates, I simply gave up. I can get the localizers to work just fine in code and I can manually set the formatters for display but there is an easier way to do it.

As part of my modified Core Data Stack, I have a parent class that subclasses NSManagedObject. All of my objects then extend this subclass. This (super/sub)class allows me to load in some interesting things such as overriding the valueForUndefinedKey: method. In this case, however, I am doing some trickery on the key itself.

As an example, most of my data objects have a value called ‘createDate’ that is set in the awakeFromInsert method. This attribute is stored in Core Data as an NSDate. To get around the issues with the date formatters in InterfaceBuilder, I overrode the valueForUndefinedKey: method in the ZDSManagedObject as follows:

With this code in place, I can set the createDate binding in Interface Builder to createDateLocalString and the field will be populated with the create date formatted properly for the locale. I can also set the binding to createDateLocalDTString and receive the date and time formatted properly for the locale.


There is a lot more than can be done with Key Value Coding and Observing and the undefinedKey methods. These two examples are just a start of what can be done to easily and cleanly roll up code that is reused frequently.


joo_p23 says:

may i suggest using a wordpress template that is wider so that you don’t have to scroll horizontally on the code examples.