The MIDlet has released all resources and terminated. This state,
which can only be entered once, can be entered when the destroy-
App(boolean unconditional) method is called by the AMS
and returns successfully. If the unconditional argument is false, a
MIDletStateChangedException may be thrown and the MIDlet
will not move to the DESTROYED state. Otherwise, the destroy-
App() implementation should release all resources and terminate any
running threads, so as to guarantee that no resources remain blocked
or using memory after the MIDlet has ceased to execute.
The MIDlet also enters the DESTROYED state when the notify-
Destroyed() method successfully returns; the application should
release all resources and terminate any running threads prior to calling
2.2.2 Developing a MIDlet
Once the source code has been written, we are ready to compile, pre-
verify and package the MIDlet into a suite for deployment to a target
device or a device emulator.
In this section, we create our first MIDlet in a simple but complete
example of MIDlet creation, building, packaging and execution. We use
a tool called the Java Wireless Toolkit (WTK) which provides a GUI
that wraps the functionality of the command-line tool chain: compiler,
pre-verifier and packaging tool.
The WTK (see Figure 2.3) was created by Sun to facilitate MIDP
development. It can be obtained free of charge from Sun's website
( java.sun.com/products/sjwtoolkit/download.html ).
The WTK offers the developer support in the following areas:
Building and packaging: You write the source code using your favorite
text editor and the WTK takes care of compiling it, pre-verifying the
class files, and packaging the resulting MIDlet suite
Running and monitoring: You can directly run applications on the
available mobile phone emulators or install them in a process emu-
lating that of a real device. Your MIDlets can be analyzed by the
memory monitor, network monitor and method profiler provided by
MIDlet signing: A GUI facilitates the process of signing MIDlets,
creating new key stores and key pairs, and assigning them to different
security domains for testing with the different API permission sets
associated with those domains.