Cocos2d makes it easy to convert your drab standard UIAlertViews into glorious customized color dialog boxes. Above is an actual UIAlertView / custom dialog box transition from my upcoming iPhone game. Here’s how I did it.

Implementing a Custom Dialog Box in Cocos2d

Cocos2d Scene Structure

Cocos2d uses a scene graph to hold everything being displayed at any given point in a game. Informally, this data structure is a hierarchy of objects, each of which might display something onscreen, contain other objects to be displayed onscreen, or both. In Cocos2d, these objects are descendants of the CCNode class.

Related objects can be placed into a single container object, which allows them all to be manipulated as a unit when necessary. The root, or lowest-level, container at any given time is an instance of the CCScene class. A CCScene contains CCLayer objects, which themselves contain other objects such as menu labels or sprites to be displayed. Layers, as the name implies, are displayed superimposed upon each other onscreen, which makes a CCLayer perfect for our custom dialog box.

Custom CCLayer

Here’s the code for DialogLayer.h and DialogLayer.m. These implement a basic but perfectly servicable custom iPhone dialog box. It can be used as-is or expanded in any number of ways for particular situations. Take a look through the finished product, and then we’ll go over it below.

DialogLayer.h

//
//  DialogLayer.h
//  concentrate
//
//  Created by Paul Legato on 12/4/10.
//  Copyright 2010 Paul Legato. All rights reserved.
//

#import <Foundation/Foundation.h>
#import "cocos2d.h"

@interface DialogLayer : CCLayer {
  NSInvocation *callback;
}

-(id) initWithHeader:(NSString *)header andLine1:(NSString *)line1 andLine2:(NSString *)line2 andLine3:(NSString *)line3 target:(id)callbackObj selector:(SEL)selector;
-(void) okButtonPressed:(id) sender;

@end

DialogLayer.m

//
//  DialogLayer.m
//  concentrate
//
//  Created by Paul Legato on 12/4/10.
//  Copyright 2010 Paul Legato. All rights reserved.
//

#import "DialogLayer.h"
#import "GameSoundManager.h"

#define DIALOG_FONT @"bicho.fnt"

@implementation DialogLayer
-(id) initWithHeader:(NSString *)header andLine1:(NSString *)line1 andLine2:(NSString *)line2 andLine3:(NSString *)line3 target:(id)callbackObj selector:(SEL)selector
 {
   if((self=[super init])) {

     NSMethodSignature *sig = [[callbackObj class] instanceMethodSignatureForSelector:selector];
     callback = [NSInvocation invocationWithMethodSignature:sig];
     [callback setTarget:callbackObj];
     [callback setSelector:selector];
     [callback retain];

     CGSize screenSize = [CCDirector sharedDirector].winSize;

     CCSprite *background = [CCSprite node];
     [background initWithFile:@"Dialog.png"];
     [background setPosition:ccp(screenSize.width / 2, screenSize.height / 2)];
     [self addChild:background z:-1];

     CCLabelBMFont *headerShadow = [CCLabelBMFont labelWithString:header fntFile:DIALOG_FONT];
     headerShadow.color = ccGRAY;
     headerShadow.opacity = 127;
     [headerShadow setPosition:ccp(243, 262)];
     [self addChild:headerShadow];

     CCLabelBMFont *headerLabel = [CCLabelBMFont labelWithString:header fntFile:DIALOG_FONT];
     headerLabel.color = ccBLACK;
     [headerLabel setPosition:ccp(240, 265)];
     [self addChild:headerLabel];

     //////////////////

     CCLabelBMFont *line1Label = [CCLabelBMFont labelWithString:line1 fntFile:DIALOG_FONT];
     line1Label.color = ccBLACK;
     line1Label.scale = 0.84f;
     [line1Label setPosition:ccp(240, 200)];
     [self addChild:line1Label];

     CCLabelBMFont *line2Label = [CCLabelBMFont labelWithString:line2 fntFile:DIALOG_FONT];
     line2Label.color = ccBLACK;
     line2Label.scale = 0.84f;
     [line2Label setPosition:ccp(240, 160)];
     [self addChild:line2Label];

     CCLabelBMFont *line3Label = [CCLabelBMFont labelWithString:line3 fntFile:DIALOG_FONT];
     line3Label.color = ccBLACK;
     line3Label.scale = 0.84f;
     [line3Label setPosition:ccp(240, 120)];
     [self addChild:line3Label];

     CCMenuItemImage *okButton = [CCMenuItemImage itemFromNormalImage:@"OKButton.png" selectedImage:@"OKButtonSelected.png" target:self selector:@selector(okButtonPressed:)];
     [okButton setPosition:ccp(0, 60)];

     CCMenu *menu = [CCMenu menuWithItems: okButton, nil];
     menu.position = ccp(240,0);
     [self addChild:menu];
   }
   return self;
 }

-(void) okButtonPressed:(id) sender
 {
   [[GameSoundManager sharedManager].soundEngine playEffect:@"OK.caf"
                                    pitch:1.0f
                                    pan:0.0f
                                    gain:1.0f];

   [self removeFromParentAndCleanup:YES];
   [callback invoke];
 }

-(void) dealloc
 {
   [callback release];
   [super dealloc];
 }
@end

Custom dialog box code analysis

Overview

The dialog box is implemented as a subclass of CCLayer. An initWithHeader method is provided to initialize the layer with a given message and a specified callback method that will be invoked when the dialog’s “OK” button is pressed. It also plays a confirmation sound and switches the “OK” button’s image to a “pressed button” when the user taps it.

DialogLayer.m requires a few external supports, which must be available as project resources. Dialog.png is the dialog box’s background image. bicho.fnt is an AngelCode format bitmapped font, used for the labels, and can be substituted with any font you like. OKButton.png and OKButtonSelected.png are the images to be used for the button in unpressed and pressed forms. Finally, OK.caf is the audio file to be played when the user taps the button.

Analysis

Storing the callback

     NSMethodSignature *sig = [[callbackObj class] instanceMethodSignatureForSelector:selector];
     callback = [NSInvocation invocationWithMethodSignature:sig];
     [callback setTarget:callbackObj];
     [callback setSelector:selector];
     [callback retain];

This code is Objective C’s (massively redundant) way of storing the callback to be activated when the dialog’s button is pressed. It’s based on the callback code in Cocos2d itself. (We could also have used Objective C’s new closure data type, called “blocks”, but that syntax grates my Lispy sensibilities even more than the overly verbose Javaish mess here, besides not working out of the box on older versions of iOS.)

The initWithHeader method is given a target object and a method selector. It looks up the class of the target object and then looks up the selector on that class at line 1, resulting in a NSMethodSignature object which encapsulates the class-method combination. Line 2 transforms that class-method signature into an “invocation,” which represents the act of actually calling that method on some as yet unspecified object. Line 3 associates the invocation with the particular target object we were given, and line 4 associates the selector (which is utterly odd, since the desired method is encoded in the signature object already.) Finally, we retain the callback so that we can save it for later (to be activated when the user actually presses the “OK” button) and it won’t be deallocated at the end of the present scope.

Setting up the background and labels

The remainder of the initWithHeader method, lines 25 to 68 in the main listing above, is pretty straightforward. A CCSprite object is created to store the background image and added to self, that is, to the new custom layer being created. Its position is set to be the center of the screen, and its level on the Z axis is set to -1 so that it will appear below anything else added in the layer.

CCLabelBMFonts are then created for the given text and added to the new layer. A shadow effect is created for the header by writing the same thing in grey at a slight offset underneath the main text. All lines except the header are then scaled down to 0.84 of their natural size, so as to enhance the prominence of the header.

A CCMenuItemImage is finally created to be the “OK” button. It’s added to a CCMenu, which handles the logic of button presses for us, and the CCMenu is then added to the new layer. It will take a little experimentation to get the exact placement of the OK button correct (lines 64 and 67) relative to your background image.

Note that the OK button itself takes callback arguments of exactly the same type that our initWithHeader method does (line 63). We might be tempted to forego the construction of our own callback object and just pass the given target and selector on to the OK button, simplifying the design of our DialogLayer a bit, but then we wouldn’t have the chance to play a sound when the OK buton is pressed. More seriously, we would have no way to destroy the dialog layer and remove it from the screen. So, we give the OK button a target of self and tell it to call the okButtonPressed method when OK is pressed.

The okButtonPressed callback

The CCMenuItemImage will invoke this method when the user presses “OK”. This means that it’s time to remove the DialogLayer from the scene (easy enough, line 80). Here, we also play a little click-type sound to make the game seem more interactive; also easy with CocosDenshion, lines 75-78. If you don’t want to play a sound, you can remove those lines and the GameSoundManager.h include file.

dealloc

Nothing fancy here; we just release our retained callback object and then defer to super.

Using the custom DialogLayer

Adding a custom dialog layer to your game scene is very easy:

   CCLayer *dialogLayer = [[[DialogLayer alloc]
                            initWithHeader:@"Level 1"
                            andLine1:@"Tilt The Phone"
                            andLine2:@"To Balance"
                            andLine3:@"The Ball!"
                            target:self
                            selector:@selector(beginLevelOne)] autorelease];
   [self addChild:dialogLayer z:200];

Future Expansions

DialogLayer is a simple modal dialog box that can only accept one action from the user. It can easily be enhanced in many ways, depending on your needs. The most obvious enhancement is to add multiple buttons to allow the user to make a choice rather than simply dismissing the box. It could be modified to accept an arbitrary amount of text and divide it up automatically into an aesthetically pleasing configuration.

One thing that DialogLayer does not do is pause the game. I decided that that is not necessarily desirable in all cases; many game scenarios need to present information to the user without stopping the action. It’s easy enough to pause manually when activating the dialog.

Little enhancements like this are critical as ‘polish’ for your game.

iPhone Pros

• iPhones are all (almost) exactly the same. 4th generation iPhones do support an optional higher screen resolution than previous models, but they’re 100% binary backwards compatible. This is a trivial difference when put up against the dozens of different Android devices available with radically different hardware, and the hoops that you as a developer have to jump through to make sure your app runs correctly on all of them.
• Large, high-end user base that demonstrably spends money on apps. iPhone users have already shown their willingness to buy large numbers of apps; Android users, not so much. This seems to be slowly changing over time as the Android app store matures, but for now, iPhone is still the cash cow.
• Beautiful and well-designed UI and system architecture. iPhones have been designed as an integrated and coherent experience. Apple’s renowned mastery of intuitive human-computer interaction is evident at every step while using the device. There is an overall (and well documented) unifying strategic vision of how different subsystems should fit together seamlessly and present a unified interface to the user. Their development libraries have been designed to support this theme at every level. Android, by contrast, reads much more like KDE or Gnome; it was bolted together out of disparate pieces written by different groups working in isolation with minimal coordination. Perceived technical coolness from the perspective of a software engineer who is already intimately familiar with the system’s internals took precedent over usability. Android’s user interface is generally much uglier and much less intuitive.
• iPhones support low latency audio. Android uses ALSA internally, which does support low-latency audio, but the low-latency API is not exposed to developers, and Google does not seem to be interested in fixing this. Android latency is unacceptably high for realtime sound synthesis unless you hack it and use the ALSA API, which is officially forbidden and in any case could change significantly and without warning between Android operating system updates and between phones. iPhone, on the other hand, has an officially supported low latency audio API, and there are many successful realtime sound synthesizer apps in the app store.
• XCode. XCode is a really well done IDE. I normally don’t like IDEs. I normally use Emacs for everything. But, in all fairness, I decided to give XCode and Eclipse with the Android plugins a shot. Eclipse is nice, but a little rough around the edges. I ran into a few bizarre IDE error messages while developing my Android test projects that required extensive Googling and hours of experimentation to unravel. XCode, as one would expect from a flagship Apple product, is immaculately polished and completely integrated from top to bottom.

iPhone cons

• Objective C. While Objective C was really cool and innovative in 1988, today it seems archaic. Nobody uses it except Apple. It’s laden with tons of cruft. It still feels like it’s a bolt-on afterthought preprocessor for a C compiler. For example:
  • Selectors: you can’t refer to method names directly; you have to use the special @selector() compiler directive to look up their index number. This probably made great sense when CPUs were very slow and doing a lookup in an ASCII table was a significant performance hit over doing an integer offset jump, but on modern computers, this is just annoying. CPU time is cheaper than engineer time.

  • Manual reference-counted memory management is an obsolete and extremely fragile pain in the ass. Lisp had GC ~40 years ago. The vast set of problems introduced by manual memory management, such as buffer overflows and memory leaks, is just not worth the small gain in efficiency that you get from not periodically running a garbage collector. Again, CPU time is cheaper than engineer time. Android does GC on a phone just fine, so I don’t buy the argument that a phone can’t support that kind of overhead. Garbage collection was recently introduced for the Mac OS X desktop system, but is as of yet not available on the iPhone.

    (I’m aware that C and C++ are widely used and both still make you do manual memory management, too. Far from regarding this as a vehicle for a macho display of programming prowess, I find manual memory management to be more of an annoyance, something that the computer should be handling for me automatically, much like how figuring out the exact memory address of a function was automated long ago and is no longer something we as application-level programmers ever need to worry about much.)

  • The use of + and - to mark methods as class or instance methods. Principle of least surprise; why not just use, say, the English word class or static or something to that effect to designate class methods, and leave instance methods unmarked? Perhaps using 1 character symbols rather than entire English words as the token improved compile times on large, complex projects in the ’80s, but the time savings is infinitesimal on a modern computer, so I’ll vote for obviousness and clarity rather than crypticity.
  • The use of [] (square brackets) for message passing, and the requirement for named (but non-reorderable) arguments.

    Perhaps this was done out of a well-intentioned effort to make the programmer notice that these are messages and not function calls or C++ methods, and to make the code self-documenting. I find the introduction of new syntax rather unwarranted and distracting. I’d much prefer the familiar object.message(argument1, argument2) over the verbose and unwieldly [object message:argument1 parameterName:argument2]. You can’t even re-order the named arguments, so including the argument name is just noise in the code. I guess I’ve been spoiled by Clojure and Lisp, where there’s almost no syntax.

    If they really felt strongly about the need to pedantically differentiate messages from function calls or methods at the syntax level, they should at least have retained the general function/method syntactic template and chosen a different separator character, so as to enable programmers to re-use most of their neural syntax parsing circuitry rather than force us to introduce an entirely new syntactic template that performs only 1 task. For example, a more intuitive syntax that still emphasizes the fact that this is not a function or method call could be something like object#message(argument1, argument2) or object<-message(argument1, argument2).

• Closed platform. The source code to the vast Cocoa library is proprietary. You can develop with things Apple tells you you may develop with, and nothing else. They only recently relaxed the restriction on using any third party tools at all. The iPhone's CPU is widely reported to have built-in hardware level Java bytecode support, but that's off-limits.
• Vendor lock-in. This is a huge and obvious minus for the iPhone. Your ability to generate revenue is 100% dependent upon Apple's whims, upon remaining in Apple's good graces. Uncountable horror stories circulate online about developers who invested months and many thousands of dollars into a project only to have it rejected by Apple, often after a considerable delay and with little or no explanation.

Android pros

• Java (almost). Android apps are written in Java. (Well, technically not in Java due to licensing issues, but in a language that is 99.9% the same as Java.) If you already know Java, as I do, this is a big plus. You can easily re-use your code elsewhere, on any platform, with minor or no modifications. Objective C code is rather limited in what you can do with it: you can re-use it in your Apple desktop apps. (Yes, there is a free GNU Objective C compiler, but almost all real-world Objective C code is locked into Apple's proprietary Cocoa runtime system.)
• A JVM, almost. Android doesn't run a true JVM, unfortunately, as part of a licensing dispute between Google and Sun, but it's close. Android's Dalvik is a cleanroom reimplementation of part of Java, designed to avoid triggering what Google regards as onerous licensing fees for the use of a true JVM on a mobile handset. In any case, it's close enough that the door is open to potentially running Clojure and other JVM languages on it someday.
• No upfront developer fees. Develop for free. You can download the SDK and go nuts, upload your code to a real handset to test, send your apps to the app store for sale, whatever. There is no $99 developer tax.
• Larger ultimate user base. Android phones are now outselling iPhones, and this trend looks set to continue. The price you pay is coding for 200 slightly different handsets.
• Open source platform. Most of the Android system is freely available, precluding vendor lock-in, at least in theory.

Android cons

• Android emulator lacks hardware accelerated graphics. This is a big minus. I made a very simple bouncing-ball demo with Rokon that got about 6 or 7 fps in the emulator. Full games often take multiple seconds per frame, completely unusable. If you want to write games (or anything else where graphical performance is key), you absolutely need to have a hardware handset from the start. If you don't already own an Android phone anyway, this means you have to invest hundreds of dollars upfront, just to see if the platform is for you.
• Lack of interest from Google. Google has many, many pots cooking at once. While they do devote significant resources to Android's maintenance and expansion, it's nowhere near as important a product for them as the iPhone is for Apple, and you can tell. The iPhone is a core strategic product for Apple, whereas Android is a relatively minor satellite project for Google. Correspondingly, Apple's general support of the iPhone and its developers seems far better.
• Relatively few libraries. For the moment, there seem to be more third party libraries available for the iPhone, and they seem to be more mature and robust than what's out there for Android. This will change in time, as more and more app developers begin to use Android.

It was a close call. I did some exploratory coding on both platforms — there's no substitute for direct experience. Though I much prefer Java over Objective C as a language, the universe of extant Android libraries is much smaller and less mature. I may have been able to live with that in order to be able to code in Java and avoid Apple's vendor lock-in. In the end, the tipping point was practical: the Android emulator's lack of hardware accelerated graphics left me with an unusable framerate, so I'd have to spend hundreds of dollars on a handset to do even trivial demo development, whereas I already own an iPhone.

I'll be checking back in on Android periodically, as I expect its long-term position will improve substantially in time, but for now, I'm going with the iPhone.

In standard Unix, this is one line in a crontab:

0 0 * * * /some/script

That’s it. Put that in your crontab and /some/script will run every day at midnight.

Naturally, I typed man crontab on my Mac to get started. Apple likes to make weird minor modifications to standard Unix commands sometimes. I found:

(Darwin note: Although cron(8) and crontab(5) are officially supported under Darwin, their functionality has been absorbed into launchd(8), which provides a more flexible way of automatically executing commands. See launchctl(1) for more information.)

More flexible, huh? I’m all about more flexible! Sounds good. Another well thought out Apple improvement, sweeping away 30+ years of Unix cruft at a stroke!

Not quite. Turns out that you must submit jobs to launchctl as XML files. We all know how much I hate XML files, and this is a great example of why. That one line cronjob becomes this fragile ~20 line XML monstrosity:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>net.sourceforge.awstats.update-daily</string>
<key>LowPriorityIO</key>
<true/>
<key>OnDemand</key>
<false/>
<key>Program</key>
<string>/opt/local/www/awstats/cgi-bin/awstats.pl</string>
<key>ProgramArguments</key>
<array>
<string>-config=INSERT_YOUR_COMPUTER_NAME_HERE.local</string>
<string>-update</string>
</array>
<key>ServiceDescription</key>
<string>Updates statistics for awstats.pl every day at 3AM.</string>
<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>3</integer>
</dict>
</dict>
</plist>

But it defines its own syntax!! I can already hear the XML cheerleaders say. Well, sort of. You can read it, kinda, even if you are unfamiliar with the syntax, but you certainly can’t write it without spending half an hour or more reading about and then absorbing the syntax documentation first. For comparison, you can learn the syntax of a crontab entry in around 1 minute. Hell, the documentation of the crontab syntax is shorter than that one simple launchd plist example, nevermind the 13 page manpage explaining the launchd plist syntax.

More verbosity means more things that can be screwed up, as that discussion thread amply demonstrates. Even extremely simple jobs become ordeals. In this case, the problem stems from trying to do too much in one tool, forgetting the Unix philosophy: do one thing, and do it well. Create reusable, chainable tools, rather than one monolithic beast that tries to do everything. Apple bills launchd as a replacement for init, rc, init.d, rc.d, SystemStarter, inetd/xinetd, atd, crond, and watchdogd. Maybe others, too.

Developing a language powerful enough to capture the functionality of all of those different tools results in a massively complex, fragile, general-purpose language. Developing a tool that does exactly 1 of those things results in a tiny, simple, clean, resilient language that is easy to use and hard to screw up. Complex cases are then handled by gluing those many small tools together, not by programming a massive monolith.

Fortunately, cron is still supported by Mac OS X as a legacy service, so I’m using that. If and when they finally remove it from the OS altogether, I’ll be using the MacPorts version.

Payne’s conception of humanity is somewhat more disturbing. He is saying that all people can be, or at least should be, “creative” (whatever that means), and those who are not are somehow deficient as human beings. Nonetheless, the iPad so far has not impressed me.

Payne raises some legitimate points. Admittedly, I’ve never seen a real one.  If it’s just a larger iPod Touch, I will never buy it, for many of the reasons Payne describes. I’ve had an iPhone for a while now, and at this moment, I wouldn’t buy another one, simply because of the oppressive restrictions on what one is permitted to do with it. I don’t like having to have Apple’s imprimatur for software before I’m allowed to use it. I certainly don’t like the idea of being forced to pay money for a straight port of a free and open source SSH client that’s available for a thousand other platforms gratis. I own the hardware, I’m not renting it. Didn’t the old AT&T monopoly already go through all this long ago?

I do love the iPhone’s UI polish, though. It’s a very tightly integrated device, and everything Just Works. The Android user interface is not yet up to speed — but it will be, soon. Probably just about the time that my iPhone reaches the end of its useful life, and I’ll be switching. That is, unless in a moment of sudden enlightenment, Apple removes the DRM from the iPhone and avoids shooting themselves in the foot again by making exactly the same mistake Jobs made 20 years ago with the original Mac. (And by the way, what are we looking forward to in Mac OS XI? Pervasive DRM and an App Store?)

Al3x derides Apple as “cynical” for closing the iPad, but it would be just as fair to flip that around and characterize people like Alex Payne as incredibly naive. “Apple can’t – or won’t – conceive of a future for personal computing that is both elegant and open, usable and free… Apple has decided that openness is not a quality that’s necessary in a personal computer. That’s disturbing,” he writes.

Um… Last I checked, Apple was a for-profit corporation operating in a capitalist economy. This is not secret or hidden information. All such corporations have exactly 1 goal: provide a good return on capital to their shareholders. Anything else that they do is always and exclusively in the service of that goal.

Elegant, open, usable, and free are all nice, sure — but, for Apple or for any other for-profit corporation, only insofar as doing those things provides a nice return on capital to the shareholders. If they believe that they can get an even better return by dropping them and doing something else instead, then they will.

What’s really disturbing here is that Payne and more than a few of his friends seem to have actually expected “nice” over “profit” from a corporation, and are startled and miffed because the corporation chose “profit”. “The iPad leaves me with the feeling that Apple’s interests and values going forward are deeply divergent from my own.” … it took the release of the iPad to trigger this epiphany?