The high-level UI components' main characteristics are a consistent
API and leaving the actual UI layout and appearance to be implemented
by the device environment itself. Developers can write their code against
a single set of classes and objects and trust they will appear consistently in
all devices implementing that set. This approach ensures that high-level
UI components are portable across devices, appearing on the screen in a
manner that is consistent with the device's form factor, screen size and
input methods. The downside is that little control is left in the developers'
hands, and some important things, such as fonts, colors and component
positioning, can only be hinted at by the developer - the implementation
is free to follow those hints or not.
The low-level set of UI components consists of the Canvas class, the
GameCanvas subclass and the associated Graphics class. They provide
fine-grained, pixel-by-pixel control of layout, colors, component place-
ment, etc. The downside of using the low-level set is that the developer
must implement basic UI controls (dialogs, text input fields, forms), since
the Canvas is simply a blank canvas which can be drawn upon. The
CustomItem class of the javax.microedition.lcdui package can
be thought of as belonging to the low-level UI set, as it provides only
basic drawing functionalities, allowing developers to specify layout and
positioning of controls very precisely. However, as custom items are only
used within Form s they are discussed in Section 2.3.2.
The javax.microedition.lcdui package implements an event
model that runs across both the high- and low-level APIs. It handles
such things as user interaction and calls to redraw the display. The
implementation is notified of such an event and responds by making a
corresponding call back to the MIDlet. There are four types of UI event:
events that represent abstract commands that are part of the high-level
API; the Back, Select, Exit, Cancel commands seen in Symbian OS
devices generally fit this category
low-level events that represent single key presses or releases or pointer
calls to the paint() method of the Canvas class
calls to an object's run() method.
Callbacks are serialized and never occur in parallel. More specifically,
a new callback never starts while another is running; this is true even
when there is a series of events to be processed. In this case, the callbacks
are processed as soon as possible after the last UI callback has returned.
The implementation also guarantees that a call to run() , requested by