I’ve merged the results of my UIControls branch on github into my master branch. I think my little experiment went well, and I’d love to get feedback from people on how this new API works for you. I still have some great plans for it, but before I get ahead of myself, let me cover what I’ve done:

Changes:

• Refactored the command call API to allow for a richer set of arguments to PhoneGap commands
• Moved some commands around to more appropriate classes (e.g. Alert and Vibrate both moved to Notifications)
• Reorganized the XCode project so commands are clearly separated from PhoneGap infrastructure
• Renamed the Settings.plist PhoneGap config file to PhoneGap.plist, and created a new Settings.plist file that contains custom application-specific configuration.
• Made all PhoneGap commands inherit from a common base-class that auto-loads its own Dictionary of configuration from the main PhoneGap.plist file.
• Added UIControls command class that exposes tab bars and toolbars to JavaScript.
• Updated the demo to show off tabs and toolbars

All that looks like a big change, but almost all of it was infrastructure changes that were necessary to get UIControls to work. Previously, all PhoneGap commands were class method calls, meaning it was very difficult to maintain state between command calls. Now that commands are actually called on an instance of a given command class, it’s easier to maintain state. So when a tab bar is created, multiple calls can be made, each to construct different aspects of the UI. Without all this, the following example would have been much more complicated:

They say a picture’s worth a thousand words. Frankly I think inflation has really taken its toll on the cost of words, but nevertheless here’s a quick view of what’s been going on in my UIControls PhoneGap branch on Github.

In that screenshot the UIWebView frame, aka the actual webpage content of the app itself, was automatically resized so the toolbar and tabbar has room to be shown. And yes, those are native widgets for the toolbar and tabbar.

Last Thursday I went down to Nitobi after work for a couple of beer and a chat about PhoneGap before I had to go give a couple lightning talks at the Vancouver.pm Perl Mongers group. My hour chat with a couple of the Nitobi crew turned into over 2 hours, making me late for Vancouver.pm, but I think the effort was worth it. First off, they have good taste in beer. Second, I had an opportunity to do a little show-and-tell of my PhoneGap branch on Github. Not only did they like my changes, but I told them what my roadmap of features for PhoneGap includes, and I think they’re on board.

Like many people before me, and I’m sure many more after, I’ve had an ungodly amount of difficulty with Apple’s iPhone certificate provisioning system. I personally think it’s a brilliant solution to a difficult problem, but unfortunately for us they made it a pain in the ass to deal with. I’ve only run up against a few basic issues with them, and thought I’d document my solutions to them here.

I’ve been working on some pretty fun changes to PhoneGap recently, which hopefully will be merged into the main branch soon. (Brock? Any word on that? It’s now 12 days, and counting) In my branch of PhoneGap I added console logging support, I implemented queueing of commands so they don’t walk over each other, and finally (and perhaps more importantly) improved the JavaScript build system and infrastructure.

PhoneGap’s JavaScript Structure

PhoneGap is broken up into several different .js files, each of which implements a part of the PhoneGap API. And with recent changes to PhoneGap’s Objective-C code, the implementations of those commands are divided nicely into their own separate classes. Additionally, there’s platform-specific implementation hooks of those APIs which make the necessary calls in to the native code that implements those commands. At build time, a Rakefile is used to compile these together into one single “phonegap.js” file that can be included into your application.

So my wife is probably one of the coolest geeks I know. Would you like to know why?

We were just watching the intro for a new episode of The Simpsons where Comic Book Guy ate a dinner, and finally was given the bill which showed, among other things, the tax. So, she pulled out a calculator, figured out the food service tax percentage, and went straight to Google to see which state Springfield is in.

I’ve said it many times before, but as programmers we tend to spendthe bulk of our time working with broken software, and we try to endeavor to make it less broken. When it’s not broken enough to keep people from using it on a day-to-day basis, you release your software. Some places do this better than others, and at my day job we’re really good at it. We are very dilligent about our software releases, we have tons of unit tests, system test automation, a nightly test “dashboard” that shows us how well our tests passed, and so forth.

I keep finding amazingly good blog posts or links of interest that I end up bookmarking for my own uses, but I end up having to tell people on a case-by-case basis why one article is good for one reason or another. I end up bookmarking on my Delicious account and sharing blog articles I like via my Google Reader account, but it’s becoming increasingly obvious that this isn’t enough.

I’ve managed to avoid C and C++ programming for most of my career of 15 years. I’ve dabbled, and then I’ve run back to my favourite languages. Besides, as a web developer there hasn’t often been a need for me to delve that deeply into the machine.

Now that I’m developing iPhone applications, that’s all changing. I’m using PhoneGap to develop my apps, but some of it was buggy, and others just didn’t do what I needed to do. I’m integrating the AdMob and Medialets APIs into my application, which means Objective-C programming. After picking my way around, and continuing on the work my friend Scott McWhirter developed, I think I’ve come up with something that not only works well, but helped me to learn and love Objective-C.

My wife and I don’t celebrate Valentines Day. This is for several reasons, but the biggest reason is that we don’t like being made to buy overpriced flowers and chocolates, pay for overpriced restaurants, and buy overpriced cards that convey generic and meaningless messages of love to someone I already love and have far more profound ways of expressing it than what Hallmark has cooked up. So basically, we’re both jaded and cheap.