UPDATE: Apple Isn’t Stupid – They’re Just “The Man”

The problem with an application review process like the one Apple has in place is that there are humans on the reviewing end that are most likely too stupid or narrow minded to pick up on really innovative applications.

I don’t care if the reviewers are the people who built the platform and think they know what it can do like the back of their hand. They will not immediately understand the usefulness of some applications, and those applications may be game changers. Instead of being introduced to the public and living or dying by a meritocracy, they will probably get a message like this:

Dear Developer,

We’ve reviewed your application Big Five.   We have determined that this
application is of limited utility to the broad iPhone and iPod touch
user community, and will not be published to the App Store.

Sincerely,

What is Big Five?  A very useful application developed by Dirk Holtwick.  It’s an alternative web browser for the iphone that enables websites to use the native iphone APIs.  So, as a web developer if I knew that visitors where visiting through Big Five, I could offer special functionality, like integrated location using their iphone’s GPS, or accelerometer functionality, etc.  Oh, and I could do all this without ever having to know Objective C or Cocoa Touch – I could use the javascript I already know and love!

(Big Five is built on the phonegap project which I talked here about and contributed to here and here.)

It’s really a very interesting application that opens up game changing possibilities for the browsing experience!  But, alas Joe Q Reviewer has decided that this is of limited functionality to the public.

Why does apple think this application is of limited use to the public?  Here are two possible justifications (albeit bad ones) that I can think the reviewer may have.  (Oh, by the way they did not offer any of these justifications, just the short and incredibly useless message I posted above).

“Well, it is of limited use because there are no websites out there that take advantage of big5 yet.”  Huh?  The logic behind that is so incredibly stupid that I don’t know where to begin.

“This application is targetting developers more than it is targetting the public.”  It targets developers in order to provide a richer experience for end-users!  If Apple would provide phone-gap like functionality in Safari itself, then maybe we wouldn’t need Big Five, but alas they have not.

The bottom line is that the application review process is tedious, narrow minded, and broken.  I wish at the very least Apple would provide a reason or some pointers to why Big Five isn’t considered useful.  I also wonder if I should not waste any time developing phonegap enabled applications because Apple is too dense to understand the possibilities it opens up?

Here’s the solution I came up with.  I don’t understand enough about the rendering heirarchy to explain the why, but here’s the how:

In the GlassAppDelegate.m source file you should see a block of code that looks like the following:

 // Set up the image picker controller and add it to the view
	imagePickerController = [[UIImagePickerController alloc] init];

	// Im not sure why the next line was giving me a warning... any ideas?
	// when this is commented out, the cancel button no longer works.
	imagePickerController.delegate = self;
	imagePickerController.sourceType = UIImagePickerControllerSourceTypePhotoLibrary;
	[window addSubview:imagePickerController.view];

Simply move this block of code BELOW the following line. This renders the imagePicker object after the web view.

webView.delegate = self;

Problem – the imagePicker is obscuring the web view! Simply add the statment imagePickerController.view.hidden = YES; to the above block of code so that the entire block looks like:

 // Set up the image picker controller and add it to the view
	imagePickerController = [[UIImagePickerController alloc] init];

	// Im not sure why the next line was giving me a warning... any ideas?
	// when this is commented out, the cancel button no longer works.
	imagePickerController.delegate = self;
	imagePickerController.sourceType = UIImagePickerControllerSourceTypePhotoLibrary;
        imagePickerController.view.hidden = YES;
	[window addSubview:imagePickerController.view];

As it sounds like, we are just hiding the imagePickerController’s view – we don’t need it when the application starts anyways. But, we do need it when we access the images API through javascript, so find the block:

else if([(NSString *)[parts objectAtIndex:1] isEqualToString:@"getphoto"]){
				NSLog(@"Photo request!");
				NSLog([parts objectAtIndex:2]);

				webView.hidden = YES;
        [window bringSubviewToFront:imagePickerController.view];
				NSLog(@"photo dialog open now!");
}

and add the line imagePickerController.view.hidden = NO; above webView.hidden = YES; so that the entire block looks like:

else if([(NSString *)[parts objectAtIndex:1] isEqualToString:@"getphoto"]){
				NSLog(@"Photo request!");
				NSLog([parts objectAtIndex:2]);
        imagePickerController.view.hidden = NO;
				webView.hidden = YES;
        [window bringSubviewToFront:imagePickerController.view];
				NSLog(@"photo dialog open now!");
}

Voila! Compile and run the app and the keyboard should now appear when a form input is pressed on your iphone.

When phonegap initializes, it loads a few parameters from the client iPhone into your javascript environment.  By default these include the phone model, version, and gap version.  For my specific application, I wanted to load the iPhone’s unique identifier.

To add this uniqueIdentifier parameter is simple – looking in the phonegap sources, Find the GlassAppDelegate.m script in the Classes folder. Using Xcode’s method-finder bar, navigate to the (void)webViewDidStartLoad:(UIWebView *) method and replace it with the following:

- (void)webViewDidStartLoad:(UIWebView *)webViewLocal {
	NSLog(@"Page loaded");
	NSString *jsCallBack = nil;
	jsCallBack = [[NSString alloc] initWithFormat:@"\
				  __gap = true; \
				  __gap_version='0.1'; \
				  __gap_device_model='%s'; \
				  __gap_device_version='%s'; \
				  __gap_device_uniqueid='%s';",
				  [[[UIDevice currentDevice] model] UTF8String],
				  [[[UIDevice currentDevice] systemVersion] UTF8String],
				  [[[UIDevice currentDevice] uniqueIdentifier] UTF8String]
				  ];
	//NSLog(jsCallBack);
	[webViewLocal stringByEvaluatingJavaScriptFromString:jsCallBack];
	[jsCallBack release];

}

I’m simply access the uniqueIdentifier property of Cocoa’s UIDevice class.

To be able to access this paramter in your javascript, jump into the gap.js that you should be loading in your iphone web app, find the Device.init function, and replace with:

    init: function(model, version) {
        try {
            Device.available = __gap;
            Device.model = __gap_device_model;
            Device.version = __gap_device_version;
            Device.gapVersion = __gap_version;
			Device.uniqueIdentifier = __gap_device_uniqueid;
        } catch(e) {
            alert("GAP is not supported!")
        }
    },

Voila! You can now access the client iphone’s unique identifier via Device.uniqueIdentifier in your javascript.

Next up – figuring out how to access the keyboard through the UIWebView :X

Step 1: Develop a website on the stack of your choice. Better yet, use the iUI library to develop a website that looks and feels like a native iphone app.

Step 2: Download phonegap from github and open the project in Xcode.  Simply edit the file called url.txt in the Resources folder to point to the URL of your iphone app. Compile and run and you should see your website appear.

Step 3: To access the SDK libs, simply use their function calls:

     getLocation();

     // automatically calls this callback
     gotLocation(lat,lon) {
          // do awesome stuff with google maps, etc, etc.
     }

Check out more information on their google group.

I honestly think the iPhone, with it’s GPS enabled functionality combined with it’s google maps app, may revolutionize the location-based gaming genre, and even bring it into the mainstream.  The barrier to entry for these games is that you need 1) a GPS device and another device or format for interacting with the game or 2) a business-class phone running Windows Mobile or Symbian-OS.  The types of people that fit these two scenarios are a small fraction of the types of people that want/have an iphone.

Here’s a braindump of silly/fun generic location-based game for the iphone that’s been swirling around my head for the past few weeks.

• The iphone user downloads an app from the app store.
• They register and sign up for a team.
• There are two teams – doesn’t matter what they are.
• Players simply go to different locations and ‘capture’ them for their team.
• Capturing could be as simple as pressing a button, sending GPS coordinates to a server, reverse geo-locating that address and storing it in a database.
• Opposing teams can capture each other’s locations.
• First team to 500,000 locations wins
• There is a companion website for the game that shows activity, history, a map with the team’s locations, etc.

Obviously, there are some quirks that would have to be worked out.  A location would have to have a more specific and larger definition than ‘any GPS coordinate.’   There may have to be a cooldown on a location to prevent high-traffic locations from continuously changing hands.

Also, this provides the foundation for more complex and interactive location-based games.  There could be more than just 2 teams, or an infinite number of teams that players define.  There could be more complex rules for capturing a location.  A location may have to be ‘won’ by a game of tic-tac-toe or chess against a live person or a computer.  The game could have a theme or be branded as a fun compliment to a mainstream console or PC game.

Really, the possibilities are endless!  I’ll have another post in the near future with more details on an iphone location-based game we may or may not be working on at Figaro

Do you want a browser that lets you use hypothetical “open” applications that will be developed in the future, or one that lets you browse the web as it exists right now? You know, the web where many popular sites are built on Flash technology? Yeah, me too.

Someone should write a dystopian story about what would/will happen when Apple creates their own little sterile corner of the web where only apps built for their framework/libraries/safari javascript engine work properly.