J2ME Programming (Part I)

J2ME Overview

J2ME (Java 2 Micro Edition) is a family of APIs that specify
application platforms that are typically implemented by embedded or handheld
devices. Handheld devices include PDAs (Personal Digital Assistants) and high-end
mobile phones. These platforms are typically limited in memory capacity and I/O
capabilities, although they do have the ability to transfer data over low
bandwidth, intermittent wireless connections.

J2ME SDKs

Competing Technologies

Quick Start: "Hello World"

We will be using the Sun/Java J2ME SDK. This SDK includes
the J2ME Wireless Toolkit. Here's its GUI (called K Toolbar):

Creating a New Project and Midlet

Applications that run on a MIDP/CLDC platform are called midlets.
By pressing the "New Project" button we create a new project named Examples
containing a midlet defined in a file named HelloWorld.class:

The console window informs us that it has created a project
directory named Examples containing src, res, and lib
subdirectories:

Other subdirectories have been created as well. We must save
our .java files in the Examples\src subdirectory.

HelloWorld.java

The file Examples\src\HelloWorld.java is created
using an ordinary text editor. It begins by importing several J2ME packages:

Notice that HelloWorld extends MIDlet. Two instance
variables are declared and subsequently initialized by the constructor. theDisplay
represents the display window of the PDA or mobile phone. mainScreen
represents the screen that theDisplay is supposed to display. This is
accomplished in startApp() method by the line:

theDisplay.setCurrent(mainScreen);

startApp() is one of three lifecycle methods every midlet
must define. In most of our examples the other two have empty bodies. We can
think of theDisplay as a mini web browser and mainWindow as a
type of web page. In our example, mainPage is a text box titled
"Example 1" and containing the text "Hello World".

Running HelloWorld

Pressing the Build button on the toolbar causes the Wireless
Toolkit to compile all .java files in the current project's src
subdirectory. The corresponding .class files are placed in the classes
subdirectory. Next, the .class files are pre-verified. If a .class
file passes various security checks, it is tagged as verified. All of the
project's verified files are placed in an archive file called Examples.jad.
This file is placed in the bin subdirectory.

Pressing the Run button on the toolbar causes the Wireless
Toolkit to start a mobile phone simulator. The Examples application
suite is "downloaded" to the "phone," which displays the
suite's midlets in its window. Currently, HelloWorld is the only midlet.
Launching this midlet causes the window to display the midlet's main page. Use
the red "hang up" button to terminate the midlet.

J2ME APIs

HelloWorld extended the MIDlet class and contains references
to a Display object (theDisplay) and a TextBox object (mainScreen). TextBox
extends the Screen class, which is the base class for all high-level GUIs.
Low-level displays, where the programmer must define his own graphics, extend
the Canvas class.

The midlet responds to user input commands by selecting a
displayable object from this collection, then asking the display to display it
with the command:

theDisplay.setCurrent(displayables[next]);

Here's a more comprehensive class diagram showing the lcdui
package:

First notice that in addition to text boxes, there are three
other types of screens: alerts (a message dialog that flashes on the display),
forms (a control panel containing control items such as labels, text fields,
and buttons), and lists.

A displayable can fire and handle commands. A command is
fired when the user presses keypad buttons when the displayable is the current
window. When a command is fired, a command object is passed to the
commandAction() method of each registered command listener. Typically, the
midlet is the command listener.

Form items also fire commands. When an item command is
fired, a command object is passed to the commandAction() method of each
registered item command listener. Typically, the midlet or the parent form is
the item command listener.

The J2ME Application Manager

The Application manager manages the lifecycles of midlets:

Commands and The Midlet as a Command Processor

To demonstrate commands and command processing, let's add a
new midlet to the Examples project. Pressing the Settings button on the
Wireless Toolkit toolbar displays the Settings dialog. Pressing the Add button
at the bottom of this dialog allows us to add a new project called navigator
contained in the CommandProcessor.class file:

Running the Command Processor

Here are some screen shots of the Navigator running on the
simulator. Notice that the opening screen now shows the Examples suite contains
two midlets. Selecting the navigator midlet causes the midlet's first screen to
appear. The screen is titled "Screen 0" and displays the question
"Shall we go to screen 1?". That's all Navigator allows users to do:
to navigate from screen i to screen j.

Notice that the phone's soft buttons are labeled Back
and Menu. The Back button will allow us to return to the midlet's
previous screen. The menu button displays a list of commands the current screen
can fire:

CommandProcessor.java

The command processor midlet has much in common with
HelloWorld. Instead of a single screen, the constructor will create an array of
five screens plus a help screen. The startApp() method will display
screen[0] in theDisplay.

The makeScreen() method creates a type of screen called an
Alert. An alert is a warning or confirmation that flashes on the display, only
in our case we are setting the duration of the flash to be forever (users will
have to get rid of the alert by navigating to another screen). Each screen is
declared capable of firing five pre-defined commands (OK, CANCEL, BACK, HELP,
and EXIT) as well as one custom command (cmmd_0, for example). Finally, the
midlet is registered as the screens listener:

Handling Commands

The CommandProcessor implements the CommandListener
interface. This means that it must implement a commandAction() method and that
it can subsequently be registered as a listener for the screens. A typical
commandAction() implementation uses a switch statement that dispatches to a
sub-handler based on the type of the input command. In most cases, a new screen
is selected and is set as theDisplay's current displayable: