Java Reference
In-Depth Information
public void destroyApp(boolean unconditional) {
}
}
Wow! That's a lot of code for so little typing. As you browse the NetBeans IDE,
you'll notice two things. First, large swaths of the code are on a blue background; the
IDE autogenerates and maintains these blocks of code. Second, if you compare the
appearance of these lines with the code shown in Listing 3-1, you'll notice that the list-
ing has many lines with comments like
//GEN-BEGIN
,
//GEN_LINE
, and
//GEN_END
, followed
by unique identifiers. The NetBeans IDE inserts these comments and uses them to tag
the code it creates and maintains; if you edit the source code, be careful not to edit
these lines, as you will lose your changes when you go back to use the Screen Designer
and Flow Designer again.
While I go into more detail about the structure of MIDlets in Chapter 4, it's worth
your time for me to point out now a few things about the code the NetBeans IDE gener-
ated for us. Just like traditional applets and applications, MIDlets have a specific life
cycle, although it's a little different than for applets:
•
Construction
: When the application management system launches a MIDlet, an
instance is created, resulting in the runtime invoking the MIDlet's constructor. The
MIDlet is now said to be
paused
.
•
Active
: When the application manager calls the MIDlet's
startApp
method, the
MIDlet is
active
and running normally.
•
Paused
: At any time, the application manager can pause the MIDlet to permit
another application access to the handset (such as for an incoming call) by invok-
ing
pauseApp
. Alternatively, a MIDlet can place itself in the same state by invoking
notifyPaused
. From this state, the application manager can resume the application
by invoking
startApp
again.
•
Destroyed
: The application manager can terminate the MIDlet's execution at any
time by calling
destroyApp
. Alternatively, the MIDlet can destroy itself by calling
notifyDestroyed
.
Figure 3-8 shows the MIDlet life cycle.
