RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Start Your Engines: Mobile Application Development : Page 7

A fifth of the world's population will soon have a mobile device and access to the Internet. With that many potential users, is an explosion of mobile applications inevitable? If so, what technologies will lead the way in their development?

Platform and Application Provisioning
Getting the application platform and applications onto the devices can be problematic especially since the devices can literally be anywhere in the world.

Java ME's application provisioning strategy depends on the configuration. An Over-the-Air (OTA) Provisioning specification defines how applications can be obtained on devices that run Java ME's Connected Limited Device Configuration (CLDC). While the specification is in place, carrier and/or vendor support for the specification and how end-users can obtain their Java ME application is not always seamless (see the blog So, you want to deploy a J2ME app in the US?). There is no OTA specification for Connected Device Configuration (CDC) applications and therefore no consistent technology or strategy for getting these applications to their devices—particularly over the air.

As for the Java ME runtime environment, it is often factory installed by the vendor, especially on cell phones. In some cases, however, the runtime must be installed along with the application by developers or consumers, which adds to deployment frustrations.

The .NET Compact Framework is already installed with Windows Mobile OS, so getting the base application platform in this environment shouldn't be an issue. ActiveSync allows Windows Mobile OS devices to be updated quickly and easily via connection to a desktop. In addition, over-the-air provisioning is technically possible, but it requires the support of the carrier and/or vendor. In particular, they must provide a device management (DM) server. In its documentation on Windows Mobile OS, Microsoft notes that "Microsoft does not provide an OMA DM or an OMA Client Provisioning server. The OEM, Operator, or a third party must create their own server".

The effort to get an application to the point of delivery can be extensive with BREW. However, once ready, BREW's application deployment and provisioning plans are well thought out and where BREW excels, especially for application developers targeting devices in the hands of the general public. The operator manages the available BREW applications for download through the BREW Distribution System (BDS). This system allows handset users to select and download applications over the air and bill them accordingly. The operator and Qualcomm conveniently handle all the distribution and billing details. Of course, this comes at a cost. This document indicates that developers receive 80 percent of the application's wholesale price while Qualcomm and the operator take 20 percent. This over-the-air provisioning also allows the applications to be quickly updated or fixed. In fact, the handset manufacturers provide new features and fix bugs over-the-air also using BREW extensions.

Other Resident App Options
Again, this is not a complete list of resident application development technologies. The Open Handheld Alliance, whose members include Google, HTC, Intel, Motorola, Qualcomm, Samsung, LG, T-Mobile, and Nvidia, released Android in November of 2007. Android applications are written in Java with an Android Java SDK, but this Java is not Java ME or Java SE. Android applications are targeted to run on a custom virtual machine (Dalvik) and Linux OS. While there is considerable interest in Android, there are no major devices that run this application platform today. Apple, as mentioned, just released its SDK for the iPhone. This is certainly an application platform that could impact mobile development and attract the business community to think about the iPhone as a possible platform. Sun is also developing a JVM for the iPhone OS. Still there are other mobile development platforms that may not fit under a heading of "major" but might be worthy of exploration given your particular platform and application needs. Nokia has released a Python interpreter for some if its mobile phones. Lazarus provides a Pascal (Object Pascal) environment for select devices. Straight C/C++ applications can be written for Windows Mobile and other platforms. And regular Java (Java SE) is available on some mobile device platforms and James Gosling has hinted that this is ultimately where Java is heading in the mobile space.

The combinations and permutations of programming languages, development environments, and mobile device runtimes are extensive. There is bound to be something for everybody.

Tomorrow's Resident Application Choices
Will BREW survive? Will the Apple SDK drive more companies to explore the iPhone for business applications and thus increase its market share? Will Android ever find platforms to host it? Will this discussion of writing to a device and writing to an application platform always be an issue? While it appears that the number of choices for mobile development is increasing, some say it's a matter of time before we experience some contraction. Some, especially those centered on enterprise applications for business, say these and a host of other questions may not be relevant in the near future.

In 2004, Jack Gold, then a Vice President at Meta Group, made a bold prediction that "before long, the market will consist of only two camps: Microsoft and Java."

Today, Mr. Gold is President of J.Gold Associates, LLC, a research, analysis, and strategic consulting company. Via email, I asked Mr. Gold if he would like to update is 2004 comment in light of what almost seems like more options and alternatives for building mobile applications today. He sticks by his 2004 comments and indicates the enterprise challenges will be at the heart of that consolidation.

"We still expect the market to coalesce around the two major platforms: Microsoft's .NET framework and the Java environment (and its derivatives, but primarily J2ME). The vast majority of mobile apps deployed to smart devices today fall into one of these two environments. Yes, there are some thin client apps being deployed and this will expand, particularly as the browsers on the devices become more capable and support things like AJAX, Flash, Silverlight, etc. But enterprises still have the challenge of assuring anytime/anywhere computing for their workforce, and the wireless networks are not 100 percent reliable, and probably never will be (except in a controlled environment like an enterprise campus where radios/access points can be added as need). And if you look at the various platforms available for delivery, the standards become even more compelling. Blackberry and Symbian apps are primarily delivered to the devices via J2ME. Microsoft powered Smart Phone devices have apps that are primarily .NET powered. And Android, which is really an overlay on a Linux Kernel, will provide a platform for Java and AJAX deployment, as will the iPhone (Mac OS also has Unix at its core).
So while the devices expand, the delivery mechanisms, and especially development environments for enterprise class apps will remain centered on the standards that companies know today—Visual Studio and Eclipse primarily, with a few specialty app environments (e.g., Apple) for a few select devices. Enterprises will not be able to go out and learn a myriad of different app environments—it is too costly to create, maintain, and support different apps for different device types. There has to be a unifying thread, even though they need to potentially support different actual devices. So coalescence is required (unlike the consumer space where apps need to support dozens or hundreds of devices)."
Using history as an indicator, Mr. Gold might be on to something. In both hardware and software, there has typically been a period of proliferation of solutions before an eventual consolidation/standardization.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date