As a programmer, you probably know that the first program you ever write when
you are learning a new language is displaying the famous words, 'Hello
World". This was the first program that the founders of the great C
language introduced when they introduced the C language to the world.
Here is the MIDP version of the inveterate "Hello
World" program. The following J2ME code sample shows the source code for the first version of the HelloWorld
MIDlet.
In the program above, 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, 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. 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.
//This is the MIDP version of the familiar HelloWorld program.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.
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
{
// 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);
}
}
In the program above, 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, 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. 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.
