Wireless J2ME Platform Programming
- The Application Execution Lifecycle
- The MIDlet State Model
- The MIDP UI Component Model
- System Properties
- Application Properties
- Chapter Summary
The Application Execution Lifecycle
MIDlet Program Structure
The MIDlet State Model
The MIDP UI Component Model
In this chapter, you'll learn about the basic abstractions and programming model that the MIDP defines. It's necessary to understand the basic MIDP programming model in order to write MIDP applications. You must also understand the abstractions defined by the user interface (UI) components in order to build user interfaces using the MIDP. Before looking at source code, however, you must first understand the MIDlet execution lifecycle.
The Application Execution Lifecycle
Here's an example of the steps involved in executing an application:
Start the emulator. You'll see a window appear that simulates the device interface. If you're using the J2MEWTK v1.0.2, you'll notice that the emulator simply executes the HelloWorld application because it's the only application present in the suite. Figure 3.1 shows the main screen of this MIDl etexecution. With the J2MEWTK v1.0.3, however, you'll see a selection list of all MIDlets, even if there is only one.
Figure 3.1. This MIDlet run uses the default color phone supplied with the toolkit. Notice the MIDlet title.
Add a second version of the program, called HelloWorld2, to the MIDlet suite. You can begin this process by pressing the Settings… button on the toolkit main window, which you saw back in Figure 2.5 in chapter 2. First write the source code, and then place it in the project's src/ directory. Add it to the MIDlet suite by selecting the MIDlets tab of the screen that displays the project settings screen. Figure 3.2 shows the configuration screen after adding the new MIDlet.
Figure 3.2. Add new MIDlets to a suite using the MIDlets tab of the Settings window.
Now, build the project and then execute it. This time you see the display shown in Figure 3.3. Notice that now you see a menu that displays the names of both MIDlets contained in the MIDlet suite. Because there is more than one MIDlet to execute, the AMS must display a menu and allow you to select the one you wish to run. Of course, the emulator takes on the role of a real device's AMS here.
Figure 3.3. When more than one MIDlet is available, the AMS displays a menu showing you all of them. The AMS, not your application, creates the Launch button. You must click it to invoke the selected MIDlet.
On a real device, the device's AMS displays this menu. For example, Motorola and Siemens phones both use standard select lists that allow you to select first the AMS, then the MIDlet suite, and finally, the MIDlet. In other markets (in Japan, for instance), phones might have a button labeled "Web," which launches the AMS and automatically starts a Java-based Web browser. The MIDlets listed are those that are known to the AMS.
When you add a MIDlet to the suite, you're telling the toolkit that you want the new MIDlet to be available for execution. When you build the MIDlet, the toolkit places its .class files in the MIDlet suite JAR file and updates the manifest and JAD files. This behavior adheres to the J2ME specification, which, you recall, requires that MIDlets be contained in a JAR file.
Select the HelloWorld MIDlet and then click the Launch soft button to execute it. Figure 3.4 shows the single screen that it creates and displays.
Figure 3.4. This application's main screen contains a title and a single line of text.
Click (press) the red handset button ("hang up") on the emulator and you are returned to the AMS main screen. Closing the emulator window ends the emulation. You've now completed the whole application execution lifecycle. Later in this chapter, you'll learn more about the details of the MIDlet lifecycle and the MIDlet state model.