So when iOS 4 came out recently I heard from a variety of people that it was generally “slow” on older devices. For my main iPhone 3G this was certainly the case, and I was convinced Apple couldn’t release such an update. No matter how you spin it, an update that makes the user experience worse cannot be a good thing. Well, it seems we have been left out in the cold on this one. App developers who rely on certain APIs have found out the hard way that even when the problem is in the OS, they are the ones left holding the bag.

I’m talking about CGContextDrawImage. My two most popular games, reMovem and reMovem free, made heavy use of this functionality to draw the balls on the screen. It’s not uncommon, especially for code ported from Mac OS X, where Quartz 2D is widely used for drawing. I’m not sure how this is possible, but CGContextDrawImage (and its cousin [UIImage drawInRect:]) is measurably slower on older iPhone devices. In my case, where it used to take less than 20 ms to render key elements of the screen on iOS 3.x, it now takes around 500 ms. That is, suffice to say, enough to cripple these games.

With all the commotion around the successful iPhone 4 launch recently I’m sure Apple would rather not worry so much about compatibility and performance on older CPUs. Fortunately you don’t have to wait for Apple to address the problem. I solved it in reMovem by using CALayer to draw the images I needed, and was able to get a performance boost at the same time. The same key elements of my game now render in around 2 ms. Here’s how.

The key to using CALayer is to understand that each UIView is backed by a Core Animation layer object. Each layer can have multiple sublayers. Each layer object has numerous properties, many of which are animatable. Simply attach a sublayer to your view’s existing layer, set its content property to your image, and you are done. Well, sort of. A good place to learn more about Core Animation is the excellent Cocoa Is My Girlfriend blog by Matt Long and Marcus Zarra.

Here’s a specific example. In my view’s drawRect: code, there’s a loop which needs to draw a bunch of images on the screen in various locations. For each image, it computes the rectangle to draw the image, then uses CGContextDrawImage (or [UIImage drawInRect:], your choice) to render the image to the screen. In Xcode:

// process rows from top -> bottom

for ( row = 0; row < numRows; row++ )

{

	// process columns left -> right

	for ( column = 0; column < numColumns; column++ )

	{

		id cell = [dataSource objectValueForRow:row column:column];

		int x = bounds.origin.x + column * width;

		int y = bounds.origin.y + row * height;

		CGRect cellRect;

		cellRect.origin = CGPointMake(x,y);

		cellRect.size = CGSizeMake( width, height );

		if ( cell != nil && cell != [NSNull null] )

		{

			CGFloat alpha = 1.0;

			if ( [cell selected] )

				alpha = 0.35;

			CGContextSetAlpha( context, alpha );

			CGContextDrawImage( context, cellRect, [[dataSource imageAtIndex:[cell imageIndex]] CGImage] );

		}

	}

}

Pretty simple stuff, almost identical to the original Mac code. Problem is, this loop, when profiled on iOS 4 took 500 ms on average. That’s way too slow to keep the game responsive, even if I only refresh the screen a couple of times per second. Well, obviously I can’t so that won’t ever happen. The game seemed to freeze and the images would hang in mid air for a bit before redrawing where they belonged.

Adding CALayer drawing to you code requires a little setup, but that can be done once in an init function. In mine, we create a bunch of sublayers, modify the properties appropriately, and add them to the view’s main layer. The tradeoff here is we require slightly more resources (sublayer memory) but we obtain vast improvements in performance. Why’s that? I imagine Apple’s engineers are spending tons of time optimizing Core Animation, which is literally behind everything you see on the iPhone and iPad screen. Betting on CALayer is a safe bet for the foreseeable future. Here’s the new code, which is not too different from the old code:

// process rows from top -> bottom

for ( row = 0; row < numRows; row++ )

{

	// process columns left -> right

	for ( column = 0; column < numColumns; column++ )

	{

		id cell = [dataSource objectValueForRow:row column:column];

		CALayer* layer = layers[row][column];

		if ( cell != nil && cell != [NSNull null] )

		{

			CGFloat alpha = 1.0;

			if ( [cell selected] ) 

				alpha = 0.35;

			UIImage* image = [dataSource imageAtIndex:[cell imageIndex]];

			layer.contents = (id)[image CGImage];

			layer.opacity = alpha;

		} else {

			layer.contents = nil;

		}

	}

}

As you can see the crucial change involves modifying the existing layer’s contents. Either we stuff the image into the layer or we set the contents to nil. This clears the layer, and nothing will be drawn. The resulting code fits nicely into the existing game logic and drawing code, so no other changes (besides the sublayer init code) need to be made.

The resulting drawing is also rendered better on the iPad in pixel double mode, and Core Animation does a much nicer job of resizing the images if needed. As an added bonus the drawing also has a smoother feel to it, with less jarring changes from one image/color to the next. I look at this as the silver lining to the cloud that was over my head for the last week or so. Future changes to the drawing code will be easier with CALayer drawing in place now. Once these changes were made and fully tested on all our devices, it was just a matter of getting Apple to review the updates in a timely manner. Luckily Apple responded to my request after three days, which is certainly one of the shortest turn-around times I’ve ever had.

I haven’t attempted to exceed this, but the 255 character limit on your application’s name is possibly also 255 bytes. Likewise, the application description is probably 4000 bytes instead of the documented 4000 characters.

Keep it mind when planning your localization, especially if you are getting estimates for the translation of your application’s descriptions and keywords. Hopefully you won’t have to pay for something that you can’t even use.

Update: Kirby’s comments remind me that this problem is only apparent after you update the application. If you merely add the description and keywords when appending a new language translation, you won’t see the problem. That is to say, you’ll think the keywords were accepted, but they are probably truncated if more than 100 bytes.

Setup

To get started you’ll need to set up accounts and download SDKs. In the example below I am using the analytics packages from Pinch Media, Flurry, and Google, three of the many choices for the iPhone OS today. Each solution contains one or more header files and a static library to add to your Xcode project. Read the specific instructions for the latest details on configuring your project properly. You may want to use a single one, or you may want to implement more than one to verify/validate your results. Also, each service provides a distinct developer “dashboard” of results; you’ll soon discover which one suits your particular needs.

All of the analytics packages I’ve used follow a similar pattern: create a singleton instance, initialize it at startup, log events, cleanup and terminate at shutdown. I’ve encapsulated this behavior in my own class like this:

// MMTrackingController.h
// Copyright Mundue LLC 2008. All rights reserved.

@interface MMTrackingController : NSObject {
}
+ (MMTrackingController*) sharedTrackingController;
- (void) startTracking;
- (void) stopTracking;
- (void) logEvent:(NSString*)event;
@end

Import the MMTrackingController.h file in your application delegate and add the housekeeping code like this:

- (void)applicationDidFinishLaunching:(UIApplication *)application {
// Add this first to track launch events.
[[MMTrackingController sharedTrackingController] startTracking ];
[[MMTrackingController sharedTrackingController] logEvent:@”Launch” ];
…
}

- (void)applicationWillTerminate:(UIApplication *)application {
…
// Add this last to track terminate events.
[[MMTrackingController sharedTrackingController] logEvent:@”Terminate” ];
[[MMTrackingController sharedTrackingController] stopTracking ];
}

Now you just need sprinkle logging calls wherever you need them in your code. For a game, this might be when an achievement is earned, or high scores are bested. Here are some examples:

[[MMTrackingController sharedTrackingController] logEvent:@”newGame” ];
…
[[MMTrackingController sharedTrackingController] logEvent:@”addHighScore” ];
…
[[MMTrackingController sharedTrackingController] logEvent:@”gameOver” ];

That’s really all there is to it. The details of the tracking controller are not that interesting, but that’s where you’ll hook up the various back-end services. I’m currently using Flurry, Pinch Media, and Google Analytics, but I’ve also hooked up Mobclix and others in the same way. Implement the tracking controller singleton like this:

// MMTrackingController.m
// Copyright Mundue LLC 2008. All rights reserved.

#import “MMTrackingController.h”
#import “Beacon.h” // The pinch API
#import “FlurryAPI.h” // The flurry API
#import “GANTracker.h” // The google API

static MMTrackingController* _sharedTrackingController = nil;

+ (MMTrackingController*) sharedTrackingController {
if ( _sharedTrackingController == nil ) {
_sharedTrackingController = [[MMTrackingController alloc] init];
}
return _sharedTrackingController;
}

- (void) startTracking {
[Beacon initAndStartBeaconWithApplicationCode:@"abcdef1234567890" // Your pinch app id
useCoreLocation:NO // or YES
useOnlyWiFi:NO]; // or YES
[FlurryAPI startSession:@"abcdef1234567890"]; // Your flurry app id
[[GANTracker sharedTracker] startTrackerWithAccountID:@”us123456-00″ // Your google tracking code
dispatchPeriod:10 // some amount of time
delegate:nil]; // read the google API docs
}

- (void) stopTracking {
[[Beacon shared] endBeacon];
// Flurry:Nothing to do
[[GANTracker sharedTracker] stopTracker];
}

- (void) logEvent:(NSString*)event {
[[Beacon shared] startSubBeaconWithName:event
timeSession:NO];
[FlurryAPI logEvent:event];
NSError *error;
if (![[GANTracker sharedTracker] trackEvent:@”reMovem free” // “category”
action:event //read the google API docs
label:nil
value:-1
withError:&error]) {
// Handle error here
}

}

You’ll need to take the standard precautions when implementing your singleton (shared instance) class, to avoid potential multiple allocations and threading issues. I’ve left the details of that out, see the Cocoa documentation for complete information.

Results

Calls made to the tracking code are typically cached on the device in a sqlite database, then sent to the server only when a connection is available. Modern implementations will not waste time or battery by constantly attempting to connect, but do so at well-defined times like launch and shutdown. If a connection is not available, the cached information is simply updated and saved for the next session.

Most services take several hours to aggregate the data. That is, you won’t see results immediately, but definitely within a day. Because all devices are not always connected, the data could appear days or even weeks later, when a connection is eventually made. I usually don’t consider the data from within the last several days to be fully baked, but it will help you to see trends nevertheless.

If you’ve ever used Google Analytics for a website, you’ll be familiar with the types of reports available on the developer dashboards. Each service gives a breakdown of accumulated events (that you logged with logEvent) and unique “visitors,” or users. For example, here is a snippet of the Google Analytics for an unreleased application:

You normally want to drill down into the “events” to get an idea of what is going on. This shows the Pinch Media event reporting for a random period of days for one of my games:

The event reporting again, this time in Flurry:

You can see the wide variety in reporting styles, and each includes the ability to download or save as CSV or XLS data files. You can easily import the data into Excel or Numbers and manipulate it further on the desktop, if desired. If you want to see how many users, or how many sessions occurred, you can easily get that too. In fact the level of detail in some reports is too much, and often a simple graph paints a pretty good picture, like this (also from Flurry):

Conclusion

It’s easy to add a tracking controller to manage the various analytics packages you might want to use. By merely commenting out a few lines (or #ifdef-ing them out) in the tracking controller you can enable and disable new ones without rewriting the other parts of your code. With a little bit of imagination, you can even allow the code to turn on and off the various tracking mechanisms. However, should you wish to provide a more generic “opt-out” mechanism there are other ways. See each SDK for specific details.

Hope this helps. Enjoy!