MIDlet Program Structure
MIDlet Program Structure
Now that you understand the application execution lifecycle, it's time to look at the source code of
a simple MIDlet. You might have already surmised that I'm going to start by showing you the
simplest MIDlet—the MIDP version of the inveterate "Hello World" program. Listing 3.1 shows
the source code for the first version of the HelloWorld MIDlet.
Listing 3.1 This is the MIDP version of the familiar HelloWorld program.
import javax.microedition.lcdui.Display;
import javax.microedition.lcdui.Displayable;
import javax.microedition.lcdui.Form;
import javax.microedition.midlet.MIDlet;
/**
Creates the "Hello world" program in J2ME MIDP.
Note that the class must be public so that the device
application management software can instantiate it.
*/
public class HelloWorld extends MIDlet
37
{
// The Displayable. This component is displayed on the
// screen.
private Form form;
// The Display. This object manages all Displayable
// components.
private Display display;
// A public no-arg constructor is necessary, even though
// the system calls startApp()! The AMS calls the
// class's no-arg constructor to instantiate the class.
// Either create a public no-arg constructor, or declare
// no constructors, and let the compiler create a public
// no-arg constructor.
//
public HelloWorld()
{
super();
}
public void destroyApp(boolean destroy)
{
form = null;
notifyDestroyed();
}
public void pauseApp()
{
}
public void startApp()
{
// Create a Displayable widget.
form = new Form("Hello, World");
// Add a string to the form.
String msg = "My first MIDlet!";
form.append(msg);
// This app simply displays the single form created
// above.
display = Display.getDisplay(this);
display.setCurrent(form);
}
}
First, notice that this application defines a class called HelloWorld, which extends
javax.microedition.midlet.MIDlet. All MIDlets must extend this class.
The HelloWorld class is the primary class of your application. For this reason, it must be
declared public. Moreover, you must declare a public no-argument constructor, or ensure that
there are no constructors, in which case the compiler will define a no-argument constructor for
you. Readers who are familiar with Java applets will recognize the similarity between the applet
and MIDlet lifecycle control models.
38
When you select HelloWorld from the AMS main screen, the AMS launches your application and
instantiates the HelloWorld class. Technically, it starts the VM (or ensures that one is running)
and instructs it to instantiate your class. The VM calls the no-argument constructor on the instance.
The AMS then calls the startApp() method. In Listing 3.1, the startApp(), pauseApp(),
and destroyApp() methods override abstract declarations from the MIDlet class. Notice that
all the initialization code goes in the startApp() method rather than in the constructor. You
certainly can put some initialization code in your constructor; it will be executed before the call to
startApp(). However, the startApp() method is always called as the entry point for your
MIDlet.
What about a main() method? The Java language definition requires all Java applications to have
a main() method with the following signature:
public static void main(String [] args)
If J2ME applications are real Java applications, as I've claimed previously, then there must be a
main method somewhere that is the real entry point used by the VM to start the process of
executing the application. In fact, there is such a method. It's part of the MIDP implementation
(not the application), and, typically, the AMS software calls it. The AMS handles application
invocation requests, for instance, by spawning a thread for each MIDlet startup request and
controlling the MIDlet from that thread. Actual details are implementation dependent. In Sun's
J2ME Wireless Toolkit, the class com.sun.midp.Main defines the main() method.
The startApp() method creates an object called a form and passes a string to the constructor
that represents the form's title. A form is an instance of the class
javax.microedition.lcdui.Form, which is a kind of screen that you can see on your
display. It's so named because it functions somewhat like an HTML form—it contains one or more
visual items, such as strings.
Next, the startApp() method creates a regular String object and adds it to the form. It then
gets a reference to an object called a display, and it sets the form object as the currently displayed
entity of the display.
After all this code executes, you see the screen in Figure 3.4. When you click or press the handset
button that tells the device to hang up, the AMS invokes destroyApp(), which simply
eliminates all references to the form object previously created. It's now subject to garbage
collection. The AMS then terminates the MIDlet.
You're responsible for properly disposing of objects created by your MIDlets. In this contrived
case, it shouldn't matter whether or not you set the reference to the form variable to null, because
the MIDlet terminates. But in general, you need to properly manage the references to your
program's objects, just as you would in any Java program.
|
839 times read
|
|
|
|
Sections
Syndication
