- The Application Execution Lifecycle
- The MIDlet State Model
- The MIDP UI Component Model
- System Properties
- Application Properties
- Chapter Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
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.
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.
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 |
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.