|PREV PACKAGE NEXT PACKAGE||FRAMES NO FRAMES|
|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
|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
|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
|AlertType||The AlertType provides an indication of the nature of alerts.|
|ChoiceGroup|| A ChoiceGroup is a group of selectable elements intended to be
placed within a
|CustomItem||A CustomItem is customizable by subclassing to introduce new visual and
interactive elements into
|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.|
|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
|Item||A superclass for components that can be added to a
|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
|Ticker||Implements a "ticker-tape," a piece of text that runs continuously across the display.|
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.
The application can switch the screens by calling
It is recommended that the screens are simple and contain as few UI components as reasonable.
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:
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 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.
The screens implementing the high-level API are the subclasses of
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
Graphicsimplement 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.
|PREV PACKAGE NEXT PACKAGE||FRAMES NO FRAMES|
Copyright 1999-2011 Research In Motion Limited. 295 Phillip Street, Waterloo, Ontario, Canada, N2L 3W8. All Rights Reserved.
Java is a trademark of Oracle America Inc. in the US and other countries.