Use is subject to License Terms. Your use of this web site or any of its content or software indicates your agreement to be bound by these License Terms.

Copyright © 2006 Sun Microsystems, Inc. All rights reserved.

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	Choice defines an API for a user interface components implementing selection from predefined number of choices.
CommandListener	This interface is used by applications which need to receive high-level events from the implementation.
ItemStateListener	This interface is used by applications which need to receive events that indicate changes in the internal state of the interactive items within a Form screen.

Class Summary

Alert	An alert is a screen that shows data to the user and waits for a certain period of time before proceeding to the next screen.
AlertType	The AlertType provides an indication of the nature of alerts.
Canvas	The Canvas class is a base class for writing applications that need to handle low-level events and to issue graphics calls for drawing to the display.
ChoiceGroup	A ChoiceGroup is a group of selectable elements intended to be placed within a Form.
Command	The Command class is a construct that encapsulates the semantic information of an action.
DateField	A DateField is an editable component for presenting date and time (calendar) information that may be placed into a Form.
Display	Display represents the manager of the display and input devices of the system.
Displayable	An object that has the capability of being placed on the display.
Font	The Font class represents fonts and font metrics.
Form	A Form is a Screen that contains an arbitrary mixture of items: images, read-only text fields, editable text fields, editable date fields, gauges, and choice groups.
Gauge	The Gauge class implements a bar graph display of a value intended for use in a form.
Graphics	Provides simple 2D geometric rendering capability.
Image	The Image class is used to hold graphical image data.
ImageItem	A class that provides layout control when Image objects are added to a Form or to an Alert.
Item	A superclass for components that can be added to a Form and Alert.
List	The List class is a Screen containing list of choices.
Screen	The common superclass of all high-level user interface classes.
StringItem	An item that can contain a string.
TextBox	The TextBox class is a Screen that allows the user to enter and edit text.
TextField	A TextField is an editable text component that may be placed into a Form.
Ticker	Implements a "ticker-tape," a piece of text that runs continuously across the display.

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.