What's in the High-Level UI API?
The concepts and decisions behind the high-level API are consistent, but their function, display, and placement differs on different devices. The minimum MIDP device requirements are:
- Screen-size: 96x54
- Display Depth: 1-bit
- Approximately Square Pixels
- Input (one or more of the following user-input mechanisms):
- One-handed keyboard
- Two-Handed Keyboard
- Touch Screens
- 128 kilobytes for MIDP components
- 8 kilobytes of non-volatile memory for persistent storage
- 32 kilobytes of memory for the Java heap
- Two, wireless, intermittent with limited bandwidth
MIDP approaches user interfaces using a metaphor of Screens as opposed to the common Window concept used for modern desktop development. MIDP assumes that the target device can display only one screen at a time. It doesn't even provide controls automatically for users to navigate between screensyou have to provide users with buttons or other methods for navigating through multi-screen applications.
The abstract Screen class lets you specify a title and text for a ticker, an item that scrolls text horizontally across the screen (exact ticker placement is specific to the implementation).
|Figure 1: The image on the left shows a Form as rendered on a cell phone. On the right is the Palm OS implementation. Notice the difference between ticker and label placement.
With the high-level UI API you don't handle user events directly; the API captures these commands and either handles them internally or wraps them up as objects that it passes to you for handling. That's good, because you don't have to worry about device-specific navigation, which keys to trap, or how to pass focus to the correct interface item. Instead, you can concentrate on the higher level API interface flow. You'll also find that you can't draw directly to a Screen or its derivatives, but I'll show you a way to display dynamic graphics later in this article.
Screens run under the control of the MIDlet's Display class. To get a reference to the Display class, call the Midlet.getDisplay() method. The object returned from getDisplay is the same throughout the lifecycle of the MIDlet so you can store this value for reference later in your application.
After obtaining the Display instance, you set or remove the currently displayed Screen by calling the Display.setCurrent(Displayable) method. Calling getCurrent returns the currently displayed Screen.
Calling setCurrent replaces the current screen. Calling setCurrent with null removes the current screen. Calling setCurrent, however, doesn't guarantee that the specified Screen will be available when the method call returns; the decision as to when to replace the current screen is left up to the device and the implementation. In other words, performing a potentially time-consuming processing after calling setCurrent might make your application appear to be frozen. To solve the problem, perform such time-consuming tasks in a separate thread. For example, if your application performs a lengthy network lookup, do the lookup in a separate thread to avoid locking up the device display.
MIDP uses the abstract Screen class as the base class from which other screens in the high-level UI API are derived. Screen, in turn, is derived from Displayable. Other displayable classes, such as forms and user interface widgets (called Items), are described below.