Your application can create any number of NSOperationQueue objects, but the documentation suggests there is a practical limit to how many operations are executing at any given time. Specifically, adding additional queues does not mean you can execute additional operations. I find that a single queue is usually sufficient. Having access to a global operation queue means you can add, suspend, and cancel operations as needed. Add something like this to ApplicationDidFinishLaunching:

// Create the shared operation queue

sharedOperationQueue = [[NSOperationQueuealloc] init];

Notice all we did was change the selSucceeded selector to connectionSucceededWrapper:. The new wrapper method creates and adds the operation to the queue, as follows:

This post is part of iDevBlogADay, a group of indie iOS development blogs featuring two new posts per day. You can keep up with iDevBlogADay through the web site,RSS feed, or Twitter.

When using NSURLConnection there are only a couple of things to deal with. Unless you are using the synchronous version (not recommended) you will typically set up an object, such as your application delegate or a view controller, as a delegate to receive the NSURLConnectionDelegate callbacks. The main delegate message you need to handle are connection:didFailWithError:, connection:didReceiveData:, and connectionDidFinishLoading:.

One potential issue you face here is using a single object as delegate for multiple connections. Then your delegate message handlers will become messy as they attempt to determine which response goes with which request, etc. Now instead consider creating a utility class with just two public methods, like this:

myConnectionController interface

@interface myConnectionController : NSObject {
    NSMutableData* receivedData;
}
@property (nonatomic, retain) id connectionDelegate;
@property (nonatomic) SEL succeededAction;
@property (nonatomic) SEL failedAction;
- (id)initWithDelegate:(id)delegate selSucceeded:(SEL)succeeded selFailed:(SEL)failed;
- (BOOL)startRequestForURL:(NSURL*)url;
@end

Calling code example usage

id delegate = self;
myConnectionController* connectionController = [[[myConnectionController alloc] initWithDelegate:delegate
                                                                                   selSucceeded:@selector(connectionSucceeded:)
                                                                                      selFailed:@selector(connectionFailed:)] autorelease];
[myConnectionController startRequestForURL:[NSURL URLWithString:@"http://request.org/somequery.php"]];

Callback methods

- (void)connectionSucceeded:(NSMutableData*)data {
    // data contains response, e.g. JSON to be parsed
}
- (void)connectionFailed:(NSError*)error {
    // error contains reason for failure
}

myConnectionController implementation

@implementation myConnectionController
@synthesize connectionDelegate;
@synthesize succeededAction;
@synthesize failedAction;
- (id)initWithDelegate:(id)delegate selSucceeded:(SEL)succeeded selFailed:(SEL)failed {
    if ((self = [super init])) {
        self.connectionDelegate = delegate;
        self.succeededAction = succeeded;
        self.failedAction = failed;
    }
    return self;
}
-(void)dealloc {
    [connectionDelegate release];
    [super dealloc];
}
- (BOOL)startRequestForURL:(NSURL*)url {
    NSMutableURLRequest* urlRequest = [NSMutableURLRequest requestWithURL:url];
    // cache & policy stuff here
    [[NSURLCache sharedURLCache] removeAllCachedResponses];
    [urlRequest setHTTPMethod:@"POST"];
    [urlRequest setHTTPShouldHandleCookies:YES];
    NSURLConnection* connectionResponse = [[[NSURLConnection alloc] initWithRequest:urlRequest delegate:self] autorelease];
    if (!connectionResponse)
    {
        // handle error
    return NO;
    } else {
        receivedData = [[NSMutableData data] retain];
    }
    return YES;
}

And finally, the standard delegate methods for NSURLConnection are hidden inside the myConnectionController implementation. These should be familiar if you’ve ever used NSURLConnection directly:

NSURLConnectionDelegate methods

- (void)connection:(NSURLConnection*)connection didReceiveResponse:(NSURLResponse*)response {
    [receivedData setLength:0];
}
- (void)connection:(NSURLConnection*)connection didReceiveData:(NSData*)data {
    [receivedData appendData:data];
}
- (void)connection:(NSURLConnection*)connection didFailWithError:(NSError*)error {
    [connectionDelegate performSelector:failedAction withObject:error];
    [receivedData release];
}
- (void)connectionDidFinishLoading:(NSURLConnection*)connection {
    [connectionDelegate performSelector:succeededAction withObject:receivedData];
    [receivedData release];
}
@end

This post is part of iDevBlogADay, a group of indie iOS development blogs featuring two new posts per day. You can keep up with iDevBlogADay through the web site,RSS feed, or Twitter.

The changes in Lion are impressive; I consider it the most significant update since OS X was first released 10 years ago. Developers will want to rev their desktop apps to take advantage of the many new features, like Autosave, Resume, Versions, and Fullscreen. Some of the features we’ve long had on iOS are coming to the desktop in a big way, and this really does fulfill the “Back to the Mac” promise. If you don’t have a trackpad yet, you’ll want one for Lion. Lion’s on the immediate horizon with a scheduled July release.

Similar in scope is the iOS 5 update. Even if you don’t appreciate each of the 200 listed new features, you are going to be impressed with the new Notification Center, Reminders, and, hold the applause, wireless syncing. Billed as PC Free, Apple doesn’t even call this syncing, but it’s supposed to allow for wireless activation, backup, and updating. Although they’ve had some of this functionality on Android for a while, Apple’s superior user experience really shines here.

The game-changer of the three is of course iCloud, long speculated as Apple’s sync service “in the cloud.” But it’s much much more than that. By seamlessly storing data in a central wireless repository and automatically syncing it to all your devices (desktop & mobile), the problem of syncing multiple devices should be eliminated. Like many, I’ve suffered though the pain of MobileMe duplicating and removing contacts, calendar entries, and email settings. With six iOS devices and three Macs sitting in front of me right now, this solution can’t come soon enough. I expect some new breeds of apps designed to take collaboration (with self & others) to the next level. In addition, even for casual games like reMovem it will be easy to save game state so you can start it on your iPod touch and finish the same game later on your iPad.

If iCloud is the glue that holds apps together, then Xcode 4 is the all-in-one tool needed to build them. In order to work with any of the newer SDKs you should already be using a version of Xcode 4. I hesitated for quite some time, mostly because my experience with the early pre-release versions was less than satisfactory. Around the time of the VTM Seattle conference (early April) I made a conscious effort to switch from Xcode 3.2.6 to Xcode 4. Honestly I haven’t regretted it one bit. I know there are some things that don’t work right, but luckily I’m not using the Core Data modeling which is broken. If you do, then I can understand the hesitation.

I’ve been using Xcode 4 exclusively now for 3 months and it’s really a nice improvement in many ways over the previous versions. I’ve used it for a couple of client projects and submitted three of my own apps with it during that time. Once you get over the learning curve, and it is steep, you’ll be happy you made the switch. We’re often asked by new developers, “Where do I start?” Although all of the beginning iPhone development books reference Xcode 3, you’d be better suited to dive into Xcode 4 right away and avoid any uncomfortable transition.

After seeing some of the presentations at WWDC when the Apple folks made Xcode do the almost-unthinkable, it’s clear that its capabilities (now, and planned for the near future) were carefully thought out. Yes it’s a beast, but one you can customize to fit your workflow if that’s your preference. If you’re still on the fence about Xcode 4, I recommend you give it a try soon so you can get on with the new shiny bits. Lion is nearly upon us, and iOS 5 awaits your exploration!

This post is part of iDevBlogADay, a group of indie iOS development blogs featuring two new posts per day. You can keep up with iDevBlogADay through the web site,RSS feed, or Twitter.

The Symptom

I was in the middle of updating a project with the latest AdWhirl and Millennial Media SDKs. If you are not familiar, the AdWhirl SDK uses the Millennial Media SDK and both have been changed recently to use a newer method in the MMAdView class. This ended up causing a runtime error, followed by a helpful stacktrace:

2011-05-10 17:11:43.105 reMovemFree[1630:707] +[MMAdView adWithFrame:type:apid:delegate:loadAd:startTimer:]: unrecognized selector sent to class 0x118c48

2011-05-10 17:11:43.184 reMovemFree[1630:707] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[MMAdView adWithFrame:type:apid:delegate:loadAd:startTimer:]: unrecognized selector sent to class 0x118c48'

I puzzled over this for a few hours trying to figure out just why this happened. The headers files were correct, and obviously the project was linking without a problem. At this point I didn’t want to write any more debugging or introspection code, but I was really just looking for a way to find out exactly which methods the class did support. That turned out to be a dead-end anyway.†

The Cause

If you work with 3rd-party SDKs you might be accustomed to taking updates every few months or so. After some time you have probably updated certain libraries many times. I know I do this quite often. Many of you are probably way ahead of me here and can see where this is going. When you (literally) drop in a new SDK, and delete the old one, Xcode adds the new SDK path to the Library Search Paths for the project. Which is fine:

The problem is that Xcode didn’t delete the old SDK from the search paths when I dragged it out of the project. Since the build links with the first version of a library it finds on the search paths, any older version will usually do. Here’s what happens after repeatedly dropping in new versions of SDKs:

So what really happened was that I was linking to the earlier version 4.1.0 of the Millennial Media SDK, not the latest 4.2.4, even though both were on the library search path. This seems like a deficiency in Xcode, since it appears to go to lengths to track external referenced file dependencies.

The Solution

The simple solution for me was to go in and manually prune the old SDK paths from the Library Search Path setting for my project. And of course, add a note in my “todo” list for future updates to take care when adding new SDKs. Unfortunately the Xcode 4 widget for editing the Library Search Path setting is a little funky compared to the Xcode 3 version. I managed to get it shrunk down so small it is barely usable, but with a great deal of patience I was able to find and zap the offending entries.

Incidentally, you may want to take advantage of Xcode’s Source Trees preference, which lets you define an external folder, give it a symbolic name, and refer to in inside your project. This is super handy for two reasons, 1) it dramatically shortens all the nearly-unreadable $(SDKROOT)/../../../etc paths, and 2) it makes code portability to different machines with different folder structures much easier. It turns this:

into this:

Hope this helps a little, even if just to remind you to double-check those Library Search Path settings next time you drop in a new replacement library from a 3rd-party vendor. If you know of a better way to manage this issue, I’d love to hear about it.

† The commandline tool “otool” is great for examining dynamic and static libraries. The problem for me was that I examined the libraries I assumed were linking, not the ones that were actually linking. Looking at the wrong library didn’t help, since it obviously had the right method signatures:

This post is part of iDevBlogADay, a group of indie iOS development blogs featuring two new posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

I rolled my own code to prompt users for a review and the results have been excellent. We’re now getting mostly 4 and 5 star ratings in the prompt-enabled apps. The key of course is in the timing of the prompts. I’ll explain a little about how the code works, then discuss the results so far. For a far better complete code template and explanation see also Noel Llopis’s blog post from last year.

Since the stated objective is to get positive feedback without annoying the user, we want to filter out people who have just launched the app for the first time. One way to do this would be to use a timer, maybe wait until some period of time has elapsed. That’s probably OK, but could lead to a prompt coming up at a truly random time. Instead I have code that checks for two things: time elapsed plus a new high score achieved. To detect a desired length of time, use something like this in your -[UIApplicationDelegate application:didFinishLaunchingWithOptions:] method:

if (![defaults objectForKey:kFirstRunKey]) {

    [defaults setObject:[NSDate date] forKey:kFirstRunKey];

}

This gives you the timestamp of the first run time. I typically define kFirstRunKey to include a unique version number, so I can record the first run of each update. Now each time a new high score (use whatever criteria you see fit) is achieved, check the current time against the first run timestamp, like this:

- (void) askToRateApp {

 if ( ![self reachable] )

   return;

 NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];

 if ( [defaults boolForKey:kAlreadyDeclinedToRateKey] )

   return;

 NSTimeInterval elapsed = [[NSDate date] timeIntervalSinceDate:[defaults objectForKey:kFirstRunKey]];

 if (elapsed < kAskDelaySeconds ) // approximately 1 day

   return;

Notice a couple of interesting things here. First, I have a Reachability test to exit early if there’s no connection. Second, if the user has previously declined to rate the app, respect that choice and do nothing. Finally, there is a test to see if enough time has elapsed. If not, again do nothing. At this point you could prompt the user, or optionally add more tests. Maybe you only want to prompt on the 17th high score. Then something like this would work:

 NSInteger showAsk = [defaults integerForKey:kShowAskToRateKey];

 // If showAsk is 0, the prompt screen will be shown.

 // If showAsk is > 0, we decrement it now.

 if ( showAsk == 0 ) {

   feedbackAlert = [[[UIAlertView alloc] initWithTitle:NSLocalizedString(@"AskToRateApp",@"") message:nil delegate:self cancelButtonTitle:NSLocalizedString(@"NoThanks",@"") otherButtonTitles:NSLocalizedString(@"RateNow",@""), NSLocalizedString(@"RemindLater",@""), nil] autorelease];

   [feedbackAlert show];

 } else {

   showAsk = (showAsk - 1) ;

   [defaults setInteger:showAsk forKey:kShowAskToRateKey];

 }

}

In this example, the showAsk variable is tested to see if the counter is zero. If it is, we show the feedback alert. Otherwise we decrement it and store it back in the default settings for next time. Set a reasonable initial value for kShowAskToRateKey. Once the saved value reaches zero, the alert will be shown exactly once. All that’s left to do is handle the buttons on the feedback alert.

- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex

{

  if ( alertView == feedbackAlert ) {

    NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];

    if ( buttonIndex == 0 ) {

      // No Thanks

      // Don't Ask Anymore

      [defaults setBool:YES forKey:kAlreadyDeclinedToRateKey];

    } else if ( buttonIndex == 1 ){

      // Rate Now...

      // and Don't Ask Anymore

      [defaults setBool:YES forKey:kAlreadyDeclinedToRateKey];

      [self showAppStoreReviewPage];

    } else if ( buttonIndex == 2 ) {

      // Remind Me Later

      [defaults setInteger:21 forKey:kShowAskToRateKey];

    }

    feedbackAlert = nil;

  }

}

For the “remind later” choice here, I’m resetting the kShowAskToRateKey to 21, but this can be any value you like. I recommend you use analytics or some other method to determine an appropriate measure of how much time is “later.” FInally you need a small piece of code to make the App Store review page show. This technique can be used on iPhone, iPod touch, iPad, and Mac, but on iPad and Mac it is not possible to go directly to the review page. You’ll go instead to the App description and may want to explain how to actually enter a rating or review in those cases.

- (void) showAppStoreReviewPage {

  [[UIApplication sharedApplication] openURL:[NSURL URLWithString:deepLinkReview]];

}

For the deepLinkReview you will specify the URL that takes users to the application’s review page on iTunes. It’s pretty straightforward to construct the URL manually. Justine Pratt wrote all about this on her blog last year. You can also wrap the URL in a LinkShare link if you are an iTunes affiliate.

So how well does it work? Like Noel I have see an improvement in reMovem ratings from 3.5 stars to 4.5 stars, with about twice as many written reviews per day as there were a year ago. Still, 2 out of 3 users choose not to leave reviews. Of the rest, half opt for the “remind later” choice while about 15% click the “rate now” button. I suspect only a percentage of those actually complete the process, but it’s better than none. It’s debatable whether this leads to more sales, but having more 4 and 5 star reviews certainly helps when people are looking at the App Store description. I also believe they use the number of reviews as a gauge to an app’s popularity, and, in turn, as a data point for their purchasing decision. So the more reviews, the better.

—-

This post is part of iDevBlogADay, a group of indie iOS development blogs featuring two new posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

Full details on the new and improved MMTrackingController are on Github. Enjoy!

When I worked on very large projects at Avid we were saddled with hours-long build times. Xcode 2 introduced the distributed build feature, which really was a godsend to us. Products were typically built from millions of lines of code in tens of thousands of files spread out over hundreds of projects (or Solutions on Visual Studio). On Windows we started using Incredibuild with great success. Yes, the incremental builds were still sort of slow, but full builds went from 8 hours to under an hour. Incredibuild was good, but came with a hefty per-seat license fee.

On the Mac side we started looking into Xcode’s distributed build, based on the distcc and gcc technologies. This proved to be a great boon to us, too, even though there were some issues to work out. For starters, Xcode’s implementation uses Bonjour (Apple’s zero-config service discovery protocol) which means all resources must be on the same subnet. While this is not a problem for you the indie developer, a corporate environment has numerous subnets, so “discovery” of your cubicle-neighbor’s system is not always easy. Also, we made heavy use of pre-compiled headers in previous attempts to shorten builds, and this causes issues with distributed builds. Again, probably not a problem for most of us, but in a very large team where you might be modifying a header locally, that will certainly screw up somebody else’s build.

Fast-forward five years and now I am doing solo iPhone development, where the largest projects are a few dozen files that take 5 minutes to build. Not a big deal. Until you add OpenFeint, that is, or maybe cocos2d, or some other third-party repository, to your project. I have one project that takes 14 minutes to build on my Unibody MBP, thanks to OpenFeint. Certainly there are other techniques to help alleviate this, such as building OpenFeint as a separate static library, etc. But for the purposes of this discussion, let’s continue with the distributed builds.

I had two Macs until very recently, and one of them is hardly used for development. I updated the Xcode on it and turned on distributed builds, and that 14 minute build went down to 9 minutes. The beauty of distributed builds with Xcode is you set it and forget it. There’s no need to keep Xcode running on the other system(s), or remember passwords or futz with permissions. All you need to do is make a reasonable effort to have all the systems use the same version of the Xcode tools. Xcode will show (in the preferences window) which clients have compatible versions; this make it easy to identify which machine is not “playing nicely.”

If you need to you can create different “sets” of machines which have different capabilities. The default set is simply called Bonjour, and it will automatically include any and all machines available at build time. If you happen to be on different subnets or otherwise can’t find the other systems with Bonjour, it’s also easy to add devices manually to the list. Just press the + button below the right-side list of machines for that set.

Best of all, building with the distributed builds is simple. You don’t have to do anything differently. Just build & run or build & debug as usual. Xcode’s activity window and status lines will say “distributing build … ” now instead of just “building … “. For those doing automated builds, I think the xcodebuild tool will use distcc automatically if it’s enabled in Xcode’s preferences.

So if you have a second or third Mac in your shop, put it to work and save yourself some time!

—-

Background on iOS mobile advertising

One of the benefits of using an ad mediation layer is that you can serve ads from multiple networks at the same time. Two years ago there were a few ad networks that had iPhone SDKs which developers could use to publish ads inside their apps. For example, AdMob was and is a big presence in the iPhone ad network world. So big, in fact, that Google acquired AdMob earlier this year for an estimate $750 million. AdMob has an easy-to-use self service feature that lets anyone create their own banner ads, which are then published on iPhone app screens. Only apps that have the AdMob SDK integrated into them will display ads, and the developers of those apps earn a percentage of the revenues generated.

Ad revenue is measured in eCPM which means “cost per thousand views.” This number is derived from factors such as how much the advertiser is paying per click, how many clicks, etc. Since ad networks generally provide a mix of ads from a wide variety of advertisers, you use the eCPM as a barometer to indicate how well your iPhone app is generating ad revenue. In other words, it’s not really an indicator of how well the ad network or any particular advertiser is paying. So if your app displays 10,000 ads (called “impressions”) and you earn $5.00 then your eCPM is  $0.50, or $5.00 (cost) divided by 10 (thousand views). It doesn’t matter whether the advertiser is paying per click (CPC or cost per click) or per impression (CPM or cost per 1000 impressions) because you only care about the bottom line, the effective CPM or eCPM.

Aside from a higher eCPM, app developers are eager for what’s called a high fill rate. If each time your app requests an ad from the network it gets one, that’s a 100% fill rate. That’s great but it never happens. (Not entirely true: Google AdSense may return a PSA if no ad is available, so it appears to have 100% fill rate.) It’s not uncommon for fill rate to be very low, often under 50%. Why’s that? There’s only so much demand for the iPhone ad “inventory;” that is, there are more apps requesting ads than there are paying advertisers, at any particular moment. Due to the requirements of advertisers and the need to resist user fatigue (seeing the same ads over and over again, etc.) your ad requests might go unfilled. Refreshing the ads less often can help with this, but more on that later.

At some point the ad networks started allowing custom ads (or house ads) to make up for the unfilled requests. If you wanted to promote some of your other apps this was any easy way to allocate a percentage of requests to your own ‘free’ ads (you aren’t paying for those banners). Or you could promote other developer’s apps, which I did on a large scale last Christmas. Of course some of us started to find ways to manually combine different ad networks inside a single app, and it didn’t take long for folks like Tapjoy, Mobclix, AdWhirl (née AdRollo), and Burstly to form new businesses around the idea of server-based ad network mediation. AdWhirl was possibly first, formed in April 2009 by two guys who successfully filled a niche and were later acquired by AdMob. Their system allows you to build your app with the AdWhirl SDK and deploy it, and control ad requests from a web panel after the app has already been released. All the mediation services operate the same way; they act as middlemen to optimize your ad requests based on priorities you set.

I’ve been using AdWhirl since June 2009 with a good deal of success, even though there were some trying times just before the AdMob acquisition. It’s open source and the server code is available if you want to run your own system. I’m not going to focus on the pros and cons of AdWhirl versus Mobclix, etc.; that’s been blogged about ad nauseam. My advice is simply that your results will vary from what you read about elsewhere. Experiment and find what works best for you. My $1.00 eCPM might sound good to you, but it’s not as good as somebody else’s $2.50 eCPM. However, if that $2.50 eCPM is only for 10,000 impressions I can’t expect the same amount for 100,000 impressions, can I?

The optimization

When setting up your application on the AdWhirl web panel, you can adjust the rate of refresh and transition animation, and other parameters. Typical refresh rates of 30 to 60 seconds are best practice. But you can’t set the refresh rate for a particular network, and this could be an issue. Say you get a call from your rep at VideoEgg or MdotM or iAd (ad networks) offering a higher fill or rate due to promotion this week or next. Yes, you can increase the percentage of requests you make to their networks in the web panel. But you might still suffer from poor fill rate or otherwise can’t afford to allocate all your requests to a particular ad network. Here’s how I solved that problem on AdWhirl, thought I’m sure this technique will work for most mediation layers.

I should point out that this method is primarily effective if your app displays a banner all the time. If you use interstitial ads (show up temporarily between pages or levels of a game, etc.) this won’t be as effective. First you need to modify your code slightly to allow the “ad received” callback to recognize a particularly interesting ad and “park” on that ad. Here’s what this looks like:

AdWhirl callback

- (void)adWhirlDidReceiveAd:(AdWhirlView*)adWhirlView
{
    myAppDelegate* appDelegate = (myAppDelegate*)[[UIApplication sharedApplication] delegate];
    if ( [appDelegate.networkNames containsObject:[adWhirlView mostRecentNetworkName]] ) {
        [adWhirlView ignoreAutoRefreshTimer]; // pause ads to optimize CTR and eCPM
    }
}

Notice this relies on your UIApplication delegate object having a “networkNames” property. If that property exists and is an NSArray that contains the name of the most recently received ad network, it will pause the refresh timer. Voilà, your ads will not refresh until you resume the refresh timer, usually in response to user action such as flipping to a new view, or navigating to a different screen, etc. This means that when you detect an AdSense ad that’s currently earning higher eCPM, for example, you can park it there and hopefully generate higher earnings.

But where does this “networkNames” property come from? It’s set up in my UIApplication delegate, but you can put it anywhere you like. Since I want this to be dynamic, it is fetched from a server at launch, which means it can be modified at my convenience. I’ve created a property list file and use an asynchronous NSURLConnection to load it if the network is available. If there’s no network, there’s no ads anyway, so no big deal. The content of the file is pretty trivial, just list the names of the ad networks to ‘park’ on, like this:

Config file

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>1.5.3</key>
    <dict>
    <key>nnames</key>
    <array>
        <string>google_adsense</string>
        <string>iad</string>
    </array>
    </dict>
</dict>
</plist>

You can get the actual names of the ad networks from the actual AdWhirl (or other) implementation by just observing the mostRecentNetworkName as the callback is triggered. Though the plist file is a perfect candidate to load with the dictionaryWithContentsOfURL: method, that is synchronous and will block the application while loading. I suppose you could use an NSOperationQueue or separate thread, but the NSURLConnection is well suited to handle this. You can take advantage of the NSPropertyListSerialization class to convert the data into a property list, which is a dictionary. Here’s the code to get the configuration file and parse the results. Also note the retry on failure and after a fixed period even if it succeeds. This ensures that you can update the config file and users will have it without relaunching the app.

getConfig

- (void)getConfig {
    if ( [self reachable] ) {
        NSURL* url = [NSURL URLWithString:kMobileAppConfigKey];
        NSURLRequest* request = [NSURLRequest requestWithURL:url];
        NSURLConnection* connection =
            [NSURLConnection connectionWithRequest:request delegate:self];
        if ( !connection ) {
            [self performSelector:@selector(getConfig) withObject:nil afterDelay:kConfigTimerRetry];
        } else {
            receivedConfigData = [[NSMutableData data] retain];
        }
    } else {
        [self performSelector:@selector(getConfig) withObject:nil afterDelay:kConfigTimerRetry];
    }
}

- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data {
    [receivedConfigData appendData:data];
}

- (void)connectionDidFinishLoading:(NSURLConnection *)connection {
    NSDictionary* config = [NSPropertyListSerialization propertyListFromData:receivedConfigData mutabilityOption:NSPropertyListImmutable format:NULL errorDescription:nil];
    if ( config ) {
        id current = [config objectForKey:kConfigCurrentVersion];
        if ( current ) {
            self.networkNames = [current objectForKey:@"nnames"];
            [[NSNotificationCenter defaultCenter] postNotificationName:kConfigChangedNotification object:self userInfo:nil];
        } else {
        }
        [self performSelector:@selector(getConfig) withObject:nil afterDelay:kConfigTimerRefresh];
    } else {
        [self performSelector:@selector(getConfig) withObject:nil afterDelay:kConfigTimerRetry];
    }
    [receivedConfigData release];
}

I’m also posting my own kConfigChangedNotification to any parts of the app that care to notice such things. I’ll most likely use this for other features, that code is not shown here.

Conclusion

So does this work? In my case, yes. When Google AdSense for Mobile Apps (AFMA) started last fall, there was a requirement to pause ad refreshing. AFMA does its own internal ad refreshing and you don’t want to mess with that, nor violate the publisher agreement you signed. However that has since been relaxed, and you can refresh the ads every 180 seconds. Plus the latest AdWhirl SDK treats AdSense like all the others and would normally refresh it at the interval you specified on the web panel. Given that the AdSense ads are one of the highest paying (again, in my limited experience, your results will vary) I want to pause every time I get an AdSense ad. Before I did this, and with the normal AdWhirl rotation, AdSense ad revenue dipped because the ads weren’t visible long enough for the user to engage. The typical clickthrough rate went from ~ 3% to ~1%. After putting this mechanism in place the clickthrough rate is back up around 3%. That in turn translates to a higher eCPM and better revenues.

This post is part of iDevBlogADay, a group of indie iOS development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

What’s all this fuss about Game Center then? Apple says:

“Experience social gaming on your iPhone. Find friends or use auto-match to play multiplayer games against new opponents. Track achievements and compare high scores.”

But we already have that, right? Yes, in various forms since early 2009. There’s OpenFeint, AGON Online, Scoreloop, Plus+, and many others. How is Game Center different? Well, aside from the 800 lb. gorilla in the room (iAd, anyone?), Game Center is a system service that comes installed on most versions of iOS 4.1.  This reduces the amount of code your applications need to build with, and in theory simplifies the integration process. More on that later. This is not a tutorial, however, just a short ramble about my experience setting up a couple of games to use Game Center.

Sure, v1.0 of Game Center is a baby step, and there are/will be glitches. Yes, Apple has a lot of catching up to do. But they are already way ahead in some ways. A very large base of potential users with a pretty low barrier to adoption. Support for all languages used by iOS 4.1. I like to focus on that point, because two of my games are translated into 13 languages. My apps were translated before the existing online services were available, and when they came out they only supported English at first.

I decided it would not be acceptable to put in non-translated global scores and achievements, so I took a pass on online scores entirely. For reMovem free I initially posted (by hand) top scores to a web page, after soliciting users to send in screen grabs of their weekly scores. This sort of spiraled out of control and I stopped advertising the link to the high scores web page (sorry).

By the time I got around to doing a couple of holiday games, about a year ago, I settled on AGON Online as my online leaderboard service. Integration was fairly simple, and Daniel and the rest of the staff are as good as they come. Working with them truly was a pleasure. Even so, I was just looking for an English solution at the time. AGON has teamed with some great developers, and they have great games, but there’s still only a couple hundred titles. Adoption rate for me was pretty low, and I begun to wonder if it was worthwhile.

Earlier this year I added support for OpenFeint to reMovem 2. They’re the grand-daddy of online services, at least in iPhone terms. They have probably got thousands of games and developers and upwards of 30 million players. That brings a boatload of users to the table, but, again it’s only English. I haven’t translated reMovem 2 so that’s OK. Adoption of OpenFeint inside reMovem 2 is slightly higher, but it’s still about 1 in 5. OpenFeint is poised to be a gamer’s portal on the iPhone, and very soon Android too. It appears that Game Center will compete with OpenFeint, but there’s talk of some sort of interoperability from the OpenFeint side. We’ll see.

Even though I’m keen on Game Center’s language support, Apple’s done a disservice to the millions of iPhone 3G owners who can’t participate in the fun. For unknown reasons, Game Center support is limited to iPhone 4, iPhone 3GS, and iPod touch (and generation and later). This is great news for iPod owners, though, which makes sense since Apple’s pushed the iPod as a great game device. The decision to not support the iPhone 3G is no surprise to developers, but the media made much hay with this last week, which just begs the question: Why?

As with iAd, Apple has high hopes for Game Center. I’m certain it will be around next year. So I’m comfortable finally adding online scores to reMovem (and hopefully reMovem free), knowing that the users won’t have to have a partially-translated interface.

Technically, Game Center is part of Game Kit, which has been around since iOS 3.0. The Game Kit framework also provides peer-to-peer connectivity and in-game voice. Game Center debuted in beta versions of iOS 4.0, but only as a developer preview. Game Center itself provides functionality for leaderboards, achievements, and multiplayer game discovery. Earlier this summer Apple announce the September 8th launch date, and the rush was on to get games submitted with Game Center features.

I’d been eager to add Game Center to reMovem since it was announced. Developers are excited because Game Center uses a concept called blocks for most of the asynchronous callbacks. Blocks are available in iOS 4 and later and OS X 10.6 and later. Objective-C and Cocoa make it easy to mix code that requires iOS 4 and older code, for example, so your single binary can run on iOS 3.1.3, 3.2.2, 4.0.2, and 4.1. Weak-linking the Game Kit framework allows you to target older devices and OSes. Unless of course your game requires Game Center to function at all (i.e. multiplayer).

I added leaderboards for reMovem’s four modes. It’s easy enough to know where to make the appropriate calls to add values to the leaderboard. The problem is that almost everything in Game Center is asynchronous. Because there is no offline support (a major deficiency, in my opinion), you must detect and retry score submissions. This is the typical pattern to report a score:

- (void) reportScore: (int64_t) score forCategory: (NSString*) category {

    GKScore* scoreReporter = [[[GKScore alloc] initWithCategory:category] autorelease];

    scoreReporter.value = score;

    [scoreReporter reportScoreWithCompletionHandler:^(NSError *error) {

        if (error != nil) {

            NSData* scoreReporterAsData = [NSKeyedArchiver archivedDataWithRootObject:scoreReporter];

            [self reportScoreLater:scoreReporterAsData];

        }

    }];

}

Note the block object (begins with ^) which detects the error and calls [self reportScoreLater:scoreReporterAsData]. That’s where the fun begins. You can implement this any way you see fit: add it to a Core Data store, or push it onto an NSArray, or into an SQLlite database, and attempt to re-submit again later. It’s clear Apple expects you to persist this information and retry even after quitting the app and relaunching. The exact same situation exists for achievements. Both are begging for a standard offline implementation, the way all other services operate.

One other funky thing to deal with is the whole authentication issue. It’s seriously complicated by the multitasking devices, because a player can be “signed in” when they start a session, then switch to Game Center and sign out, then switch back to your game, etc. There are notifications you can register for to detect authentication changes, but the UI to sign in within a game is weak, and offers no option to customize. Besides, there’s no standard UI to allow users to enable or disable Game Center features, so it’s unclear how you’d even let them do so. If they cancel the authentication once in a session, does that mean for all time? I have no idea. What if they change their minds later and want Game Center features? Again, unclear. I opted to add a switch on the Info options screen which simply says “Game Center.” If the user puts the switch “On” I will attempt to authenticate them whenever necessary. This has been in the App Store for about a week now and I’ve had a few players complain that they can’t turn it off. I’m pretty sure they are just not exiting the app completely (a whole other blog post!) on iPhone 4 or iPhone 3GS.

Finally there is the fun of using iTunesConnect to setup the whole Game Center configuration for your application. This is not difficult, and the documentation is fairly accurate and complete, but there are many scary areas which warn “once your application is live this cannot be changed”, etc. If you’ve worked with In-App Purchase you’ll be familiar with the whole concept of working within a developer “sandbox.” Game Center adds new pain to that experience, but at least it works fully in the simulator. Before September 8 Game Center only ran in a sandbox, but since launch it’s way too easy to get confused about whether your device is signed in to the real service or the developer (sandbox) service. An impractical solution would be to dedicate several (one simply won’t do) devices to testing your sandbox builds. I struggle with this throughout the day.

It would be nice to be able to reset player scores and achievements. I’m hoping iOS 4.2 (promised for Fall) will address this and a couple of my other gripes. We haven’t seen the beta for 4.2 yet, so it’s too soon to say. I do fully expect this service to improve rapidly as Apple learns from the launch of Game Center. Have you implemented Game Center yet? If so, what has your experience been like? Comments welcome.

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.