- Exploring the J2ME APIs
- Understanding MIDlets
- Building the Skeleton Example Program
- Summary
- Extreme Game Makeover
This chapter is from the book
This chapter is from the book
This chapter is from the book
Understanding MIDlets
Sun Microsystems uses the "let" suffix to name several different types of programs that fall within the Java technology umbrella. Applets, servlets, spotlets, and now MIDlets are some of these. Sun might have even tried to use the term "sniglets" had comedian Rich Hall not already worn it out on the HBO television show Not Necessarily the News in the 1980s. MIDlets are programs that are developed with the J2ME APIs, and that are used in a mobile computing environment. MIDlets require a special runtime environment to run. This environment primarily consists of an application manager that provides a means of selecting and launching MIDlets on a mobile device. The application manager for a MIDlet is responsible for establishing a frame window for the MIDlet.
Inside a MIDlet
It probably won't come as too much of a surprise that every MIDlet must derive from a standard class that is part of the MIDP API. This class is located in the javax.microedition.midlet package, and is named MIDlet. Although the MIDlet class defines several methods, three are particularly important to developing your own MIDlets:
startApp()—Starts a MIDlet
pauseApp()—Pauses a MIDlet
destroyApp()—Destroys a MIDlet
To better understand how these methods impact a MIDlet, it's important to clarify that a MIDlet has three distinct states that determine how it functions: Active, Paused, and Destroyed. These states correspond directly with the three methods, which are usually called directly by the runtime environment's application manager; in some cases you can call them yourself, particularly the destroyApp() method. These methods are collectively referred to as life cycle methods because they control the life cycle of a MIDlet. They are ultimately what allow the application manager to manage multiple MIDlets and provide each of them with shared access to device resources.
MIDlet Life Cycle
The life cycle of a MIDlet is spent between the three states you just learned about. In a typical MIDlet, most of the time is spent in the Active or Paused states, and then when the MIDlet closes it enters the Destroyed state until it is completely removed from memory. You override the relevant MIDlet life cycle methods in most game MIDlets because it is important to allocate and free resources based on the state of the MIDlet. For example, when a game MIDlet starts, you will probably need to create objects and/or load data. When the MIDlet pauses, it will probably make sense to free up some resources, close any network connections, and pause game music. And finally, upon destruction it is important to free up any resources you've allocated, as well as to save any pertinent game data.
Keep in mind that a MIDlet can enter and exit the Active and Paused states several times throughout its lifetime. However, after a MIDlet enters the Destroyed state it cannot return. In this regard, an individual game MIDlet only has one life to live.
MIDlet Commands
In addition to overriding the life cycle methods, most MIDlets implement the commandAction() method, an event response method defined in the javax.microedition.lcdui.CommandListener interface. Commands are used to control game MIDlets and initiate actions such as pausing a game, saving game data, tweaking game settings, and quitting a game. MIDlet commands are accessible through a soft button or a menu, and must be handled by the commandAction() method.
NOTE
Soft buttons are special buttons located near the screen on a mobile phone that are used to issue commands specific to a particular MIDlet. Clicking a soft button initiates the command on the screen just above the button. Buttons used to control game play are handled in a different manner than soft button commands, as you learn in Chapter 6, "Handling Mobile User Input."
The Display, Screens, and Canvases
One other important MIDlet concept worth tackling at this point is the Display class, which represents the display manager for a device. The Display class is defined in the javax.microedition.lcdui package, along with other GUI classes, and is responsible for managing the display and user input for the device. You don't ever create a Display object; you typically obtain a reference to the Display object in the startApp() method for a game MIDlet, and then use it to establish the game screen and user interface. There is exactly one instance of Display for each MIDlet that is executing on a device.
Another important display-related class is javax.microedition.lcdui.Canvas, which represents an abstract drawing surface the size of the device screen. A canvas is used to perform direct graphics operations such as drawing lines and curves or displaying images. As you might suspect, canvases form the basis for game screens. In fact, there is a special javax.microedition.lcdui.game. GameCanvas class devoted solely to drawing efficient graphics for games. The GameCanvas class differs from the Canvas class in that it supports a highly efficient means of drawing animated graphics, which are often used in games.
NOTE
If you create a game that has customizable settings or otherwise needs to retrieve information from the user, you probably need to use the javax.microedition.lcdui.Screen class. A screen is a generic MIDlet GUI component that serves as a base class for other important components. The significance of screens is that they represent an entire screen of information; only one screen can be displayed at a time. You can think of multiple screens as a stack of cards that you can flip through. Most MIDlets utilize subclasses of the Screen class such as javax.microedition.lcdui.Form, javax.microedition.lcdui.TextBox, or javax.microedition.lcdui.List because they provide more specific functionality. Screens can be used with Canvas objects to provide a comprehensive GUI for a game MIDlet. You can't show a screen and a canvas at the same time, but you can alternate between the two.
The Basics of MIDlet Development
To get started developing MIDlets, you first need to install the J2ME Wireless Toolkit, which is available on the accompanying CD-ROM. You can also use a third-party mobile Java development tool if you want to target a specific mobile phone, but you can stick with the J2ME Wireless Toolkit for now if you want to stick with emulating Java-powered phones on your PC.
To take a MIDlet game from concept to reality, you need to take the following steps:
Develop the source code files.
Compile the source code files into bytecode classes.
Preverify the bytecode classes.
Package the bytecode classes into a JAR (Java archive) file with any additional resources and a manifest file (more on this in a moment).
Develop a JAD (application descriptor) file to accompany the JAR file.
Test and debug the MIDlet.
Step 1 is carried out with a simple text editor. If you don't have a programming text editor, you can use a simple editor such as Notepad in Windows. Step 2 involves using the standard Java compiler to compile the source code files for your MIDlet. In step 3 you are required to preverify the compiled bytecode classes with a special preverification tool. Step 4 involves using the Java archive (JAR) tool to compress the MIDlet source code files, resources, and manifest file into a JAR file. Step 5 requires you to create a special application descriptor file, which is a text file containing information about your MIDlet. And finally, in step 6 you get to enjoy your hard work and test out the MIDlet with the J2ME emulator.
Although you could carry out each of these individual development steps with the command-line tools included in the J2ME Wireless Toolkit, you saw in the previous chapter how Sun's KToolbar visual tool simplifies the build/test process into a couple of mouse clicks.