A Brief Introduction to Mobile Development

This document is a brief practical overview of developing Java applications on mobile devices. It is not a [wiki:GettingStarted good resource for getting or configuring the tools] necessary for !JavaRosa, but will help the reader understand what components are involved in the !JavaRosa structure, why they were chosen, and what is necessary for developing a solid J2ME application.

Basics (Acronyms)

On robust platforms, the Java virtual machine contains all of the low-level libraries that one needs on virtually any computer, and other libraries can always be included as JAR archives to fill in missing functionality. In the J2ME world this isn't really the case. Due to the speed of technological obsolescence, space, and API limitations there exist a number of different baselines for development. There are actually a number of 'foundational' packages that may or may not be included in your JVM. Worse yet, if these packages aren't part of your JVM for a particular device, you will be unable to include that functionality via some modular system like JAR's. The foundational packages that may or may not be in your JVM are as follows

Mobile Information Device Profile (MIDP)

The MIDP libraries essentially contain User Interface and front end elements for Java Applications. It is the actual Application Environment that will be used to run software on the device.

MIDP comes in the following flavors:

• MIDP 1.0: Is included on most older Java platforms and has very weak UI element support. MIDP 1.0 can to some degree be supplemented by J2ME Polish
• MIDP 2.0: The current standard for J2ME development. Fairly common on modern devices.

Connected Limited Device Configuration (CLDC)

The CLDC libraries essentially contain the back end libraries that one requires for Java development. It is essentially the Java Engine on your device.

CLDC comes in the following flavors

• CLDC 1.0: Standard back end. Still common on many devices.
• CLDC 1.1: More developed back end support, including floating point support for devices with FP processors. CLDC 1.1 is less common than MIDP 2.0 on modern devices.
• CLDC 1.1.3: Cutting edge. On like, 3 phones ever.

Other J2ME Profiles

There are a '''ton''' of other J2ME profiles that your devices might have. Unfortunately, very very few devices are standardized on packages other than MIDP and CLDC, so developing for these packages might leave you very limited for platforms, and they will almost certainly be expensive.

JSR 75 (File Access and PIM Access)

A fair number of phones allow J2ME to access the file system of the device using this Java package. It should be noted that having '''any''' references to the classes in this package (!FileConnection, etc) will cause your MIDlet application to fail to run on platforms that do not have this package, even if the classes are never accessed.As such, you will need to have multiple releases if you want to have the same app run on both platforms with and without this package. Polish can help with this task.

JSR 46/219/129/217/62/216 (Personal Basis/Foundation/Personal Profiles)

These are more serious application environments than MIDP that include toolkits more similar to AWT with powerful event handling, etc. Unfortunately, these aren't really practical for any actual development, as you're not really likely to find a platform for them yet.

The Structure of Running Java Apps on Mobile Devices

Mobile Devices all need their own JVM to run Java applications. The vast majority of these will be simple non-floating-point implementations of CLDC and MIDP. An application for this platform comes in the form of a MIDlet, which is the basic class that needs to be implemented to run an application. Actually putting the MIDlet on the device varies by device, but generally will be simply packaged as a JAR. These JAR files often come with a JAD file that is used to describe the java archive file. Sometimes the JAR file will not run without the matching JAD file.

It is worth noting that it is not trivial to link just the right libraries in one's development environment while writing code for a specific device. Great care should be taken while developing and compiling Jars, as failures that are thrown when a JAR is placed on an actual device are not particularly verbose.

J2ME Polish, What it Is, and Why you should be Using it

Trying to develop a single application that runs on a handful of different phones is distinctly non-trivial. One of the best build tools that has been made to assist in this effort is J2ME Polish. Polish has a lot of features and uses, and it can be confusing to figure out exactly what you use it for. We will try to clarify exactly what's going on with it.

Essentially there are two elements of J2ME Polish. There are Libraries that are used to improve the look and feel of applications, and then there is a Build System. We'll discuss the later first, as it solves more fundamental problems of development.

The Polish Build System

The Polish Build System is an Ant based set of build tasks that are extremely useful for going from Code to actual MIDlets with the least amount of pain possible. Polish essentially takes care of two major tasks. The first is properly identifying what libraries code should be linked to, the second is identifying what actual code should be used out of the set of code that exists. A Polish Build comprises 3 steps

• Preprocessing
• Compiling
• Obfuscating

Preprocessing

Polish introduces into the code the idea of "directives". These are essentially variables that are defined at build-time that are known about building for a specific platform. They are most often definitions about what is available on the target platform. These can either be defined by Polish automatically when a platform is specified (For instance, a Phone with a touchscreen has the polish.hasPointerEvents directive defined), or can be manually defined as variables in the Ant buildfile in order to have more manual control over the code.

At build time, Polish uses these directives to preprocess code to remove code that will not be compiled due to these directives. It was mentioned before that JAR files including references to the !FileConnection class will fail on phones that do not have the optional file connection package. Assuming that the directive polish.fileconnections is defined to be true for phones that have this API (sometimes these directives aren't identical, and multiple ones must be included), we might manually introduce the following code to only include a !FileConnection call for those phones.

//#if polish.fileconnections
FileConnection c = new FileConnection();
this.userdata = c.someMethod();
...
//#endif

When Polish is told to target phones that don't have the File Connection Package, the above code will simply be commented out before it is compiled and linked.

Obfuscation

Obfuscation is the process of obscuring the readability of code in order to prevent it from being reverse engineered. Regardless of the necessity of this for your project, Polish's obfuscator both identifies unused code and libraries and removes them from the final JAR file that is compiled, and compresses the size of existing code in the JAR. This has the benefit that your JAR files will be much smaller than otherwise. Unfortunately, it can also have the affect that a minor change in your code can cause obfuscation to now include a whole file that has some linking problem that did not exist before in the JAR because the file was excluded, so be aware that it can introduce more major changes to the JAR when minor changes are made to the code