Brit Gardner’s Site

all the code that’s fit to printf()

Wow, I got a lot of feedback yesterday.  Protip: don’t call Apple stupid in the title of your blog post if you want Apple fans to read the content of your post!  I got some really thoughtful comments which I’ll go over here, but I got a lot more email that, if there were Cliff’s Notes, would read something like, “no your [sic] stupid.”

bud says:

I’m sure apples boilerplate rejection has nothing to do with the apps rejection.

It is pretty obvious why they would reject it; to prevent hooks from websites into the iphone; potentially malicious hooks.

Isn’t this obvious? If it is not obvious, you are disingenuous.

Yes, I agree - most likely Apple is not ignorant of the implications of Big5 and phonegap projects!  There is a small chance that the review team at Apple just didn’t “get it”, but most likely they did get it and decided to keep it under wraps.

Why? Peter agrees with bud that there are security concerns:

As has been pointed out, this is rejected because it allows an external application to access information about the iPhone. That said, he’s right that someone at Apple should have explained that rather than using the “limited utility” explanation.

To wander a little bit afield, though, I worry about this “limited utility to the broad iPhone/iPod touch user community” sentence.

One of the reasons for third-party developers is to address these areas that are of limited utility to some but valuable to others. For example, medical dictionaries are not of interest to “the broad iPhone/iPod touch community”, though there are some who will find these invaluable. So is Apple now going to try to determine whether there really is a market for your application and decide whether or not enough people would be interested in it?

He brings up a good point about the implications of Apple deciding what is considered ‘useful’ to the general public.  2 years ago if you had asked me if Twitter was useful to the general public, I would have laughed in your face.  Now, I read the RSS feeds of a bunch of different people on it and I consider it one of the best ways to access people’s raw, unfiltered thoughts.

Imagine if Apple owned the internet platform and just didn’t see the usefulness of this app…

But, as I said - Apple isn’t stupid (in the ignorant way), they are just turning into “The Man.”  My partner in crime got so riled up he went so far as to suggest Apple is the new Microsoft.  Personally, I would rather have the new innovative Big5 browser and then patch the security risks later, rather than shutter it out of fear.

As much as I hate to use Internet Explorer as an example of anything but a steaming pile of sumo wrestler dump on a burning tire, imagine if the 90+% of the people in the 90’s hadn’t been exposed to it because it might have security risks?  We know now that it was chock full of nice juicy security risks, but I would say the exposure to the internet and booming of the industry that pays my bills is a far greater consequence!

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:

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

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:

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:

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

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:

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:

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:

Check out more information on their google group.