Published on ONJava.com (http://www.onjava.com/)
 See this if you're having trouble printing code examples

O'Reilly Book Excerpts: Learning Wireless Java

MIDP GUI Programming, Part 1

Related Reading

Wireless Java
Help for New J2ME Developers
By Qusay Mahmoud

by Qusay Mahmoud

This is the first in a series of articles from O'Reilly's Learning Wireless Java, by Qusay Mahmoud. This first section of Chapter 5 introduces us to MIDP GUI programming and considers whether to use the Abstract Window Toolkit (AWT).

User interface requirements for handheld devices are different from those for desktop computers. For example, the display size of handheld devices is smaller, and input devices do not always include pointing tools such as a mouse or pen input. For these reasons, you cannot follow the same user-interface programming guidelines for applications running on handheld devices that you can on desktop computers.

The CLDC itself does not define any GUI functionality. Instead, the official GUI classes for the J2ME are included in profiles such as the MIDP and are defined by the Java Community Process (JCP). You'll note that the GUI classes included in the MIDP are not based on the Abstract Window Toolkit (AWT). That seems like a major issue, which brings us to the following question.

Why Not Reuse the AWT?

After a great deal of consideration, the MIDP Expert Group decided not to subset the existing AWT and Project Swing classes for the following reasons:


Because of the issues outlined earlier, the MIDP contains its own abbreviated GUI, which is much different from AWT. The MIDP GUI consists of both high-level and low-level APIs, each with their own set of events. This chapter discusses and shows examples of using objects from both the high-level and low-level APIs. Handling events from APIs, however, is deferred to the next chapter.

The high-level API is designed for applications where portability between mobile information devices is important. To achieve portability, the API employs a high-level abstraction and gives you little control over its look and feel. For example, you cannot define the visual appearance (shape, color, or font) of the high-level components. Most interactions with the components are encapsulated by the implementation; the application will not be aware of them. Consequently, the underlying implementation does the necessary adaptation to the device's hardware and native user interface style. Classes that implement the high-level API all inherit the javax.microedition.lcdui.Screen class.

The low-level API provides little abstraction. It is designed for applications that need precise placement and control of graphic elements, as well as access to low-level input events. This API gives the application full control over what is being drawn on the display. The javax.microedition.lcdui.Canvas and javax.microedition.lcdui.Graphics classes implement the low-level API. However, we should point out that MIDlets that access the low-level API are not guaranteed to be portable, because this API provides mechanisms to access details that are specific to a particular device.

The MIDP GUI Model

Here's how the MIDP GUI model works, in a nutshell. In order to show something on a MIDP device, you'll need to obtain the device's display, which is represented by the javax.microedition.lcdui.Display class. The Display class is the one and only display manager that is instantiated for each active MIDlet and provides methods to retrieve information about the device's display capabilities.

Obtaining the device's display is easy. However, this object by itself isn't very interesting. Instead, the more interesting abstraction is the screen, which encapsulates and organizes graphics objects and coordinates user input through the device. Screens are represented by the javax.microedition.lcdui.Screen object and are shown by the Display object by calling its setCurrent( ) method. There can be several screens in an application, but only one screen at a time can be visible (or current) in a display, and the user can traverse only through the items on that screen. Figure 1 shows the one-to-many relationship between the display and its screens.

Figure 1. Relationship between display and screens.

There are three types of screens in the MIDP GUI:

The lcdui Package

All MIDP GUI classes are contained in the javax.microedition.lcdui package. This package contains three interfaces and twenty-one classes, as shown in Table 1 and Table 2.

Table 5-1: lcdui interfaces




Defines an API for a user interface component that implements a selection from a predefined number of choices


Used by applications that need to receive high-level events from implementations


Used by applications that need to receive events that indicate changes in the internal state of the interactive items

Table 2: lcdui classes




A screen that shows data to the user and waits for a certain period of time before proceeding to the next screen.


A utility class that indicates the nature of the alert.


The base class for writing applications that need to handle low-level events and to issue graphics calls for drawing to the display.


A group of selectable elements intended to be placed within a Form.


A construct that encapsulates the semantic information of an action.


An editable component for presenting calendar data and time information that may be placed into a Form.


A utility that represents the manager of the display and input devices of the system.


An object that has the capability of being placed on the display.


A utility that represents font and font metrics.


A screen that contains an arbitrary mixture of items (images, text, text fields, or choice groups, for instance).


A utility that implements a bar graph display of a value intended for use in a form.


A utility that provides a simple two-dimensional geometric rendering capability.


A utility that holds graphical image data.


A utility that provides layout control when Image objects are added to a form or alert.


A superclass for all components that can be added to a Form or Alert.


A screen containing a list of choices.


The superclass of all high-level user interface classes.


An item that can contain a String.


A screen that allows the user to enter and edit text.


An editable text component that can be placed into a Form.


A ticker-type piece of text that runs continuously across the display. It can be attached to all screen types except Canvas.

The class diagram in Figure 4 shows the major classes and the relationships between them.

Figure 4. Class diagram of the major classes in the lcdui package.

Next week, we continue exploring the wireless Java MIDP GUI API by focusing on the High-Level MIDP APIs

View catalog information for Learning Wireless Java

Return to ONJava.com.

Copyright © 2009 O'Reilly Media, Inc.