The MIDP UI Component Model

The MIDP UI Component Model
The MIDP UI components are defined in the javax.microedition.lcdui package. This
package name will probably change in a future release because its name is too closely tied to a
particular type of physical display device. The MIDP UI components comprise the majority of
classes in this package. Understanding the organization of these UI components is essential to
building MIDP applications.
41
Listing 3.1 offers the first demonstration of the use of some of these components. The last two
lines of the startApp() method highlight the crux of the MIDP UI programming model and
demonstrate how the primary UI component classes interact:
display = Display.getDisplay(this);
display.setCurrent(form);
The first of the two lines just shown obtains a reference to a Display object. The Display
object is a Java object that represents the physical display of the device's screen. The next line says,
"Make this form the currently displayed entity."
A form is one kind of displayable component that can have a visual representation. A displayable
component in MIDP is a top-level UI component. Top-level components can be independently
displayed by a MIDlet. That is, they don't need to be contained inside any other component—in
fact, they can't be. A MIDP application can display only one top-level component at any given
time.
For AWT and Swing programmers, a MIDP top-level component is equivalent to a
java.awt.Frame or java.awt.Window in the Swing and AWT toolkits. The MIDP
implementation manages top-level components in the same way that the native window system
manages a Window in a J2SE platform implementation.
When the AMS launches a MIDlet, it does the following:
• It instantiates the Display class.
• It associates the Display instance with your MIDlet instance.
Your program never creates the Display object; the MIDP implementation does. Your MIDlet
creates only the UI components—instances of the concrete subclasses of Displayable or Item
that will be displayed on the screen throughout your MIDlet's lifetime. You tell the Display
object when to display your displayable components by calling the Display.setCurrent()
method.
Three primary objects interact here: your MIDlet instance, the Display instance created by the
AMS, and the Displayable component that you want to appear on the screen. Figure 3.6 shows
a UML diagram of the relationship between these objects.
Figure 3.6. MIDP implementations create only one Display object per MIDlet.
Your MIDlet is an instance of your main class that extends the MIDlet class. It can
create many Displayable objects, however.
42
The important concepts are the following:
• A Display object manages the physical display.
• A Display can display Displayable objects.
• You must obtain a reference to the Display object associated with your MIDlet by the
MIDP implementation.
• Only one Displayable object can be displayed at any given time.
An inheritance diagram is a wonderful tool to help one organize one's understanding of a
programming model and the relationships between the classes. Figure 3.7 shows an inheritance
diagram of all the classes in the javax.microedition.lcdui package.
Figure 3.7. The inheritance diagram of the MIDP UI components shows the
relationships between a MIDlet, its associated Display object, and its
Displayable objects. Unless otherwise qualified, all classes belong to the
javax.microedition.lcdui package.
43
In particular, notice the sibling relationship between the Display and Displayable types; their
purposes are different, hence they share no inheritance relationship. Also notice that a Form,
which our "Hello World" program creates, is a kind of Displayable called a Screen.
Conceptually, this organization supports the notion that a Form can take on the role of a top-level
screen.
Screen is also an abstract class. It encapsulates the nature of all types of top-level screen objects
in the MIDP. A Form is the particular concrete subclass of Screen used by the HelloWorld
MIDlet.
The HelloWorld MIDlet adds a String to its Form. This capability to aggregate objects makes
the Form class a kind of container. Although containers are a mainstay of the AWT and Swing
programming models, MIDP doesn't really have such a concept. The Form class is the only MIDP
type that is able to contain anything else.
Forms can contain only three types of objects: Strings, Images, and Items. A Form can't
contain another Displayable of any kind, not even a Screen or another Form. The inheritance
hierarchy of Figure 3.7 verifies this. This means that forms can't be nested. This model greatly
simplifies the structure of MIDP applications compared to AWT or Swing GUIs. To support
nesting would mean that the implementation would have to support the abstraction of visual
representation of the runtime nesting hierarchy to the user. This capability has been intentionally
omitted from MIDP because the resources required to support the related abstractions are too
costly for mobile devices.
Notice in Figure 3.7 that the Item and Image classes are not under the Displayable hierarchy,
and therefore are not displayable objects. Items, Images, and Strings can be added to forms
using the methods from the Form class shown in Table 3.3.
Table 3.3. Form Class Methods for Adding Items to a Form Object
Form Class Method Name Description
public int append(Item item) Appends an Item object to this form
public int append(String string) Appends a String object to this form
public int append(Image image) Appends an Image object to this form
44
The Form class implements the abstractions necessary to display String, Image, and Item
objects. It is also responsible for implementing a policy for organizing the objects that have been
added to it. In other words, the Form implementation defines a layout policy.
Nevertheless, MIDP has no concept of layout managers that can be manipulated by the
programmer as in AWT or Swing. The MIDP specification makes recommendations that Form
implementations should follow for doing layout, but it sets no required rules. Implementations will
vary in the way they carry out form layout.
The Item hierarchy defines visual components. You should, however, distinguish between those
components that have a visual representation and displayable components, which are top-level
components. The concrete subclasses of Item can be displayed. However, they cannot be
displayed independently like top-level Screen components. Moreover, they can only be
displayed with the help of a Form object and no other type of Screen.