Can Java phone home?

• By Chris Carpenter
• December 1, 2001

Cellphones have become ubiquitous devices. Whether or not the need is perceived or real, people want to carry one to be in touch, connected, or heard. Whatever the reason, there are a lot of cellphones sold every year and they have one killer application ... voice.

Up until this year, about the only application you could do with a phone was voice. Yes, there are some phones with simple personal information managers or games. However, until Motorola released its Java-enabled phones this year, phone capabilities were pretty much fixed at the factory by whatever applications a telecom company thought should go in them. While other manufacturers have released Java-enabled phones, I will only examine the offering from Motorola.

Before we discuss Java applications in cellphones, we need to acknowledge that for the past year and a half some digital phones have come with Web browsers. But browsing with a phone has not been a killer application for several reasons, most of which boil down to speed.

Wireless application protocol (WAP) applications must send and receive over a relatively slow 19kbps (in most cases) connection. Due to backward-compatibility with HDML1.0 (the original HTML for phones), most WAP providers don't take advantage of some of the more advanced capabilities of Wireless Markup Language (WML). But I am not going to talk about WAP because the technology can't succeed until connection speeds and built-in browsers have many of the capabilities of their desk-tethered brethren.

What you can do, though, is write an application that takes full advantage of the features and capabilities built into a cellphone, and then download and run it. Who knows, you may have the idea for a killer app in a phone beyond voice.

What Can You Do With a Phone?
Well, that depends on the phone, but for the new phones coming out of Motorola, such as the iDEN i85s/i50sx, you can write a Java application that conforms to the Sun J2ME Mobile Information Device Profile (MIDP) specification and run it using the Motorola- built JVM that resides in the phone. The MIDP spec combines with the connected limited device configuration to define all the classes and methods accessible within the phone.

Phone applications are, of necessity, constrained by the classes of objects available and by the user interface, available memory, processing speed, and network bandwidth.

Although keyboard interfaces for phones are available, you should not design an application that assumes the user has access to a keyboard. The majority of users will interact with your application via the cellphone's 10-key keypad and a tiny display. Some phones now come with a T9 input mode that allows for a more natural word entry from users, but switching between T9 and the traditional "triple-press" for a letter-data entry on a phone can become tedious. The applications you create should not require users to key in much data, and display screens should minimize the amount of scrolling users have to perform.

One of the exciting aspects of Java-enabled phones is that they're always connected to the network. Network- aware applications present an exciting programming opportunity on the phone. Wireless messaging is already a done deal, but opportunities for communicating with backbone-side services that run as agents and provide information to the phone are mostly untapped.

Phones Talk to Java Servers
I'll show you a simple application that communicates from the phone to a server to retrieve files. This will provide you with a good overview of how to build a simple MIDP user interface and how to use UDP messages to communicate from a phone to a server. To do your own development, you'll need to download the Motorola iDEN development tools for simulating a MIDP device and the Sun J2ME libraries. Both are free. After you have your application running in the simulator, you'll be able to transfer it to a real phone using the Motorola Java Application Loader.

The code examples listed here address only the phone side of the connection. I will assume readers know how to write a standard J2EE application that services UDP requests; therefore, that code is not presented.

The two phone-side classes are MidpClient (see Listing 2) and DatagramListener (see Listing 3). The MidpClient, which is the phone-side client application, contains the methods for displaying and interacting with the MIDP user interface Form and stores the incoming data in a phone RecordStore. The DatagramListener simply listens for UDP datagrams and is used by the MidpClient to receive data.

Some items to note in MidpClient:

• MIDLet is the base class of phone applications (like an Applet).
  

  
  public class MidpClient extends MIDlet implements
    CommandListener.
  

• In the phone, forms are equivalent to Frames in AWT.
  

  
    protected Form form = new Form("Inputs").
  

• When the environment is ready to begin your application, init() is called followed by startApp(). In this method, you paint your form as follows:
  

  
  public void startApp() {
            Display currentDisplay = Display.getDisplay(this);
            MidpClient client = new MidpClient();
            client.createForm();
            currentDisplay.setCurrent(client.form);
  }
  
            protected String destAddress = "datagram://";
                protected int destPort;
  }
  

• Use RecordStore to store data in the phone. Most phones do not support a file system or any FileIO (see Listing 1).