Say hello to J2ME: A programming tutorial

Download the first four and last four reports in PDF.

The Connected Limited Device Configuration (CLDC) and Mobile Information Device Profile (MIDP) combine to support the majority of low-cost mobile devices in use today, such as PDAs, wireless phones and two-way pagers. In this article, you'll get your feet wet with J2ME by building a small sample application.

Hello World!
The process of actually building, installing, and running an MIDP application is significantly different from that used for a standard Java application. So to do justice to the topic, I'll dedicate a future article to it. For now, you'll have to be content to examine the structure of a sample application. I've placed the code for a typical "Hello World!" application, called HelloJ2ME, in Listing A. The results of running HelloJ2ME are shown in Figure A.

FigureA: Why, hello yourself!

The MIDlet class provides three abstract methods that are used by the device's application manager to communicate with the apps it runs. The startApp method is called immediately after the constructor and anytime an application is made active, not just when the application is initially launched. An application may transition between active and inactive states multiple times during a single run, so you should avoid placing single-use initialization code here, such as code to initialize the UI, since it will likely be executed a number of times. Use the constructor for this purpose instead.

The destroyApp method is called by the manager to indicate that an application is about to be shut down. Unlike startApp, this method will be called only once during an application's lifetime, so it's safe to place cleanup code here. In fact, because the MIDP doesn't include finalized functionality for objects, you'll have to perform cleanup here. At the same time, though, a typical mobile device is much less stable than your typical standard platform and will be routinely powered off or reset by the user. So you can't really count on destroyApp being executed either.

The remaining abstract method, pauseApp, is a little weird at first blush. It's meant to provide notification that the app is about to be paused because the user has switched to a different application or is using a function of the device that will prevent the app from continuing to run. Because most mobile devices lack the horsepower to be truly multitasking, this will probably happen to your app a lot. You should also be a good citizen and free any resources you can inside this method. When the application is resumed, the startApp method will be called by the application manager.

Communicating with the application manager
Of course, communication has to be a two-way street to be effective, and MIDP applications are no exception. MIDlet provides a set of final methods you can use to communicate with the application manager:

• NotifyDestroyed tells the manager that your app wants to be shut down. Calling this method will not result in your destroyApp method being executed, so you'll have to call it manually.
  
• NotifyPaused notifies the manager that your app wants to be paused.
  
• ResumeRequest asks the application manager to resume your app if it has been paused.
• GetAppProperty retrieves configuration information about an app from a manifest or an application descriptor file, something I'll discuss further in a future article. For now, it'll suffice to think of this method as accessing a private initialization file.

Meet the family
There are basically three families of GUI components defined in the lcdui package, which I group based on their base classes: Screen components; Item components; and what I'll call Miscellaneous Displayable components.

Screen components
Screen components descend from the abstract class Screen and provide the traditional window-like GUI widgets. The Form object used in HelloJ2ME is a Screen descendant that can contain and display GUI controls. Other Screen components include Alert, a dialog box; List, which displays groups of choices; and TextBox, a multiline text-entry screen.

Item components
Item components are the traditional controls, like the "Hello World!" TextField in the sample app, that all descend from the Item abstract class, which provides a uniform API for labeling, event handling, and displaying controls. ChoiceGroup, DateField, Gauge, ImageItem, and StringItem are other Item components.

Miscellaneous Displayable components
Miscellaneous Displayable components all either descend from the higher-level abstract Displayable class or are in some way related to it. This group includes components like Command, a command button; Ticker, which displays scrolling text; Graphics, for displaying graphics; and Choice, an interface for manipulating predefined selections, which don't really fit in another category.

Figure B illustrates the hierarchical arrangement of these components.

Figure B

The denizens of the lcdui package

The whole graphical shebang is managed by a Display object, of which each application has access to a single, private instance. This instance is retrievable via the static Display.getDisplay method, and it's customary to hold a single reference to this instance in a member variable, as HelloJ2ME does in its constructor. In addition to methods for setting the focus to a particular screen element (setCurrent) and retrieving the element with the focus (getCurrent), Display also exposes a handful of methods useful for obtaining information about the display capabilities of the device, notably whether color is displayed (isColor) and how many colors are supported (numColors).

Things to remember
I'll leave you now with a short list of things to keep in mind when developing Java applications for a mobile platform. First, you'll be dealing with an abbreviated class library: no reflection, JNI, or, as I mentioned, finalization support. Second, you'll be dealing with rather draconian memory restrictions, as most devices running the MIDP profile will have less than 100K of dynamic memory available. As a result, you'll need to keep a wary eye on the memory use of any algorithms you employ. Finally, keep in mind that any network connectivity will be limited in bandwidth and probably sporadic.