Revisiting Android via Titanium

I’ve been focusing exclusively on iPhone development lately and only briefly looked at the Android SDK back when the G1 was just a glimmer in T-Mobile customers’ eyes. Without a doubt the iPhone App Store is the place to sell mobile applications right now. The Android Market simply can’t compete (at least, according to every single cross-platform development anecdote and statistic I’ve seen) when it comes to the rate of apps being sold. However, it’s likely to become a bit more competitive with some of the new Android devices that are coming out.

Motorola’s Droid is probably the most-discussed of the bunch, with beefy specs and a pretty slick design (and marketing campaign to boot). From a feature standpoint it’s enough to make an iPhone geek want to jump ship. Whether or not the new batch of Android phones will catch on with consumers is yet to be seen, but we know that developers are getting on board.

Now, I’m not about to ditch Interface Builder for the paltry Android equivalents and start churning out mountains of XML, but the hype is enough to make me give some form of Android development a second look. I’ve always felt that cross-platform development is less than ideal. Some cross-platform mobile development tools rely heavily on web views or not-quite-native controls to get things done. You write HTML, and they stick it in the native platform’s WebKit view and call it a day. Compared to an application developed with the native APIs you get something that is slower, looks worse, and behaves in very strange ways. You can’t build the type of experience that the hardcore iPhone fans will pay for that way.

Enter Appcelerator Titanium.

Titanium combines web development with native controls through its clever JavaScript bridge. It bridges your JavaScript code to many of the native API methods on the iPhone and Android. This allows Titanium apps to really look and feel like native apps (because they are native apps, with native controls). There’s even a module system to add additional native components, like OpenGL views for graphics, or libraries that don’t already come with Titanium. There’s a whole class of applications that seem like a great fit for Titanium. Many apps that follow the CRUD pattern and mainly deal with web services or web content are prime candidates for something like Titanium. Writing JavaScript after writing Objective-C is a bit of a breath of fresh air. Using familiar HTML and CSS markup to define layouts is great compared to configuring UITableViewCell objects on the iPhone.

Being an open-source project, however, there are still some rough edges. From the GUI tool, sometimes it takes two or three clicks (of the same button) to launch your app in the simulator, or to stop the simulator. I found that a fresh project that included Prototype.js would not build, even though Titanium let me choose it when creating the project in the first place. The ease of writing JavaScript is balanced by the difficulty of effective debugging from within the app itself. It’s back to printf-style (with log4j-style levels) debugging for now. There seems to be no apparent output when JavaScript errors occur at runtime on the iPhone, and the JavaScript bridge technology may need extensive development before any more powerful debugging is possible.

The best part is that it actually does work! Despite a few obscure bugs in the Titanium library my quick-and-dirty Mobomo Blog Reader application was fairly simple to develop.

Mobomo Blog Reader

In short, I am willing to give iPhone/Android cross-development a chance for many types of apps with Titanium, and I’m interested to see where the platform goes.

-John