Package javax.microedition.lcdui

The UI API provides a set of features for implementation of user interfaces for MIDP applications.

See:
Description

Interface Summary

Choice	This interface allows things to be chosen
CommandListener	This is used to inform an application of a command
ItemStateListener	Class used when an item changes

Class Summary

Alert	An alert class that shows a screen for a period of time
AlertType	Alert types are different types of alerts
Canvas	The canvas class is the base class for drawing applications
ChoiceGroup	A choice group provides a mechanism to select items
Command	The command class is used to setup soft buttons
DateField	A date field class allows dates to be displayed and entered
Display	This is the manager for displays in the system.
Displayable	This is the displayable class.
Font	This stores information about a font
Form	A form contains items for displaying on a screen
Gauge	A gauge allows a range of values to be entered
Graphics	This class does all the drawing
Image	This holds an image
ImageItem	Image items allow images to be used in a form
Item	Items are used to display things in forms
List	The list is a screen that contains a list of choices.
Screen	The screen is the superclass of all high level objects
StringItem	String items store strings in a form
TextBox	This provides the implementation for text fields and text boxes
TextField	The text field implementation that allows text to be editied in a form
Ticker	A ticker tape

Package javax.microedition.lcdui Description

The UI API provides a set of features for implementation of user interfaces for MIDP applications.

For more information see Chapter 9 of MIDP specification.

Screen-based approach

The central abstraction of the MIDP's UI is that of a screen. A screen is an object that encapsulates device-specific graphics rendering user input. Only one screen may be visible at the time, and the user can only traverse through the items on that screen. The screen takes care of all events that occur as the user navigates in the screen, with only higher-level events being passed on to the application.

The application can switch the screens by calling Display.setCurrent(Displayable).

It is recommended that the screens are simple and contain as few UI components as reasonable.

Two-layer approach

The MIDP UI is logically composed of two APIs: the “high-level” API and the “low-level” API.

The high-level API is designed for business applications whose client parts run on MIDs. For these applications, portability across devices is important. In order to achieve this portability, the high-level API employs a high level of abstraction and provides very little control over look and feel. This abstraction is further manifested in the following three ways:

The actual drawing to the MID's display is performed by the implementation. Applications do not define the visual appearance (e.g. shape, color, font, etc.) of the components.

Navigation, scrolling, and other primitive interaction is encapsulated by the implementation, and the application is not aware of these interactions.

Applications can not access concrete input devices like specific individual keys.

In other words, when using the high-level API, it is assumed that the underlying implementation will do the necessary adaptation to device's hardware and native UI style.

The screens implementing the high-level API are the subclasses of Screen.

The low-level API, on the other hand, provides quite little abstraction. This API is designed for applications that need precise placement and control of graphic elements and access to low-level input events. Some applications also need to access special, device-specific features. A typical example of such an application would be a game. Using the low-level API, an application can:

Have full control of what is drawn on the display.

Listen for primitive events like key presses and releases.

Access concrete keys and other input devices

Classes Canvas and Graphics implement the low-level API.

Applications that program to the low-level API are not guaranteed to be portable, since the low-level API provides means to access details that are specific to a particular device. If the application does not use these features, the applications will portable and it is recommended that the applications stick to the platform-independent part of the low-level API when ever possible. This means that the applications should not directly assume any other keys than defined in class Canvas, and should not blindly trust on any specific screen size. Rather, the application game-event mechanism should be used instead of referring to concrete keys, and application should ask and adjust to the size of the display.