Wireless Java

Chapter 4. Working with MIDlets

MIDlets are very simple to implement. All MIDlets must extend the javax.microedition.midlet.MIDlet abstract class and implement certain methods in that class. The MIDlet abstract class provides the basic functionality required in all MIDlets. A MIDlet runs in a controlled environment and therefore must implement certain methods that allow the application manager (which installs and runs the MIDlet) to control the behavior of the MIDlet. These methods are known as life cycle methods, since they reflect various states in which a MIDlet can be.

You’ll recall from the previous chapter that a MIDlet can be in one of three states: paused, active, or destroyed. The state chart in Figure 4-1 shows the possible state transitions of a MIDlet, this time with the addition of the methods that the Java Manager will call inside the MIDlet code during those transitions.

Figure 4-1. MIDlet state transitions

Here, the javax.microedition.midlet.MIDlet abstract class defines three life cycle methods that are called during the state transitions: pauseApp(), startApp(), and destroyApp(). These three methods were present in the example we developed in Chapter 1. The responsibilities for these three life cycle methods are as follows.

public void startApp( )

This method indicates that the MIDlet is moving from a paused state to an active state. Here, the MIDlet will typically initialize any objects that are required while the MIDlet is active, and set the current display.

public void pauseApp( )

This method is called when the MIDlet is moving from an active state to a paused state. This means that it will pause any threads that are currently active, as well as optionally setting the next display to be shown when the MIDlet is re-activated. Data can be persisted, if necessary, and retrieved later when the MIDlet is activated again.

public void destroyApp(boolean unconditional)

This method indicates that the MIDlet is moving to the destroyed state. It should free or close all resources that have been acquired during the life of the MIDlet. In addition, the method should persist any data that it wishes to save for future use.

It is important to note that startApp( ) can be called more than once. In addition to being called when the MIDlet is first activated to move the MIDlet from the paused state to the active state, it can also be called if the MIDlet has been paused during execution and wishes to again return to the active state.

The Application Manager

The application manager, sometimes called the Application Management System (AMS) or MIDlet management software, is software that is preinstalled on a MIDP device and that functions as an operating environment. For example, on a Motorola i85s, the Java Apps menu item will start the application manager, which immediately shows the Java logo and the words “Mobile Information Device Profile Compatible” and then displays a menu of the MIDlet suites that have been installed on the phone.

However, the application manager must do more than simply show a menu of the MIDlet suites that are installed. According to the MIDP specification, the application manager must be able to:

• Retrieve a MIDlet suite from somewhere, possibly through a serial connection, infrared connection, or across a wireless connection to the Internet

• Install a MIDlet suite on the MIDP device

• Perform version management on MIDlet suites that are installed

• Launch a MIDlet from a MIDlet suite and provide an operating environment for the KVM, as well as any system, MIDP, and CLDC classes

• Delete a previously installed MIDlet suite

As a MIDlet programmer, you typically won’t need to be concerned with the internals of the application manager running on the device—it’s unique to each device. However, some insight into its responsibilities is important when designing MIDP applications. In this case, the MIDlet life cycle methods can be called by the application manager to control the MIDlet state:

• When the user launches a MIDlet, the application manager creates a new instance of the MIDlet class by calling its zero-argument constructor. This typically performs the one-time initialization. Once this is done, the MIDlet will be placed in a paused state. However, if any exception occurs during the instantiation of the MIDlet class, the application manager will move the class to the destroyed state.

• After the MIDlet has been placed in the paused state, the application manager calls startApp( ) to transition it to the active state.

• The application manager can then call pauseApp( ) to move it from the active state to the paused state, either via a request from the program itself or from the operating environment.

• destroyApp( ) can be called by the application manager to transition the MIDlet to the destroyed state. The destroyApp() method takes a boolean argument to indicate if the MIDlet should clean up or not.

Example 4-1 shows a MIDlet skeleton class that implements the life cycle methods of the javax.microedition.midlet.MIDlet class.

Example 4-1. MIDlet skeleton

import javax.microedition.midlet.*;

public class MyMIDlet extends MIDlet {

   public MyMIDlet(  ) {
      // constructor
   }

   public void startApp(  ) {
      // entering active state
   }

   public void pauseApp(  ) {
      // entering paused state
   }

   public void destroyApp(  boolean unconditional) {
      // entering destroyed state
   }
}

Believe it or not, this class is all you need to create a MIDlet. The only thing we should reiterate is our earlier warning that startApp( ) can be called more than once. Hence, if you have any one-time initialization that you wish to perform for your MIDlet, be sure that it is placed in the constructor of the MIDlet object and not in the startApp( ) method.

Earlier, we mentioned that a MIDlet could change its own state if needed. The javax .microedition.midlet.MIDlet abstract class provides three methods that can be called by a MIDlet to control its own state transitions:

public void notifyPause( )

A MIDlet may call this method to pause itself. It can be called while in the active state, to inform the Java Application Manager that the MIDlet has entered the paused state.

public void resumeRequest( )

A MIDlet may call this method to express interest in entering the active state. The application manager also calls this method to determine which MIDlet to activate, then it calls its startApp( ) method.

public void notifyDestroyed( )

A MIDlet calls this method to destroy itself. It can be called while in the active state or the paused state, to indicate to the application manager that it has entered the destroyed state. Note that the application manager will not call destroyApp( ). Consequently, the MIDlet manages the release of its resources.