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