Take the High Road when Creating MIDP User Interfaces

ne of the biggest challenges of writing software for mobile devices is creating user interfaces that work across a number of devices. As an application is deployed from device to device, developers face challenges due to changing environment parameters and device specifications. Screen sizes and pixel resolutions vary. Some devices are monochrome, while others support color. Some devices have two softkeys (keys on the device keypad that map to application commands) for user input, others have three—or perhaps one softkey and a scroll wheel to move through a list of options.

MIDP strives to solve these problems by providing a framework and a collection of user interface controls. These user interface APIs are found in the javax.microedition.lcdui package.

What You Need: Wireless Toolkit 2.1. Available at: http://java.sun.com/products/j2mewtoolkit/download-2_1.html.

Mobile Devices Are Not Desktop Computers
The MIDP user interface specifications differ greatly from what is found in the AWT or Swing APIs of J2SE. The primary reason for this is that mobile devices have different constraints, and therefore users interact with mobile devices differently than with desktop computers. For example, a cell phone does not have a mouse, or similar pointing device to guide user interactions. Most likely, a user will be limited to a fairly small screen, a 10-digit input keypad, and a few other keys to aid in selecting items from a list or invoking some type of command.

Furthermore, most MIDP-class devices do not support running multiple applications simultaneously, or even the ability to have multiple application windows open at the same time. For this reason, the MIDP user interface API diverges from standard Java in order to better support more limited devices.

High-Level and Low-Level APIs
The MIDP user interface specification divides the javax.microedition.lcdui APIs into two categories: high-level and low-level. The high-level APIs are where the pre-built components live. In here you will find classes such as List, Form, and TextField, among others.

These components are often your best bet for porting the user interface portion of your application between devices without modification. This is because each device implementation is responsible for mapping the behavior of these components as needed for the device. In some cases, the left and right softkeys may be reversed between devices, or some lists may have different List line wrapping logic. This allows MIDP applications to behave like other applications running on the same device and adhere to the same set of user interface guidelines defined by the device manufacturer. In short, the MIDP high-level user interface APIs are designed to provide a consistent interface for applications while allowing some malleability between platforms.

The low-level APIs in MIDP make no such promise as far as portability is concerned. The low-level APIs provide a rich set of fine-grained user interface control. This is where classes such as Canvas live. Using a Canvas, developers can create just about anything they wish. The downside is that developers are also responsible for handling the portability issues between devices. Seemingly simple things become issues, such as the display writing off the edge of the screen, or only using an upper left portion screen and leaving the lower right empty. It is likely that a low-level user interface will also need to handle different key mappings to perform the same tasks between devices. For example, on device A an application might trap a key press event for key 35 to select an item from a list, where on device B the application may need to look for key 12.

Although MIDP does provide some help in managing low-level APIs between devices, the recommended practice is to use the high-level APIs whenever possible. In this month's article I will focus on the high-level APIs. Next month, I will circle back and talk more about the low-level APIs.