Tour of MIDP Features - Wireless Java Developing with J2ME, Second Edition

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 MIDlet class Jargoneer implements java.lang.Runnable, and the technique for kicking off a new thread is the same as it always was:

       Thread t = new Thread(this);
       t.start();

Significant parts of java.lang are essentially unchanged from J2SE, as are parts of java.io and java.util. The code that reads the result from the server in lookUp() is familiar stream handling, just like what you might see in J2SE.

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), Application Management Software (AMS), 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, I'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-3 shows this TextBox.

Figure 2-3: 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. You specify only a label and a type, and you register an event listener to find out when the commands are invoked. This is purposely vague—it leaves the implementation considerable latitude in deciding how commands should be displayed and invoked. In Sun's J2ME Wireless Toolkit 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. The Web server is actually an intermediary—it connects to the real Jargon File server, makes a request, parses the result, and sends the stripped-down definition back to the MIDP device.

In the first edition of this book, Jargoneer connected directly to the Jargon File server. In response to its query, it received a lot of information it didn't need. The original Jargoneer went to considerable trouble to parse through the HTML response to extract the definition it wanted. Architecturally, the old Jargoneer looked like Figure 2-4.

Figure 2-4: Jargoneer architecture

The new architecture is shown in Figure 2-5.

Figure 2-5: A cleaner architecture for Jargoneer

Instead of hitting the web server directly, Jargoneer goes through a different server hosted by Apress. This server queries the Jargon File, parses the result, and returns the definition to the device. This is advantageous from several stand-points:

• 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.