Open Source Solution for Multiple Mobile Platforms

The Challenge

Developing software for mobile devices is a bit of passion of mine — or perhaps I should call it a pathology. Unfortunately, I sometimes have some difficulty deciding which platform to spend time working on as they each have intrigue and merit, and over time my clients ask for applications on different platforms so I cannot simply ignore the question. With my product manager hat on where I am concerned about which platforms are viable and likely to stick around for a while, some platforms are simply more attractive than others from this commercial perspective — BlackBerry and iPhone come to mind.

Research in Motion, the folks behind the BlackBerry family of devices, have sold tens of millions of their addictive devices, and an argument could be made that up until the most recent device launches their devices have been mediocre — but that has not stopped them from dominating the enterprise business marketplace. Then there is the “too y for my pda” iPhone which boasts over a billion application downloads recorded at the iTunes App Store in just a year — mostly consumer oriented applications, though the enterprise market has been penetrated by the Caped Crusaders from Cupertino. Look out McDonalds, the folks at Apple might be stealing your “Billions and Billions Served” signs. Add in the legions of Android developers and the growing rumors of potential new Android-powered devices and we just cannot ignore Android.

Of course, Palm just released the WebOS SDK to developers — hoping this innovative operating system will gain enough momentum to make headway in a market that just may have already gotten away from them. Microsoft Windows Mobile has a respectable marketshare, though despite arguably the best integration with the Enterprise, they tend to get ignored in many discussions of viable mobile platforms. And, for those not in North America, Symbian is the biggest fish no one has ever heard of. From a marketshare perspective, they are huge, however North American developers have little knowledge and dare I say interest in developing for Symbian — because we rarely see them!

A couple of years ago at a Handango conference I attended someone from Nokia told me that Symbian wasn’t big in the U.S. because the networks were inadequate for their devices and therefore there just wasn’t a big push to sell them here. I couldn’t tell what to make of that response. I think the look on my face said the same thing. Any way, I am not sure if I should admit this, but I have actually developed applications on all of these platforms, some more than others of course. While every one of these platforms is of interest to me, as a (professional) software developer I’ve got to choose where to put my development energies as I still need to feed my kids. So despite my penchant for getting distracted by shiny objects like gps, touchscreens and accelerometers, I’ve got to pursue profitable activites and not spend all of my time climbing the learning curve of each of these platforms.

That challenge here is that the tool chains for these platforms of course vary, not to mention the code structures, coding framework, and we cannot forget testing! Table 1 lists some rudimentary information about each of these mobile platforms and their tool-chains. Try to find the similarities:

There is a mixture of C/C++, Java, .net languages and a variety of development environments and emulators. What if I want to target my application to numerous platforms but I don’t have the resources to write (and support) six different applications all at once? And let’s assume that the application I want to write doesn’t need to be a fast OpenGL graphical interface with killer graphics, sound effects and Wii-like controls. Heck, I don’t even need a compass for the application I need to write for my market! Maybe I should just write a web application and make everyone connect back to my server? That makes code distribution a snap, but I really don’t want a browser based app — it’s not the right solution for many mobile applications. I cannot ignore the problems of spotty connectivity and browser differences from platform to platform. In fact, everytime I click on one of those applications on my BlackBerry that launches the browser and I have to wait for my EDGE network to load some sign-in page, I just cancel out and hide the icon because I don’t want to stumble upon that application again.

I want the application to be local and responsive — not a connection to the mothership-for-every-screen kind of application. OK, so I know I want a native application, but please tell me I don’t have to master Eclipse with Android, Eclipse for webOS, X-Code/Objective-C/Cocoa Touch, BlackBerry’s IDE, Visual Studio version latest and whatever the latest tool I need for Symbian. Is there a happy solution to my greedy goal of writing quality mobile software without feeling like I’ve entered the decathlon? Do I have to learn all of these languages, frameworks, and toolchains? And support them over time? Perhaps there is an answer!

Source or Binary Compatibility?

A couple of weeks ago we looked at the XMLVM project and their technique of taking the code output of your project, namely Java byte codes or .net’s common language runtime (CLR), and magically turning that into code that can run on other platforms. It is a very cool technology however due to the black-box approach of converting one platform into another, a lot of work needs to be done inside of the black-box in order to effectively port all of those frameworks. They are making progress, but it is a tall order and something we should keep our eyes on as it matures. So, what other choices do we have? This brings us to another open source project that might be able to help us at the source level. And that source is? HTML, CSS and JavaScript. No, I’m not talking (explicitly) about WebOS, but good guess. I’m talking about PhoneGap.

Introducing PhoneGap

PhoneGap is an open source project aimed at mobile software developers who need to thread the needle between the extremes of device specific projects and proprietary toolchain knowledge on one hand and browser based, mobile optimized web applications on the other. With PhoneGap, developers write code in HTML and Javascript. The code they write is actually written in whatever toolchain is required by the platform (i.e. Eclipse for Android, X-Code for iPhone, etc.), however all of the code written is done in HTML and Javascript files. The toolchain is required for packaging and signing of applications. The premise is that we are willing to invest enough in the platforms for packaging and deployment, but we want to spend our energies writing application logic and layout in common and familiar tools. HTML and Javascript certainly meet those objectives in terms of high quality layout control and appearance while also providing a more than adequate coding capability in the JavaScript language.

OK, so how does it work you ask? Each of the supported platforms, which at present include iPhone, Android and BlackBerry, have an HTML5 capable browser which can be embedded into a “native” application as a widget or a control of some sort. The native application launches, creates an Activity (Android),UIView (iPHone),Screen (BlackBerry) and wires a browser window to the native application. A developer-modified index.html file is loaded into the “browser” and the application is up and running. That index.html file is deployed along with the application — no home runs to a webserver are necessary. In fact, the application bundle may contain multiple HTML and Javascript files which contain the complete user interface and logic for the entire application.

Any time something is needed to take place on the device itself, for example playing a sound or performing a GPS lookup, a “link” or button on the page triggers native code in the project. This native, device specific code is supplied in source form in the PhoneGap download. Over time, the PhoneGap team has been enhancing which native features are supported. The goal of the project is to allow application developers to be concerned with only application features and not have to mess with integrating with device specific interfaces. Sounds like it is on track with the things we have in mind of not having to become intimately knowledgeable with multiple platforms!

Using PhoneGap is very straight forward. You download the latest archive from their website, unzip it and open it in the environment of your choice. For example, for iPhone, you would open the project in X-Code. In fact, clicking on the project file will automatically open the PhoneGap proejct. Once in that project, modify the code in index.html. Rinse and repeat until the application logic is to your satisfaction. Is it that simple? Yes and No. Yes, those are the steps needed but No, not everything you want to do on all platforms is available yet. However many applications have been written and deployed with PhoneGap and more are yet to come. The PhoneGap team seems motivated to bring this functionality to fruition and I think the mobile developer community will be the better for it.

What about Palm

I cannot finish without making a comment about the fact that Palm has concluded the super-secret early access SDK program and made the Palm WebOS SDK available to all registered developers. This is an important milestone and will begin to reveal the story about how well WebOS will be received by the developer community at large. What I find interesting is how similar WebOS’s approach is to PhoneGap’s approach. Both are relying on HTML/CSS and JavaScript to carry the day. I think they’ve got a good model here and I am eager to see how things play out in the future. Speaking of the future, my plan is to write a couple of applications with PhoneGap across the supported platforms and report back here on my progress. If anyone has a particular kind of application they would like to see, please email it to me.