Helping You Pass the Sun Certified Mobile Application Developer Certification

The Mobile Information Device Profile and MIDlets, Part 1

by Kim Topley Editor's note: This is the first of a five part book excerpt series based on O'Reilly's J2ME in a Nutshell by Kim Topley. Part one is an overview of MIDP and the MIDP Java platform.

MIDP is a version of the Java platform based on CLDC and KVM that is aimed at small footprint devices, principally cell phones and two-way pagers. It is also suitable for running on PDAs, and an implementation is available for PalmOS Version 3.5 and higher. (In the longer term, it is intended that these devices use the PDA profile, which is also hosted by CLDC.) The MIDP specification was developed under the Java Community Process and is available for download from http://jcp.org/jsr/detail/37.jsp.

The logical position of MIDP within the software architecture of a device that implements it is shown in Figure 3-1. The software that implements MIDP runs in the KVM supplied by CLDC and provides additional services for the benefit of application code written using MIDP APIs. MIDP applications are called MIDlets. As Figure 3-1 shows, MIDlets can directly use both MIDP facilities and the APIs described in Chapter 2 that MIDP inherits from CLDC itself. MIDlets do not access the host platform's underlying operating system and cannot do so without becoming nonportable. Because the KVM does not support JNI, the only way for a MIDP application to access native platform facilities directly is by linking native code into a customized version of the virtual machine.

Sun provides a reference implementation of MIDP that can be used on Windows; the Wireless Toolkit, which contains versions of MIDP for Windows, Solaris and Linux; and a separate MIDP product for use on PalmOS-based PDAs. Device manufacturers typically use the Sun reference implementation as the basis for their own products. They usually integrate additional code as part of their MIDP implementation to provide management features such as installation, removal, and management of MIDlets that are not portable between devices and hence not part of the reference software. As shown in Figure 3-1, this code (labeled "OEM Code") may use some combination of MIDP and CLDC services and will also depend on the host platform's operating system. Some parts of the core MIDP software are themselves device-dependent and thus are also supplied by the manufacturer. These typically include parts of the networking support, the user interface components, and the code that provides persistent storage.

MIDP Hardware Requirements

As mentioned earlier, MIDP is intended for small devices with limited memory, CPU, and display capabilities. The minimum hardware requirements are described in the following sections.

Memory

As you'll see over the next few chapters, MIDP includes quite a lot of software that is not part of the core Java platform and therefore requires more memory than the minimal CLDC environment is obliged to supply. The MIDP specification requires at least 128 KB of RAM be available to store the MIDP implementation itself, over and above whatever is needed by CLDC. In addition to this, there must be at least 32 KB available for the Java heap. In practice, a 32 KB heap is very limiting and demands that the developer exercise great care when allocating objects and take all possible steps to avoid holding references to objects longer than necessary, in order to allow the garbage collector to reclaim heap space as quickly as possible. As well as the RAM requirement, MIDP devices must also supply at least 8 KB of nonvolatile memory to be used as persistent storage so that MIDlets can save information in such a way that it is not lost when the device is switched off. The content of this storage is not guaranteed to be preserved over battery changes, however, and there is a general expectation that the device also provides some way (such as the PDA "hot sync" mechanism) to back up its content to a more permanent location.

Display

MIDP devices are characterized by small displays. The specification requires that the screen should be at least 96 pixels wide and 54 pixels high and that each pixel be (approximately) square. The screen must support at least two colors, and many cell phones are capable of no more than this. At the top of the range, PDAs typically have screens with 160 pixels in each direction and support as many as 65,536 different colors. This wide disparity in capability provides the developer who wants to write a fully portable MIDlet with some interesting challenges, and it has led to some trade-offs in the MIDP user interface library, as we'll see in Chapters and .

Input device

As with displays, there are several different types of input device that might be found on a MIDP platform. At one end of the spectrum, the more sophisticated devices, like the RIM wireless handheld, have a complete alphanumeric keyboard, as shown on the left of Figure 3-2. Similarly, PalmOS-based handhelds allow the user to "write" on a special area of the screen using a form of shorthand known as Graffiti; they also provide a simulated onscreen keyboard for users who prefer a more traditional approach. The screenshot on the right side of Figure 3-2 shows the Graffiti area of a Palm handheld.

Contrast these highly functional keyboards (or keyboard substitutes) with the more basic one that you'll find on most cell phones, an example of which is shown in Figure 3-3. Keyboards like this provide relatively easy numeric input, but they require slightly more work on the part of the user to type alphabetic characters, and there are almost no special characters available.

The minimum assumption made by the MIDP specification is that the device has the equivalent of a keypad that allows the user to type the numbers 0 through 9, together with the equivalent of arrow keys and a select button as shown in the diamond-shaped arrangement at the top of Figure 3-3, where the select button is the white circle between the arrows. These requirements are directly met by cell phones and may be satisfied in various ways on other devices. On the Palm, for example, there are buttons that may be programmed to act as directional arrows, while the select operation can be performed by tapping the screen with the stylus. As we'll see in Chapter 5, this cut-down representation of the input device is reflected in the APIs that handle the user interface, and it requires the developer to be careful when handling events from whatever passes for the keyboard on the device on which a MIDlet is running.

Connectivity

Mobile information devices have some kind of network access, whether it's the built-in wireless connection in a cell phone or pager, or a separate modem attached to a PDA. MIDP does not assume that devices are permanently attached to a network or that the network directly supports TCP/IP. It does, however, require that the device vendor provide at least the illusion that the device supports HTTP 1.1, either directly over an Internet protocol stack, as would be the case for a Palm handheld connected to a modem, or by bridging a wireless connection to the Internet via a WAP gateway. This provision allows developers to write network-aware MIDlets that work equally well (other than performance differences due to differing network bandwidth) across all supported platforms.

MIDP Software Requirements

Sun's reference version of MIDP is not a commercial product. Device vendors are expected to port the reference implementation to their own hardware and software by implementing code that bridges the gap between the expectations of Sun's reference code and the vendor's hardware and operating system software. As with the hardware described previously, the reference implementation makes the following assumptions about the capabilities offered by the software base on which it will be hosted (shown as "Host Platform Operating System" in Figure 3-1):

• The operating system must provide a protected execution environment in which the JVM can run. Because CLDC supports the threading capabilities of J2SE, the host platform ideally supports multithreading, and, if it does, the KVM can make direct use of it. However, MIDP implementations are required to provide the illusion of multithreading even when this is not available from the native operating system. They do this by sharing the single available thread between the Java threads that belong to application code and those used within the VM and the MIDP and core libraries.

• Networking support is required in some form. On some platforms, such as PalmOS, a socket-level API is available, over which the mandatory MIDP HTTP support can be implemented. In the case of devices that do not offer such a convenient interface, including those that do not have direct connectivity to an IP-based network, the vendor is required to provide a means for HTTP to be bridged from the device's own network to the Internet. The networking aspects of MIDP are discussed in detail in Chapter 6.

• The software must provide access to the system's keyboard or keypad (or equivalent) and a pointing device, if it is available. The software must be able to deliver events when keys are pressed and released and when the pointing device is moved or activated. (For example, for a handheld with a stylus, the software must deliver an event when the stylus touches the screen, when it is lifted off the screen, and when it moves over the screen.) The vendor is required to map whatever codes are delivered by the user's keystrokes to a standard set of values so that similar keystrokes lead to the same results across different hardware platforms. This issue is discussed further in Chapter 5.

• It must be possible to access the device's screen. MIDP allows MIDlets to treat the screen as a rectangular array of pixels, each of which may be independently set to one of the colors supported by the device. Therefore, it is required that the software provide access to the screen as if it were a bit-mapped graphics device. MIDP user interfaces and graphics are covered in detail in later chapters.

• The platform must provide some form of persistent storage that does not lose its state when the device is switched off (that is, when it is in its minimum power mode, but not necessarily when it has no power at all). MIDP provides record-level access to this storage and therefore requires that the host software supply some kind of programmatic interface to its persistent storage mechanism. The MIDP storage APIs are described in Chapter 6.

The MIDP Java Platform

The Java platform available to MIDlets is that provided by CLDC as described in Chapter 2, together with a collection of MIDP-specific packages arranged under the javax.microedition package hierarchy. The core libraries themselves are almost unaffected by the MIDP specification; the only change is the addition of the J2SE 1.3 timer facility in the java.util package, which will be covered in the later section "Timers and TimerTasks". The MIDP specification also places the following requirements on the core libraries:

• Like applets, MIDlets are managed in an execution environment that is slightly different from that of a Java application. As you'll see shortly, the initial entry point to a MIDlet is not the main( ) method of its MIDlet class, and the MIDlet is not allowed to cause the termination of the Java VM. In order to enforce this restriction, the exit( ) methods in both the System and Runtime classes are required to throw a SecurityException if they are invoked.

• In addition to the system properties defined by CLDC, MIDP devices must set the microedition.locale property to reflect the locale in which the device is operating. The locale names are formed in a slightly different way from those used by J2SE, because the language and country components are separated by a hyphen instead of an underscore character. A typical value for this property would be en-US on a MIDP device, whereas a J2SE developer would expect the locale name in the form en_US. Since both MIDP and CLDC provide almost no support for localization, however, the precise format of this property is of little direct interest to MIDlets. Instead, it is intended to be used when installing MIDlets from external sources, to allow the selection of a version of the MIDlet suitable for the device owner's locale. The property must therefore be properly interpreted by the agent (perhaps a servlet running in a web server) that supplies the software.

• The system property microedition.profiles must contain at least the value MIDP-1.0. In the future, as new versions of the MIDP specification are released and implemented, devices that support multiple profiles may list them all in this profile, using spaces to separate the names.

In summary, the values of the system properties that are introduced by or changed by MIDP relative to the requirements placed by CLDC, are shown in Table 3-1.

In the next installment, the focus will be on MIDlets and MIDlet Suites.

Kim Topley has more than 25 years experience as a software developer and was one of the first people in the world to obtain the Sun Certified Java Developer qualification.