Tour of MIDP Features | ColdFusion MX Professional Projects

Team-Fly

Having gotten our first MIDlet to run, let's take a moment to admire it. There are several salient features, even in such a small example.

It's Java

First of all, Jargoneer is written in the Java language, the same language you'd use to code servlets, Enterprise JavaBeans, or J2SE client applications. If you're already a J2SE developer, you'll be extremely comfortable developing MIDlets.

Not only is the Java language familiar, but also many core APIs are very similar to J2SE. Notice, for example, that multithreading in Jargoneer is just the same as it might be in any other Java code. The inner class Poster extends java.lang.Thread, and kicking off a new thread is the same as it always was:

      Poster p = new Poster(word);      p.start(); // Runs in its own thread.

Significant parts of java.lang are essentially unchanged from J2SE, as are parts of java.io and java.util. Lots of the Jargoneer source code involves parsing the word definition received back from the Jargon File server, and this should all be very familiar stream handling and string manipulation.

MIDlet Life Cycle

Jargoneer also demonstrates the basic structure of MIDlets. Like all good MIDlets, it extends javax.microedition.midlet.MIDlet, the base class for all MIDP applications. Special software on the device, called the Java Application Manager (JAM) or MIDlet management software controls the process of installing, running, and removing MIDlets. When a user chooses to run your MIDlet, it is the JAM that creates an instance of the MIDlet class and runs methods on it.

The sequence of methods that will be called in your MIDlet subclass is defined by the MIDlet life cycle. MIDlets, like applets and servlets, have a small set of well-defined states. The JAM will call methods in the MIDlet to signify changes from one state to another. You can see these methods in Jargoneer: startApp(), pauseApp(), destroyApp(), and Jargoneer's constructor are all part of the MIDlet life cycle.

Generalized User Interface

Jargoneer's user-interface code may take you by surprise. Later on, we'll spend several chapters on user interface. For now, the important thing to notice is how Jargoneer's user interface is flexible enough to run on devices with different screen sizes and different input capabilities. A big part of MIDP's appeal, after all, is the concept of writing one set of source code that runs on multiple devices.

One example of MIDP's generalized user interface is the TextBox that is initially shown when Jargoneer is launched. Figure 2-2 shows this TextBox.

Figure 2-2: The Jargoneer's TextBox

TextBox is a text input field. It has a title and an area for entering text. It has a simple design and can easily be shown on screens of different sizes. Even more interesting are the commands that appear at the bottom of the TextBox. These are Exit and Find. The code that creates the TextBox and its commands is in Jargoneer's constructor:

     mExitCommand = new Command("Exit", Command.EXIT, 0);     mFindCommand = new Command("Find", Command.SCREEN, 0);     // ...     mSubmitBox = new TextBox("Jargoneer", "", 32, 0);     mSubmitBox.addCommand(mExitCommand);     mSubmitBox.addCommand(mFindCommand);     mSubmitBox.setCommandListener(this);

Notice how the commands are created. We specify only a label and a type, and we register an event listener to find out when the commands are invoked. This is all purposely vague-it leaves the implementation considerable latitude in deciding how commands should be displayed and invoked. In Sun's J2MEWTK emulator, for example, TextBox shows its commands at the bottom of the screen and allows the user to invoke them using soft buttons. Another device might put both commands in a menu and allow the user to invoke them using a selector wheel or some other mechanism.

The Likelihood of Server-Side Components

The Jargoneer example connects to a Web server, sends a request, and receives a response. Unfortunately, we're receiving a lot of information we don't need. We go to considerable trouble in the Poster class to parse through the returned HTML response to extract the definition we want. Architecturally, it looks like Figure 2-3.

click to expand
Figure 2-3: Jargoneer architecture

A much more likely architecture is shown in Figure 2-4.

click to expand
Figure 2-4: A cleaner architecture for Jargoneer

Instead of hitting the Web server directly from our code, we go through a different server. This server actually queries the Jargon File, parses the result, and returns the definition to the device in some stripped-down format. This is advantageous from several standpoints:

Bandwidth is expensive in terms of both time and money. Today's wireless networks are relatively slow, so less data passing through the air means less waiting time for your users. Also, wireless service tends to be pricey, so less data passing through the air means smaller bills for your users.
Small devices have limited memory and processing power. It is unwise to spend these limited resources on tasks like parsing HTML. In general, you will be able to place most of the processing burden of your application on a server component, making your client MIDlet's life very easy.
In this particular application, the HTML parsing is not very stable. Suppose the server we are using decides to return its Jargon File definitions in a different format; if four million users are running Jargoneer, then four million copies of our code have just broken. Performing this task on a server gives it a single point of failure and a single point of update. If we fix the parsing code on the server, the interface between the server and the client devices can remain unchanged. This makes it easy to upgrade or fix Jargoneer.

Network MIDP applications are likely to need a server component. If you're planning to do much MIDP development, you might like to study up on Java servlets.

Team-Fly