Lazy Loading of KVO Observed Properties

While in one of the labs at WWDC, I helped someone out with a deceptively tricky bit of code. The gist is this: how do you handle the case of a lazily-loaded property which has Key-Value Observer clients? It may not be clear why this is challenging, so let's take a quick look.

First, by "lazy loading," I mean essentially "load on demand." If setting up a property is particularly expensive — such as loading a large file from disk — you may want to delay doing that work until the property is actually needed. The idea is to keep the application responsive and not waste cycles and memory on something that the user may not actually use during a given session of using your app.

In this case, the property we wanted to load lazily was an image. Initially, the code looked like this (note this is not garbage collected Objective-C 2.0 code):

- (NSImage*)myImage
{
  if ( myImage == nil )
  {
    [self setMyImage:[self fetchImageFromDisk]];
  }  
  return myImage;
}

- (void)setMyImage:(NSImage*)aValue
{
  NSImage* oldMyImage = _myImage;
  _myImage = [aValue retain];
  [oldMyImage release];
}

This all looks reasonable, but there's a subtle issue here. If there's a KVO observer (which is used for Cocoa Bindings), the very act of using the setter will generate a call to the getter. The reason for this is that observers may want to know what the previous value was in addition to the new value — which is helpful for things like Undo.

If you run through the logic in your head, you might discover how this plays out in real life:

-myImage
    -setMyImage
        -myImage
            -setMyImage
                -myImage
                    -setMyImage

And so on into infinity. Remember, each time you call -setImage, the KVO observers may first want to know what the existing value is. Because of the way this code is setup, the getter is called recursively, and the instance variable never gets an actual value set. It just stays at nil, so it keeps trying to rebuild the image and spirals into recursion.

So we need some catch in the code to realize that we're already trying to regenerate the image from a call higher in the stack, and just let the code pass right through. Here's the solution we came up with:

- (NSImage*)myImage
{
  static isBeingSet = NO;
  if ( myImage == nil && isBeingSet == NO )
  {
    isBeingSet = YES;
    [self setMyImage:[self fetchImageFromDisk]];
    isBeingSet = NO;
  }  
  return myImage;
}

- (void)setMyImage:(NSImage*)aValue
{
  NSImage* oldMyImage = _myImage;
  _myImage = [aValue retain];
  [oldMyImage release];
}

The setter is exactly the same. The only addition is a static BOOL variable that says we're already in the process of setting the value, so no need to do it again. In Objective-C (and C in general), a static variable keeps its value even across multiple calls to the same method. It's like the method itself has an instance variable.

The end result of this is that the first call to -myImage will generate a legitimate check on the value of myImage. Once we decide the image needs to be loaded, we set the isBeingSet static variable to "YES", so that when we call -setImage and KVO wants to fetch the existing value, we just return nil. After the value is set, we set isBeingSet back to "NO" and return the actual image.

You might wonder why we don't just set the instance variable directly in the getter. In other words:

- (NSImage*)myImage
{
  if ( myImage == nil )
  {
    myImage = [[self fetchImageFromDisk] copy];
  }  
  return myImage;
}

This is an inelegant solution because it breaks the Key-Value Observing contract. If you set instance variables directly, KVO has no way of knowing they've changed. Even though that would temporarily fix the recursion issue, we might run into other elusive bugs further down the road. In addition, it might be that the setter has some custom logic, such as setting a particular size before actually setting the value. By setting the instance variable directly, we'd be breaking that logic.

Keep in mind that none of this solves the broader issue of thread safety. If you have multiple threads accessing myImage, you would want to set up proper NSLocks or some other generalized thread-safe solution.

Comments Temporarily Disabled

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