The Bad

Now we’ll move onto “The Bad”. Java ME does have some problems and usually these have an impact when developing applications for the public that should run on “all” Java ME mobile phones - for example, games with some kind of network playability.

In situations when the application is for a specific mobile phone model (for example, an enterprise application to be used in-house) the problems described are not an issue. This is because the application will generally run on a known set of devices, and can be appropriately tested.

API Versions

Coding an application is a problem when you don’t know what the Java ME implementation on the phone will provide. If your application uses optional Java ME implementation classes that are not on the device at run time, it will either not install or not run.

It’s a common trap for a developer to merrily code away on their development platform, and for everything to work correctly using their phone emulator (which is probably configured to use the most advanced Java ME specifications available). Then, when it comes time to install the application onto a real phone, it doesn’t work.

Why? Well, there could be various reasons. For example, the Java ME implementation on the real phone mightn’t provide the 3D graphics API that the application uses. Or maybe the implementation doesn’t provide HTTPS- or Bluetooth-related classes. Or even worse, the phone’s Java ME implementation doesn’t provide the latest core system APIs that the application has been coded to.

This is because the core, mandatory Java ME APIs essentially come in 2 flavors – MIDP 1.0 and MIDP 2.0. MIDP 1.0 is an earlier API which is found on older mobile phones. MIDP 2.0 encompasses all MIDP 1.0 functions, provides improvements in the areas of GUI and network interfaces, and is generally found on newer mobile phones. MIDP 1.0 API functions will operate on MIDP 2.0-enabled devices, but not vice-versa.

The problem is that when developing applications for public use, it seems that the general philosophy is “write code using the latest specs (MIDP 2.0), and then try to retrofit it to MIDP 1.0 later, so that the application will run on as many devices as possible”. This is a flawed philosophy, resulting in a great deal of retrofitting activities for little benefit.

My recommendation is to simply code your application using MIDP 2.0 APIs. While this seems like a large potential audience for your software is being cut out, there are various justifications for not coding to the older specification:

• MIDP 2.0 has been around for a few years and is commonly available
• People with old (MIDP 1.0) phones are not likely to be interested in downloading applications anyway.
• It’s much less effort to develop to MIDP 2.0 and not retrofit.
• Older phones have problems connecting to the internet anyway.

Device Network Configuration

Setting up your phone to connect to the internet is difficult. Although internet phone configuration is beyond the scope of the Java ME specification, it is an issue that has a direct impact on whether a user can download and run your application.

The most convenient mechanism for delivering applications is GPRS. However, many phones do not have GPRS configured or enabled by default. Additionally, if your application uses the internet for sending/receiving data, then this will not work either if GPRS is not working on the device.

Configuring GPRS on mobile phones is complicated and tedious. Consequently, it may be beyond the capabilities or interest of the average mobile phone user. Many phone carriers provide the ability to enable and send GPRS configuration information to the mobile phone over the air (OTA). This is convenient, but does require action from the phone owner to activate (for example, they may have to call the carrier help desk, or perhaps visit the carrier web site).

Anecdotal evidence suggests that it is a fairly common problem in Australia for devices to not be GPRS-enabled, but not so overseas, where mobile phones are always delivered with GPRS fully enabled and functioning.

Often this problem becomes apparent during development when you may want to demo an application. If the user doesn’t have GPRS enabled on their mobile phone, then it’s best to demo on your own phone - it’s just not worth the pain of trying to get them set up on the spot.

Device Phone Number Awareness

As far as I can tell, there seems to be no way for a Java ME application to reliably and consistently determine the phone number of the mobile phone that it’s operating on at runtime. Consequently, identifying a particular user to the application is difficult. Instead of just using something concrete - like the phone number of the device - additional coding is necessary at both the application and deployment level to provide identification features.

API Fragmentation

Many Java ME specifications are completely optional; a vendor can choose whether or not to implement them on a phone. If your application requires an optional API but is installed on a phone without this capability, then the installation will either not install, or worse, install and not run (depending upon the device).

So if your whiz-bang calculator application happens to have a splash-screen which uses the optional 3D package, then don’t expect everybody to be able to run it, even if it uses just the core API for everything else it does.

A workaround is to deliver packages based on functionality, but this can get very complicated, very fast. For example, consider an application which delivers some base functionality, but also uses the optional 3D and Bluetooth APIs. Different physical packages could be built which exclude particular functionality, meaning that you could end up with the following packages:

• Base Functionality
• Base Functionality + Bluetooth
• Base Functionality + 3D
• Base Functionality + 3D + Bluetooth

So suddenly your application can come in at least 4 different flavors, or even more if your application uses other optional APIs. And you have to manage and maintain them appropriately.

Even worse, the end user has to try to figure out which of these applications are suitable for installation on their mobile phone. Installing the “wrong” package will result in an application that doesn’t work. And to add insult to injury, the user may have paid for the network traffic of downloading the wrong package!

My recommendation here is to make life easier by coding the application to just deliver base functionality. If the optional API’s are absolutely required, then include them, but make it clear to users that specific functionality is required of their device and that your application may not run on all mobile phones.