First off, this is kind of a warm up post. I’m struggling with figuring how to post source code into my post without killing chickens and using their blood for magic rituals. I’ll probably screw it up. It may be also that I need to elaborate on stuff here – I’m a bit rusty with the technical writing. So please don’t hesitate to ask questions or ask for more info. Or if you have a better idea about something I’m writing about, or I have it wrong, or I have spinach in my teeth, please let me know.

To get the most out of this post you should understand objective-c blocks, and objective-c categories.

Ok, warp factor one. Engage.

This is a useful pattern I’ve discovered after playing with it in various incarnations since iOS 4 came out. I’ve landed on a design which is super simple, and really easy to use. The example’s here are silly and contrived, but the pattern works at scale with large shipping code.

I’m a big fan of objective-c blocks. I first learned about them when using Javascript closures at Microsoft and they blew my mind back then. Now, not so much with the mind blowing, but they’re very useful and I was super excited when they came to objective-c. They have their dangers and drawbacks (which I’ll explore in another post), but for this, they’re perfect because you can use them inline with your normal code – you don’t have to declare extra functions or methods or whatever for fancy or complex initializaton.

Let me explain.

Here’s the situation. You need to build a list of objects that do something, or represent something. For example, this might be a list of addresses, or a queue of tasks to perform, or whatever. We do this all the time. For this, we need to configure a bunch of ducks. Funky ducks.

Let’s start with an example.

I need to create 3 GtFunkyDuck objects and add them to a NSMutableArray.

(Note that GtFunkyDuck isn’t a real object, and the properties and method names will just be silliness to illustrate my point. Also, my company is GreenTongue Software, so all my objects are prefixed with “Gt”. You know, it stands for Goober Tooth or Grand Teton or Got Tamatoes…).

Here’s the normal way to initialize some ducks. Hmm, did I really just write that?

NSMutableArray* myArray = [NSMutableArray array];

GtFunkyDuck* myDuck1 = [[[GtFunkyDuck alloc] init] autorelease];
myDuck1.feetAreWebbed = YES;
myDuck1.billColor = [UIColor redColor];
myDuck1.quackVolume = 6;
[myDuck1 getReadyToSwimInPond:myPond];
[myArray addObject:myDuck1];

GtFunkyDuck* myDuck2 = [[[GtFunkyDuck alloc] init] autorelease];
myDuck2.feetAreWebbed = NO;
myDuck2.billColor = [UIColor greenColor];
myDuck2.quackVolume = 1;
[myDuck1 getReadyToSwimInBathtub:aBathtub];
[myArray addObject:myDuck2];

GtFunkyDuck* myDuck3 = [[[GtFunkyDuck alloc] init] autorelease];
myDuck1.feetAreWebbed = NO;
myDuck3.billColor = [UIColor blueColor];
myDuck3.quackVolume = 2;
[myDuck1 getReadyToChaseAToddler:aToddler];
[myArray addObject:myDuck1];

This post illustrates what I’m talking about very well. Look closely. There are a couple of bugs here. Why? Because I’m lazy and I copied and pasted myDuck1 to reuse the code for myDuck2 and myDuck3. I want this code written, now, I can’t be bothered retyping GtFunkyDuck seventy-hundred times. So copy-paste here I come, and then I got distracted by twitter and screwed up myDuck3. This could cause weirdass bugs that are hard to track down. myDuck1 was added twice to the array, myDuck3 was never added, and myDuck1 doesn’t have webbedFeet like it’s supposed to. Well, you get the idea. It’s far easier to screw up the code here than to get it right, in my experience. Copy and paste. Deliciously dangerous.

One solution is to add an initWithWebbedFeet method and have a bunch of parameters for building the object. But what if the object has twentysix options? Or complex configuration methods? What if the default initializer puts the object into a state that’s just fine? If so, there’s no point in passing in all the parameters, or creating six quadrillion different init methods, and in fact that will make the code very difficult to maintain and debug

GtFunkyDuck* myDuck1 = [[[GtFunkyDuck alloc] initWithWebbedFeet:YES billColor:[UIColor redColor] quackVolume:4 swimsInCircles:NO likesBreadCrusts:YES hatesChickens:YES chasesSmallChildren:NO willBeATastyMealSomeday:YES] autorelease];

This is just damn painful. In my experience, if there are more than two or three parameters, you’re in for some hurt. Big fat painful hurt, deep in the debugger, complete with dog kicking cursing and heavy drinking. Well, maybe not that bad. And for the record, I never kicked my dog. (Or your dog).

So there are two problems here:

1. We have to create a bunch of local variables to hold temporary references to the objects we’re creating, e.g. myDuck1, myDuck2, and myDuck3. This gets painful and buggy, after, well, one, because everyone copies and pastes and we forget or miss changing the names in the newly pasted code in our hurry to implement our new duck related feature.
2. We have complex objects with a bunch of optional parameters. These damn ducks are high maintainence. They have a lot of options.

Here’s my simple solution:

typedef void (^GtConfigureObjectBlock)(id object);

@interface NSMutableArray (GtArrayAdditions)
- (void) addObject:(id) object configureObject:(GtConfigureObjectBlock) block;
@end

@implementation NSMutableArray (GtArrayAdditions)
- (void) addObject:(id) object configureObject:(GtConfigureObjectBlock) block {
    if(block){
        block(object);
    }
    [self addObject:object];
}
@end

What we’re doing here is passing in a object in a default state, and then modifying that default state with your block callback. This elimates all the local variables and nearly all the opportunity for cut and paste errors, which can be traced back to having to reference the objects through their local variables. So our new fancy code for initializing our ducks looks like this now:

NSMutableArray* myArray = [NSMutableArray array];

[myArray addObject:[[[GtFunkyDuck alloc] init] autorelease] configureObject:^(id duck) {
    [duck setFeetAreWebbed:YES];
    [duck setBillColor:[UIColor redColor]];
    [duck setQuackVolume:6];
    [duck getReadyToSwimInPond:myPond];
}];
[myArray addObject:[[[GtFunkyDuck alloc] init] autorelease] configureObject:^(id duck) {
    [duck setFeetAreWebbed:NO];
    [duck setBillColor:[UIColor greenColor]];
    [duck setQuackVolume:1];
    [duck getReadyToSwimInBathtub:aBathtub];
}];
[myArray addObject:[[[GtFunkyDuck alloc] init] autorelease] configureObject:^(id duck) {
    [duck setFeetAreWebbed:NO];
    [duck setBillColor:[UIColor blueColor]];
    [duck setQuackVolume:2];
    [duck getReadyToChaseAToddler:aToddler];
}];

The only draw back is that you loose the ability to use the properties. You can’t do this:

[myArray addObject:[[[GtFunkyDuck alloc] init] autorelease] configureObject:^(id duck) {
duck.feetAreWebbed = NO;
}];

You also can’t do this (unfortunately):

[myArray addObject:[[[GtFunkyDuck alloc] init] autorelease] configureObject:^(GtFunkyDuck* duck) {
duck.feetAreWebbed = NO;
}];

However, I view the inability here to use the properties as merely cosmetic. The trade off in better code and less bugs is worth it.

This may look a little weird, but once you wrap your head around it, it become second nature and very powerful.

Let me know what you think, or if you have any questions.

I view this blog reboot as an experiment. The basic premise is that I want to see if I can write some stuff here that will actually help people – specifically with iOS and Cocoa development.

I’ve spent the last two years on an intensive crash course with this stuff and I’ve got about twenty years experience shipping software now, so maybe I just might have something to say.

I’ve read a lot of blog posts and discussions here and there on the web that have helped me, and now maybe I can help someone else and give back a bit a bit…

Not sure if the timing of Apple releasing Lion and me doing this have any great meaning. Probably not. But I’ll take what I can get.

So, anyway, I updated my wordpress install and installed a new theme, and off we go…

_DSC6117, originally uploaded by Mike and Bunny.

This shot was under exposed, but I like it anyway.