Testing It Out
You should test your applications on as many device emulators as possible. Skins and emulators for most devices are available at little cost or even free. It really pays to test the UI against all possible target devices, following a consistent test path through the UI first, and then trying out unplanned choices. Some devices provide testing facilities. For example, the Palm OS emulator has a great testing facility called Gremlins, which will poke and prod your interface in random ways and report any errors in a log file. Such tools can help you identify problems.
As you can see, it's not a trivial matter to slap a UI on your application. UI design can make or break your applications. The more devices your application runs on, the more vulnerable it is to UI problems. But you can minimize the potential problems by using the MIDP High-Level UI API and its facilities for creating standard interfaces that render appropriately for disparate devices. Click here to take a look at some general guidelines for minimizing UI problems.
Be sure to separate business rules from the presentation logic so that you can replace UI implementations at compile time. For example, the PDA profile under J2ME provides more facilities for accessing the much more advanced features of higher-end devices such as Palm Pilots and Pocket PCs.
If you have control over application provisioning, you can make different application versions available based on the requesting device's signature. For example, if your server can tell that an LG5350 is asking for your application, you can serve it a color version. And you can do this automatically without the user having to specify what device they have.
MIDP 2.0 promises to add user interface facilities for specifying spacing, using screen layers and many other exciting and useful additions to our UI toolkit. Take a look at the reference implementation on the Sun J2ME section and check out the examples provided.