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.
ItemCommandListener A listener type for receiving notification of commands that have been invoked on Item objects.
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 Displayable.
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.
CustomItem A CustomItem is customizable by subclassing to introduce new visual and interactive elements into Forms.
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, choice groups, and custom items.
Gauge Implements a graphical display, such as a bar graph, of an integer value.
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.
List A Screen containing list of choices.
Screen The common superclass of all high-level user interface classes.
Spacer A blank, non-interactive item that has a settable minimum size.
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.
     






    Copyright 1999-2010 Research In Motion Limited. 295 Phillip Street, Waterloo, Ontario, Canada, N2L 3W8. All Rights Reserved.
    Copyright 1993-2003 Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, California, 94303, U.S.A. All Rights Reserved.
    Copyright 2002-2003 Nokia Corporation All Rights Reserved.
    Java is a trademark of Sun Microsystems, Inc.