Tips for Writing MIDP Applications, Part 1

Several months ago, I wrote an article on creating bluepulse widgets. At the time, I put another article -– this one -– on my mental to-do list. There it languished, being pushed ever further down until I read this article from little springs design. It’s tongue-and-cheek, and contains some great tips for what not to do when writing a mobile application.

I wholeheartedly agree with the intent of each of the ten guidelines they mention, but I tend to view articles from the design perspective with a degree of trepidation. Full disclosure: yes, I’ve killed a back button or two in my day, and I continue to do so. The intent is always honorable, but execution of some well-meaning guidelines can get hairy. Nowhere is this more true than in the mobile space, where, despite standards, developers face a near-vertical incline when deploying to many handsets.

From a development perspective, here are several good practices for building mobile applications. This is not intended to be an exhaustive list. I should also point out that these guidelines apply specifically to the development of MIDP applications.

Pay Attention to User Goals

Mobile device users have unique usage goals that should be observed. Most are looking for information/content, communicating with others, or seeking entertainment. They are generally using their devices for short periods of time to perform specific tasks. So keep things simple, focused, task-based, and don’t expect users to learn how to use your
application.

A tip for keeping things focused is to try to boil your application’s purpose down into a single sentence. Or two or three. Just keep it short. Then focus your UI on the tasks required to fulfill that purpose. For example, you might be developing a dieting application that allows users to enter eating and exercise goals, view meal plans and get recipes, chat with other dieters, and so on. But your one-sentence purpose might be to “enable users to track their weight.” Some obvious tasks that could be derived from this purpose are “enter weight” and “view progress.”

Create Builds for Device Groups

Creating attractive screens for mobile devices is particularly challenging partially due to the disparity among all of the devices using an application. Coming from the PC world, the magnitude of these differences can be difficult to grasp.

There are several valid strategies for creating applications for these devices. Creating an all-purpose build is suitable if you’re using the standard MIDP controls, but if you’re creating your own canvases and custom items, creating separate builds for device groups is more feasible. For example, I usually create three primary layouts: small, for screens up to 170×220; medium, for screens from 170×200 to 220×300; and large for screens larger than 220×300. It’s not perfect, but it enables support for the normal distribution of mobile devices.

This concept can be applied to form other groupings, as well, e.g. permitted jar size, available runtime memory, color bit depth.

Use a Build Tool

Keeping track of all of those builds is not only difficult, but more importantly, prone to error. Using a build tool like Ant, Antenna, or the Java ME-specific J2ME Polish can make your life much easier.

Build for Interruptions

Distractions are more common when using mobile devices, so prepare for them. Every screen should provide some kind of context so that the user knows where he is, and what he should be doing on that screen.

Your application might be suspended or abruptly exited at any time. Make sure you handle pauses and resumes, suspended operations, freeing resources, or restarting operations, as appropriate. Make sure you release all resources and close all connections on exit. Some ugly errors can occur if connections aren’t properly closed, and you attempt to use them in a later session.

Test on Multiple Emulators

If you’re building for multiple handsets, test on multiple emulators. This can be a real pain, because each vendor toolkit you install on your PC seems to slow it down further, and increase those pesky Dr. Watson errors. No comments from Mac users, please. I use a box specifically for development, where I don’t mind installing emulators,
toolkits, and software willy-nilly.

Test on Multiple Real Devices

Emulators are nowhere close to perfect. You’ve got to test on real devices. It’s very common for errors to occur on real devices that don’t occur on emulators. More exasperating is a bug on an emulator that doesn’t occur on a real device.

Additionally, while emulators can help point out bugs in your code, they commonly don’t alert you to performance considerations on a real device. Similar to testing on multiple emulators, you should test your application on several real devices.

Find a cellular carrier that is understanding of using unlocked phones with your service. Most don’t care, and some will provide limited support for handsets not purchased from them, but you’re largely on your own for things like WAP and Internet settings. I use Cingular, whose network is compatible with a large number of GSM phones, and who has a relatively extensive device database. While I use a Sony-Ericsson s710a for daily use, I use a Nokia 7370, Nokia 6670, Sony-Ericsson Z520, Motorola V360, Siemens SK65, and a Samsung SGH-D807 for testing. None were purchased from Cingular, and all work flawlessly.

Stay tuned for part two of this article.

Tags: J2ME, Java ME, mobile software, mobile development, MIDP, Java