Cocoa

F#$% Nil Outlets

Andy Kim — Sun, 15 Jun 2008 22:46:49 -0700

This is for you cocoa developers out there.

A common error I keep making is forgetting to set an outlet in Interface Builder. Usually I catch the problem pretty quickly but once in a blue moon it can leave me scratching my head for too long a period of time to confess here.

I love problems that can be engineered away and after making this mistake yet again, I decided to solve it once and for all. I'm sharing the solution because it has worked out splendidly.

The following code parses your header file for outlets and makes sure that they are set at runtime.

In a header file:

#ifndef RELEASE
#define PFValidateOutlets(obj) PFValidateOutlets_(obj, [NSString stringWithFormat:@"%s", __FILE__], nil)
#define PFValidateOutletsInFile(obj, header) PFValidateOutlets_(obj, [NSString stringWithFormat:@"%s", __FILE__], header)
#else
#define PFValidateOutlets(obj)
#define PFValidateOutletsInFile(obj, header)
#endif

In a .m file:

#import <objc/runtime.h>

void PFValidateOutlets_(id obj, NSString *filepath, NSString *headerFilename)
{
#ifndef RELEASE
    if (headerFilename) {
        filepath = [[filepath stringByDeletingLastPathComponent] stringByAppendingPathComponent:headerFilename];
    }
    if (![filepath hasSuffix:@".h"]) {
        filepath = [NSString stringWithFormat:@"%@.h", [filepath stringByDeletingPathExtension]];
    }

    // Parse the outlets
    if ([[NSFileManager defaultManager] fileExistsAtPath:filepath]) {
        NSString *source = [NSString stringWithContentsOfFile:filepath];
        NSArray *classes = [source componentsSeparatedByString:@"@interface"];

        NSCharacterSet *spacesSet = [NSCharacterSet whitespaceAndNewlineCharacterSet];
        NSCharacterSet *wordTokenizingSet = [NSCharacterSet characterSetWithCharactersInString:@" \t\n\r{}*:;"];
        NSCharacterSet *statementTokenizingSet = [NSCharacterSet characterSetWithCharactersInString:@"{}:;/"];
        NSCharacterSet *lineSeparatingSet = [NSCharacterSet characterSetWithCharactersInString:@"\n\r"];

        for (NSString *classSource in classes) {
            NSScanner *scanner = [NSScanner scannerWithString:classSource];
            [scanner scanCharactersFromSet:spacesSet intoString:nil];

            NSString *className;

            // Proceed if the parsed class matches the object's class
            if ([scanner scanUpToCharactersFromSet:wordTokenizingSet intoString:&className] &&
                [className isEqualToString:NSStringFromClass([obj class])]) {

                NSArray *lines = [classSource componentsSeparatedByCharactersInSet:lineSeparatingSet];

                for (NSString *line in lines) {
                    // Skip comment lines
                    if ([[line stringByTrimmingCharactersInSet:spacesSet] hasPrefix:@"//"]) continue;

                    NSArray *statements = [line componentsSeparatedByCharactersInSet:statementTokenizingSet];
                    for (NSString *statement in statements) {
                        if ([[statement stringByTrimmingCharactersInSet:spacesSet] hasPrefix:@"IBOutlet"]) {
                            NSString *outletName = [[statement componentsSeparatedByCharactersInSet:wordTokenizingSet] lastObject];
                            Ivar outletIvar = class_getInstanceVariable([obj class], [outletName UTF8String]);
                            id outletValue = object_getIvar(obj, outletIvar);
                            if (outletValue == nil)
                                NSLog(@"WARNING -- %@'s outlet %@ is nil", className, outletName, outletValue);
                        }
                    }
                }
            }
        }
    }
#endif
}

Usage:

- (void)awakeFromNib
{
    PFValidateOutlets(self);
    // Rest of the code
}

As you can see, I'm invoking the validation manually in awakeFromNib of classes that have outlets. It would be awesome if there were way to make the check fully automatic but I stopped investigating because this is good enough for me. Let me know if you think of something though.

How to Keep Backwards Compatibility and be Less Grumpy About It

Andy Kim — Sun, 04 Nov 2007 03:35:01 -0800

I dread backwards compatibility. I dread it because it means that for every product that I need to keep backwards compatible, the testing burden is at least twice as big. The math is simple: testing on two major OS versions and two processor types can be as much as 4 times of stuff I'd rather not be doing.

The last time I had to maintain a product with backwards compatibility, this is what I used to do:

Build then copy application to test machine.
Get it to fail. This is the one part where I don't have to work very hard.
Try to fix while scratching head then proceed to littering print statements all over the code.
Go back to step 1.

You can make this process a little less sucky by configuring Xcode to copy after each build, or by mounting a share so that there's no copying at all. But in the end, debugging with print statements alone is limiting and time consuming. There has to be a better way, right?

The better way turns out to be handsomely better and it's called remote debugging. A remote debugger is usually used for kernel hacking or for developing full-screen applications such as games, but it's quite handy for fixing backward compatibility problems—especially if your app no longer builds on Tiger.

With remote debugging, I can code in Xcode 3—my new favorite IDE—then just hit command-Y. It works as any great software should. Like magic. The application launches on the test machine and you're off debugging as if it were running locally. You can set breakpoints, examine variables and stack traces, fix and continue, or whatever else that gdb can do. There's no longer a cycle of doom, and as a result, I'm a much happier person.

There are just 3 things you need to do to get stress free debugging on older systems with Xcode:

Set up password-less ssh for logging into your test machine.
Share the build directory in a way that both machines can access it through the same path
Configure a new executable in Xcode for remote debugging.

The Xcode User Guide does a fine job of explaining these steps succinctly.

Xcode User Guide — Debugging Programs Remotely

Some additional tips:

1. If your test machine has a different kind of processor, duplicate your Debug build configuration and set it up to build a universal binary.

2. Use "DWARF with dSYM File" as your debug metadata format. With the other two options, breakpoints set through the Xcode UI didn't work for me.

Quick NSDate Warning

Andy Kim — Thu, 30 Aug 2007 07:47:45 -0700

This is a quick warning for Cocoa programmers.

The following piece of code will not trigger an assertion error:
NSDate *now = [NSDate date];

#if defined(__i386__) NSAssert([now laterDate:nil] == now, @"now should be later than nil"); #else NSAssert([now laterDate:nil] == nil, @"nil should be later than now"); #endif

I think that the correct return value is now since any date is more recent than no date at all, but I admit that the logic is dubious. Best thing to do is to make sure that nil does not get passed in to the date comparison methods at all.

This is the reason why Tangerine! version 1.2.3b has to exist. Don't let it get you too.

UPDATE (December 12, 2007): This is fixed in Leopard now.