If you’re developing mobile content, the first thing you need to ask yourself is what road will you follow. A mobile project, more so than a web project, is about choices. The choice which phones you will support, which mobile OS’s and perhaps most importantly, which platform you will use to develop your content.
The Platform
Just like the browser wars, the mobile community has its own battle to fight. The world of mobile devices is littered with proprietary APIs and different solutions for packaging and deploying your application to the device. On one side you have Apple with its proprietary iPhone OS that almost exclusively offers applications through its App Store, while on the other side you have Nokia supporting Flash Lite applications and allowing you to package your content as a Web Runtime widget which will run on most S60 phones. (new generation Nokia phones as well as some others like Samsung and LG). Though far from a complete list (others include BlackBerry OS, Palm OS, Windows Mobile and Google’s emerging Android system), these two currently hold the biggest market share for mobile devices and chances are you will be developing for one of these platforms.
The Tools
Once you’ve decided on the platform, you will need to decide which tools to use. If you’re developing for the iPhone, you have only one real option, the iPhone SDK, which lets you develop iPhone applications using Objective C. Fortunately, this kit is short from perfect, with excellent ease of use and an incredible emulator which allows you to test your content without necessarily having to upload it to your device.
If you’re developing for the Series 60 or Series 40 phones, there is a huge selection of tools and programming languages available to you, ranging from the more low-level languages like JavaME and C++ to web technologies like Flash Lite and Web Runtime (which is basically an HTML page with Javascript and CSS). From here on in, I will mostly focus on these last two. On the point of IDEs, there’s an even bigger variety, depending on the programming language of your choosing. Here at These Days, we tend to use Eclipse with the Aptana Plugin and Adobe Device Central for our mobile projects.
The Clash: WRT vs. Flash Lite
So, as a multi-skilled mobile content developer, which of these technologies should you choose? Well, each certainly has its merits and although a good many of you might tend to rush in and pick the technology that you feel most comfortable with, it’s often better to look at the needs of your application or widget and then decide on which technology suits those needs best. Else you may find yourself drumming your head against the wall in agony later on. For example, one of the new features supported on high-end phones, most notably Nokia’s new N97, is the homescreen. The Nokia N97 homescreen is highly customizable and allows the user easy access to his favorite apps or widgets. This very interesting feature does come with a downside, namely that you’re bound to using Nokia’s Web Runtime and cannot deploy your content for instance, as a .sis or .jar application.
Since WRT widget are comprised of plain old HTML, CSS and Javascript they are often the most cost-effective solution for widgets that deliver customizable content to the user, like RSS readers, weather applications or applications that tie in to your website in some other way. (Facebook has an excellent example, pre-installed on the N97) It’s even possible to add some Flash Lite content, but be warned that you lose out on a lot of the power and possibilities of Flash Lite when it is embedded in a WRT widget, since you most likely will not be able to use any of the API’s used to interface with the device. (unless you build a communication layer between Flash Lite and Javascript)
This is one of the reasons that Flash Lite is much more suitable for small games and standalone applications where you don’t need to leverage the special features only available to WRT widgets, like the homescreen. But here also, keep in mind that Flash Lite nor the devices that run it are not anywhere near what we’ve become accustomed to, performance-wise. So if you’re going the Flash Lite way, expect Actionscript 2 (Flash Lite 3.x supports Flash Player 8 capabilities, all versions below support Flash Player 7) for at least another year (rumor is that by the end of this year, Adobe will present the beta to Flash Lite 4 and with it long-awaited support for AS3) and don’t overdo it with embedded bitmap images and tweens.
The Conclusion
The only advice I can give you is: make sure that you think long and hard on which technology suits your needs best. At this moment, I think WRT, due to its ease-of-use and extensive components library (WRTKit) is slightly more feasible than Flash Lite, and only time will tell if that delicate balance will tip in Adobe’s favor once more.
I’ll leave off with some excellent resources:
