dcsimg

Open Source Solution for Multiple Mobile Platforms

There is a never ending debate about which platform is best: Android, iPhone, Palm, BlackBerry, Windows Mobile, or Symbian. But what if the correct answer is ... JavaScript? Is this a joke? Not according to an open source project named PhoneGap.

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 sexy 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:

Platform Tool Chain Open Source
Android Java, Eclipse & Android Tools Yes
BlackBerry Java, Proprietary JDE, Eclipse alternative No
iPhone Objective-C, X-Code, Cocoa Touch Framework No
Palm pre/WebOS HTML, CSS, Javascript, Mojo Framework, Eclipse with plugins Hybrid
Windows Mobile C/C++/C#/vb, Visual Studio Version 200X No
Symbian C++,Java, Visual Studio, Codewarrior, GCC Yes & No, moving target

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.

Comments on "Open Source Solution for Multiple Mobile Platforms"

mojavelinux

I don\’t know how you can even put BlackBerry in the same category with the iPhone and Android phones. Using a BlackBerry is simply painful. When I switched over to the G1 phone, it was like there was this whole world I was missing out on.

With that said, PhoneGap does look interesting because it means being on an Android phone, it\’s less likely that I would get locked out by a company too lazy to port their application to Android, which is just as capable as iPhone.

Reply
bruceboyes

Have you looked at Titanium Appcelerator? I have just started. Sounds sort of similar to PhoneGap. I guess one conclusion is that with so many people trying to solve the problem of writing once for many smartphones, it must be seen as Something Worth Doing.

But wait a sec — wasn\’t this supposed to be what Java did? What went wrong there? Palm briefly flirted with Java then abandoned it. Google wrote their own VM instead of licensing from Sun. What\\\’s the backstory here to why this problem wasn\’t solved already by Sun Java?

Reply
fableson

Blackberry has too much market share to ignore and too loyal a following to ignore. And, they are great on battery life and a capable multi-tasking environment.

I am taking a look at Titanium\’s Appcelerator. It looks like they will also be presenting at InsideMobile conference put on by O\’rielly this coming weekend. I hope to get a few minutes to chat with them.

HTML/CSS/JavaScript are the \”new Java\”. The design approach has legs, let\’s see how it pans out. Palm is betting their future on it from all appearances.

Frank

Reply
biglinuxguy

@bruceboyes

The backstory is actually a compendium. Factors that precluded Java from solving the cross-platform problem and having everyone think in terms of web browsers (which is another dead-end, IMHO) are:

1) No standard JVM – ODMs and Operators are the culprits here. Operators provide a specification to the device manufacturers who price the device based on the specification. Even today, there is no standard JVM (which is why Google wrote it\’s own, BTW).

2) Java is pretty bloated for a mobile device and given #1, makes it virtually impossible to have any breadth of coverage across device families. The exception here is for operators that use Qualcomm\’s BREW which has it\’s own high-performance JVM that *is* standard across all BREW platforms.

3) The early J2ME specs were laughably inadequate and led to a complete fragmentation of the market. Sun repeatedly dropped the ball on driving \”standardization efforts\”, apparently hoping the by some miracle all of the participants would put aside their divergent agendas, hold hands and sing Kum-Ba-Yah (which didn\’t happen).

4) The length of time it took to get anything through the famed Java Community Process was usually 2-3 years followed by a 2-3 cycle to first implementation. Apparently in the standards group think of the 1990s/early 2000s nobody realized that by the time 5-6 years has passed nobody really gives a damn about the watered down feature.

5) Java went down the path of complexity for its own sake, rather than searching for elegant simplicity. Too many toolkit choices, Sun changing its direction too frequently, and more tack-on libraries with each version of Java were just nails in its coffin.

6) XML parsing is still hideously slow on a mobile device compared to a desktop or server, yet that is how most things are shipped around.

7) All of the \”open\” mobile operating systems, e.g. Symbian, and all of the \”closed\” RTOS systems have their own libraries that are required to write applications. Unless you\’re really skilled at isolating platform-specific issues, you can\’t make write-once, run anywhere happen. It certainly was *never* an option in the mobility sector.

There are a number of other horror stories as to why Java was a complete failure in the mobile device end of things, but I\’m content to stop at seven. It gets pretty depressing in a really short time when you realize that the industry has been struggling with this issue for well over a decade.

Reply
fableson

Thanks for the lengthy contribution – lots of good stuff in here. Of note in the new general of HTML/CSS & Javascript is the apparent downplaying of xml. JSON seems to be the new favored packaging tool.

Reply
jillemash

These HTML/javascript solutions are interesting indeed!
But they still need a VM for javascript, and I wonder what are the limitations to this kind of approach, compared to languages such as Objective-C/C/Java?
I\’d rather like a solution where you keep the same language and standard libraries for all platform, as it should be the case with Java.
That\’s the approach of iSpectrum (http://www.flexycore.com/), which gives the opportunity to code native iPhone apps in Java (1.5) without JVM (since it is not available on the iPhone).

Reply

Thank you, I have just been searching for info about this topic for a while and yours is the greatest I have found out till now. However, what concerning the conclusion? Are you sure about the source?

Reply

Wonderful goods from you, man. I’ve understand your stuff previous to and you are just extremely great. I really like what you’ve acquired here, certainly like what you are stating and the way in which you say it. You make it enjoyable and you still take care of to keep it wise. I cant wait to read much more from you. This is really a great website.

Reply

I’m not sure why but this weblog is loading extremely slow for me. Is anyone else having this issue or is it a problem on my end? I’ll check back later and see if the problem still exists.

Reply

Where are some good areas to obtain good free of charge blogger themes?

Reply

Hiya, I am really glad I’ve found this info. Nowadays bloggers publish just about gossip and web stuff and this is really irritating. A good web site with interesting content, that’s what I need. Thank you for making this website, and I’ll be visiting again. Do you do newsletters by email?

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>