|PREV PACKAGE NEXT PACKAGE||FRAMES NO FRAMES|
|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
|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
|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
|Item||A superclass for components that can be added to a
|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
|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|