Second impressions with PhoneGap

WebKit

I’m now a registered iPhone App Developer! After the usual waiting, emailing, phoning, and faxing that I won’t bore you with because blogs all over the world are full of people ranting about Apple’s registration process, I now have my developer key. (Personally, I don’t see what people are complaining about…it wasn’t all that painful.)

So now that I’ve written two iPhone applications, the first thing I wanted to do was load them on the phone and see how they actually behaved on real hardware. The results were, lets just say, less than thrilling. While they ran and did everything I would have expected of them, there are strange inconsistencies between the rendering of WebKit on the phone vs the desktop.

What went wrong

First off, let me state for the record that these are development versions of my apps, and I hadn’t figured on them working well right away. Lets face it, as developers we spend most of our lives working with broken crap, and try our best to make it less broken. That being said, I’m still an optimist and I had hoped.

First, what worked:

  1. The app’s icon, start-up screen, and general layout all behaved. Everything was where it was supposed to be.
  2. The app started up fairly fast. The only other app I’ve used that’s based on PhoneGap is the Translink public transit app (since I take a combination of a bus and train to get to work). It takes far longer than most apps to start, so I had expected the worse for my app.
  3. Clicking on buttons and other UI elements in my first app worked just fine. My second app, which uses more complicated gestures (pinch, rotate, etc) also worked without a hitch.
  4. My JavaScript ran quite well, with only a few minor exceptions.

Now on to what didn’t work. Keep in mind, the list above is a lot longer than I’d expected, so the oddities below are tolerable, for the time being.

  1. My CSS transitions are behaving very oddly. Instead of smoothly fading from 0% to 100% opacity, they jump between 0% and 100% immediately, back down to 0%, and then fade gracefully back up to 100%.
  2. The toolbar of my app, which is implemented as HTML/CSS, flickers whenever I click on buttons anywhere on the screen. This is especially weird since the events for those buttons, located in the center of the screen, don’t touch or interact with the HTML or CSS attributes of the toolbar in any way.
  3. For one of my apps I use an element with CSS sprites. None of these seem to work. When I change CSS classes, instead of changing the background position of the sprite image, it stays in the same skewed position.

Next steps

From here, I think I need to either use CSS classes, or set style properties from JavaScript exclusively. Mixing and matching might be causing problems. What do you think?

However, as I finish this, my wife and my in-laws want to go to the pub. So screw this hacking on frustrating code from home. I’m going for a pint and some appies!

Before I go though, I’m going to appeal to the iPhone and PhoneGap developer community at large: Have any of you encountered these problems before? Do you have any suggestions on how to make things work better?

Reblog this post [with Zemanta]

Tags:

About Michael Nachbaur

iOS app developer, livin' the dream. Working from wherever I find myself; Hawaii, Santa Monica, Vancouver, and elsewhere.

2 Responses to “Second impressions with PhoneGap”

  1. Brian.LeRoux February 16, 2009 11:14 am
    #

    Hey dude, we’ve seen similar flakeyness with the css transitions on mobile safari. Check out the examples in the web app dev center at apple.com and/or also check out how they did their dashcode examples. Totally native looking. XUIJS.com is our answer to doing lightweight dev too.

  2. Mike Nachbaur February 16, 2009 11:34 am
    #

    Yes, I’d certainly like to dig more into XUI. Anything we can do together to make developing iPhone apps more seamless, the better.

    I’ve noticed that some CSS3 features are flawless on Mobile Safari / PhoneGap, while others aren’t. Certainly opacity transitions rock on the phone, while manipulating absolute positioning is less than speedy.