July 21, 2011, 8:12 a.m.
posted by barateon
The following sections present more advanced topics related to the MIDP user interface libraries.
Typically, the current screen of the foreground MIDlet is visible on the display. However, under certain circumstances, the system may create a screen that temporarily obscures the current screen of the application. These screens are referred to as system screens. This may occur if the system needs to show a menu or if the system requires the user to edit text on a separate screen instead of a TextField inside a Form. Even though the system screen obscures the application's screen, from the viewpoint of the application the notion of the current screen does not change. In particular, while a system screen is visible, a call to the method getCurrent will still return the application's current screen, not the system screen. The value returned by the method isShown is false while the current Displayable is obscured by a system screen.
If the system screen obscures a Canvas, the hideNotify method of the Canvas is called. When the system screen is removed, restoring the Canvas, its showNotify method and then its paint method are called. If the system screen was used by the user to issue a command, the commandAction method is invoked automatically after the showNotify method is called.
2 Adaptation to Device-Specific User Interface Style
The lcdui API contains several methods to query the user interface properties of the target device.
The Display class provides methods to query the color capability of the client device. The methods isColor, numColors, and numAlphaLevels provide information about whether the device has a color or monochrome display, the number of colors (or gray levels), and the number of supported alpha-channel levels in off-screen images, respectively.
The system colors can be queried with a method:
The color specifiers are:
The getBorderStyle method is used to query which border style is used in the device for highlighted and non highlighted components. Similarly, using class Font, some of the device fonts, FONT_INPUT_TEXT and FONT_STATIC_TEXT, can be queried using the method:
Class Display also provides the methods getBestImageWidth and getBestImageHeight for querying the preferred sizes of images used in high-level components. The Displayable class provides the methods getWidth and getHeight to check the screen size provided for the application.
The methods for querying screen or component sizes and low-level input capabilities are provided in the classes Canvas and CustomItem. For the applicable methods of class CustomItem, refer to Section 10.8.1, "Interaction Modes." For the applicable methods of class Canvas, see Section 11.2.3, "Pointer Events."
3 Device-Provided Operations
In many high-level user interface classes such as Screens there are some additional operations that are visible only to the end user and not to the applications. This means that the user interface may present commands for which no listeners or event mechanisms are available in the lcdui API. When the user activates such device-provided operations, no application listeners are called.
The set of available operations depends on the user interface design of the specific device. For example, in the TextBox class, an operation that allows the user to change the mode for text input between alphabetic and numeric is needed in devices that have only an ITU-T keypad. Many devices with an ITU-T keypad have more complex predictive input systems, and these require additional operations in TextBox. Some of the operations are presented in the user interface in the same way as application-defined commands. End users need not understand which of the operations are provided by the application and which are provided by the system. Not all operations are available in every implementation. For example, a system that has a word-lookup-based text input scheme will generally provide additional operations within the TextBox class. A system that lacks such an input scheme will also lack the corresponding operations.
Some operations are available on all devices, but the way the operation is implemented may differ greatly from device to device. Examples of such operations are: the mechanism that is used to navigate between List elements and Form items, the selection of List elements, moving the insertion point within a text editor, and so forth. Some devices do not allow the direct editing of the value of an Item, but instead require the user to switch to an off-screen editor. In such devices, there must be a dedicated selection operation that can be used to invoke the off-screen editor. The selection of List elements could be, for example, implemented with a dedicated "Go" or "Select" key. Some devices have no dedicated selection key and must select elements using some other means.
On devices where the selection is performed using a dedicated select key, this key will often not have a label displayed for it. It is appropriate for the implementation to use this key in situations where its meaning is obvious. For example, if the user is presented with a set of mutually exclusive options, the selection key will obviously select one of those options. However, in a device that does not have a dedicated select key, it is likely that the selection operation will be implemented using a softkey that requires a label. The ability to set the select command for a List of type IMPLICIT and the ability to set the default command for an Item are provided so that the application can set the label for this operation and can therefore receive a notification when this operation occurs.
The MIDP user interface API has been designed to be thread-safe. There are methods that may be called from callbacks, for example, the methods of a CommandListener, ItemCommandListener, ItemStateListener, TimerTask, or a Thread created by the application. The MIDP system implementation handles its own locking and synchronization to make this possible.
The application is responsible for the synchronization of its own objects and data structures. The MIDP user interface API purposefully serializes callbacks to listeners of high-level API and calls to the event notifications methods of class Canvas, so in most cases the application does not need to perform locking.