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?

PhoneGap currently has an issue with the keyboard not appearing whenever a form input is selected on a web site.  The key here is that the keyboard IS actually showing up, but it is being drawn behind the UIWebView used to render the webpage.

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.

Yesterday I wrote about the nascent project, PhoneGap, that acts as a Cocoa Touch-native wrapper to your web-based application.  I’ve been playing with it non-stop since I stumbled accross it and it works like a charm!

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

Stumbled across phonegap – a project that allows you to publish a native iPhone app that simply acts as a pass-through to your web application of choice.  The best part is, you can tap into some of the core frameworks of the iphone SDK via javascript, i.e. you can tap into the Core Location framework, Acceleration, etc, etc! Hats off to the developers of this project. It’ll make my life a whole lot easier.

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.

Location based gaming isn’t anything new.  Take a look at the wikipedia page for location-based game to see a wide variety of games dating back to around the turn of this century.  But, what are all these games missing?  Hint: it starts with an i and rhymes with dry scone.

(more…)

… until they add support for flash.  Period. The recent news about the whole SproutCore framework for iphone web apps just doesn’t do it for me.  Venture Beat puts it well when they say:

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.