Today, Salesforce moved the mobile framework to GA. We’ve been using this in RingDNA since it’s first beta release at Dreamforce.

A common issue w/ large native applications (connected to a remote datasource) is the amount of UI bindings you need to code. 

Objective-c doesn’t like null values all that much… If you’re building a lot of simple read-only screens, it’ll take quite a bit of code to check for null values on every field. You can use obj-c blocks in your response callback to insert empty NSString objects in place of nulls to allow for auto-binding to UI elements. 

So, using blocks we can do something like: 

- (void)request:(SFRestRequest *)request didLoadResponse:(id)jsonResponse {
    NSDictionary *dict = (NSDictionary *)jsonResponse;
    NSLog(@"Response: %@", dict);
    
    if ([[dict valueForKey:@"totalSize"] intValue] > 0) {
        NSDictionary *firstResult = [[dict valueForKey:@"records"] objectAtIndex:0];

        [firstResult enumerateKeysAndObjectsUsingBlock:^(id key, id obj, BOOL *stop) {
            NSLog(@"KEY: %@", key);
            if ([key isEqualToString:@"Account"]) {
                [obj enumerateKeysAndObjectsUsingBlock:^(id accountKey, id accountObj, BOOL *accountStop) {
                    if ((NSNull *)accountObj == [NSNull null]) {
                        NSLog(@"NULL Found: %@", accountKey);
                    }
                }];
            }
        }];
        
        self.contactSFDC = firstResult;
        
        [self setContactInfo:firstResult];
    } else {
        // Load alternate view? No contact was found
    }
}

You can see that this is less code than looping over the allKeys NSArray (it has performance benefits as well). I’m showing the nested Account relation in this response so you can see how to traverse two levels from the SOQL query. Also, notice the casting of the obj to NSNull so we can properly check if the field is null. 

I’m finishing the final chapter of my book this afternoon. 

Yeah, not sure if this was just Halloween spirit or what… the last chapter is a cocos2D / Augmented Reality game called Attack of the Alien Jack-o-lanterns. I’m also not sure why they are alien… but, they came from somewhere to take over our human bodies. 

In this chapter, we create a basic cocos2D game where pumpkins are taking over our faces. Random people in the camera view have a pumpkin (some people aren’t affected) taking over their head… like you see here: 

Doesn’t that kind of make you want to shoot the pumpkin?…well, good thing. When you tap the pumpkins they explode. Not sure if there’s any business value here… but, gaming was one of the topics we had to cover in the text.

I’ll see if I can clean this up enough to get it on iTunes around Halloween. 

I’m working on the final edits for my upcoming Professional iOS 5 Augmented Reality book. I posted a few screenshots from the facial recognition tutorial chapter already. I got the kids help with that chapter. I covered two other approaches to facial recognition in the book as well, with some help from Elvis. 

Chapter 12 covers three approaches to facial recognition from iOS applications with sample code. I discuss OpenCV, the more traditional approach as well as a more web friendly REST API from face.com. Lastly, we discuss the new CIDetector classes that shipped with iOS 5. 

With some help from the moriarty library, we measured the performance of the different approaches. CIDetector came out on top for native analytics. Outperforming OpenCV and face.com. Of course, face.com also includes a full round trip to a REST API. The fact that it even comes close to the performance of a full native API is impressive on its own. 

I’ve been using the Force.com toolkit for iOS for a while now. Back at Appirio, we used this for many mobile projects. I’m working on a project called ringDNA in which we’re using oAuth instead of the local login to the SOAP API. What’s interesting about the toolkit, since the change to FDCServerSwitchboard from ZKSServerSwitchboard is the lack of current user information. I’m not sure if this is an oversight of if it’s just more secure to do this on your own. Either way, if you’re using oAuth, there’s a missing step in the library. (at least, it would be more convenient if this was done and populated the UserInfo prop like the SOAP one did)

- (void)loginOAuth:(FDCOAuthViewController *)oAuthViewController error:(NSError *)error
{
    if ([oAuthViewController accessToken] && !error)
    {
        [[FDCServerSwitchboard switchboard] setApiUrlFromOAuthInstanceUrl:[oAuthViewController instanceUrl]]; 
        [[FDCServerSwitchboard switchboard] setSessionId:[oAuthViewController accessToken]];
        [[FDCServerSwitchboard switchboard] setOAuthRefreshToken:[oAuthViewController refreshToken]];
        [_rest oAuthIdentity:[NSString stringWithFormat:@"%@?oauth_token=%@", [oAuthViewController idUrl], [oAuthViewController accessToken]]];
        [_rest activeCalls];
        
        [self dismissModalViewControllerAnimated:YES];
    }
}

That’s pretty much it. The _rest class is something I wrote to handle obj-c REST callouts asynchronously while tagging them all with unique callback IDs. It’s an extension of the NSURLConnection class with some delegate methods.