A core feature of the MIDP (Mobile Information Device Profile) technology is its support for developing mobile phone user interfaces. The MIDP provides a set of Java APIs known as the LCDUI, which has functionalities similar to the Java Abstract Windows Toolkit (AWT) and Swing APIs in the desktop world. This article covers mobile phone UI development using the MIDP APIs. Our focus is the MIDP 2.0 API, which is standard on all Nokia Developer Platform 2.0 devices. At the time of writing (late 2004), Developer Platform 1.0 devices, which are based on MIDP 1.0, still have a large installed base. Hence, the key differences between the MIDP 2.0 and MIDP 1.0 APIs are also briefly covered throughout the discussion. The topics in this article are as follows:
Screen and Canvas classes.
Canvas and how to handle keypad events. A useful example illustrates how to add animation functionality to Canvas applications.
Existing Java developers can get started with the MIDP very quickly because it leverages some proven design patterns in standard Java UI APIs, such as the AWT and Swing. The MIDP LCDUI supports two programming models: the widget-based, high-level model and the pixel-based, low-level model.
The LCDUI high- and low-level APIs satisfy the needs of different developers. The high-level API is very easy to learn and to use. It aims to support fast development cycles, and it is easier to write portable code with the high-level API. The low-level API provides raw power and flexibility to developers who need to control every aspect of the user experience. In this section, we look at those two APIs from a bird's-eye view.
The high-level API
The design goal of the high-level API is to support programming applications that are portable across devices. It provides
a set of standard UI classes representing basic UI components at a high abstraction level. Devices implement the components,
and, therefore, an application programmed with high-level APIs adopts the native look and feel of that device. For example,
the Series 40 and Series 60 devices often render the same widget differently according to their own UI guidelines. The high-level
API is mostly suitable for business applications, which do not differentiate themselves with UI innovations. Such applications
offer a "no-surprise" UI to users and have minimal learning curves. Their value comes from the content and functionalities
behind the user interface.
However, the drawback with the high-level UI approach is also obvious: the developer has little control over the drawing details and cannot go beyond the predefined set of widget components. For instance, it would be hard to develop an animation screen using the high-level API alone.
Archived Discussions (Read only)