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


Automate Your J2ME Application Porting with Preprocessing : Page 3

Got porting nightmares? If you're considering automating the porting your J2ME applications, you may want to think about using a preprocessor. Find out why it's the only technique open-ended enough to handle porting to multiple device models.

What's Involved in Porting with a Preprocessor?
The basic principle is to keep only one version of your source code, which is then preprocessed to generate code adapted to each device model.

Here are some things to keep in mind:

  • You'll need a thorough knowledge of the specific behavior of each device model.
  • You'll need to know the Java features supported by each device model.
  • You'll need to know which operations are more or less covered by pre-processing (things like deployment).
  • Remember that pre-processing does not convert resources (things like images or sounds).
  • You need to completely automate your solution—a parameterized solution is not sufficient.
  • You'll need to invest in the development of an automated compilation and packaging process.

You'll need to use conversion tools to adapt resources like images and sounds to the capabilities of each device model. The images will have to be optimized; for instance, you'll need to remove optional information in the headers of .png images, group small images in big images, reduce the number of colors for each image, preload resources, etc.

You may have to create a series of Java devices with the same characteristics, features, and behaviour. Then, you can produce one application for this series, not for each device model. The features of this series will depend essentially on the features you want to use in your applications. The more optional features you use, the more fragmentation you'll be dealing with.

You'll need to update the application in order to take into account unexpected resources. For example, if the device supports big .jar files and has a high heap memory, you can store a background image for your app. Otherwise, the image will not be included in your .jar file and you will need to draw the image simply. In this case, the .jar size will decrease and the heap memory will be less consumed.

Remember, screen size is an important issue when it comes to mobile programming, so don't hesitate to use all the available techniques to reduce image size (like dynamic transformation of images or transformation before packaging).

Another good practice is to manage the interactions with the system. For example, during an incoming call, stop sounds and pause your midlet during the call.

A Concrete Example
Suppose you want to port the game MyGame on the following devices: MIDP 1, MIDP 2, MIDP 1 NokiaUI, and MIDP 1 Motorola.

Here's a step-by-step overview of the process:

  1. Download and install Ant and Antenna.
  2. Create a specific class for the sound. This class will include the specific code to play sounds for each specific device.
  3. Create a series of Antenna XML files for each device model (ie MIDP 1, MIDP 2, MIDP 1, NokiaUI, and MIDP 1 Motorola). These files will:
    • Preprocess the source files, retaining only the lines concerning the current device.
    • Build the project by compiling the source files and pre-verifing the classes.
    • Run the ported midlet in the emulator for testing.
Seems easy, right?

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