Java Reference
In-Depth Information
CHAPTER 3
■ ■ ■
All About MIDlets
I n Chapter 2, you got a quick introduction to the process of building and running MIDlets. In
this chapter, you'll explore the details. We'll cover the subjects that we skimmed in the last
chapter, starting with the MIDlet life cycle and continuing through to a full discussion of
MIDlet packaging. The chapter concludes with a look at the MIDlet security architecture.
The MIDlet Life Cycle
MIDP applications are represented by instances of the javax.microedition.midlet.MIDlet
class. MIDlets have a specific life cycle, which is reflected in the methods and behavior of the
MIDlet class.
A piece of device-specific software, the application manager , controls the installation,
execution, and life cycle of MIDlets. MIDlets have no access to the application manager. A
MIDlet is installed by moving its class files to a device. The class files will be packaged in a Java
Archive (JAR), while an accompanying descriptor file (with a .jad extension) describes the
contents of the JAR.
A MIDlet goes through the following states:
1.
When the MIDlet is about to be run, an instance is created. The MIDlet's constructor is
run, and the MIDlet is in the Paused state.
2.
Next, the MIDlet enters the Active state after the application manager calls startApp() .
3.
While the MIDlet is Active, the application manager can suspend its execution by calling
pauseApp() . This puts the MIDlet back in the Paused state. A MIDlet can place itself in
the Paused state by calling notifyPaused() .
While the MIDlet is in the Paused state, the application manager can call startApp() to
put it back into the Active state.
4.
5.
The application manager can terminate the execution of the MIDlet by calling
destroyApp() , at which point the MIDlet is destroyed and patiently awaits garbage
collection. A MIDlet can destroy itself by calling notifyDestroyed() .
Figure 3-1 shows the states of a MIDlet and the transitions between them.
29
Search WWH ::




Custom Search