In this column we tackle Java on cellphones, specifically looking at the Motorola SDK for Java.
Why Java on Cellphones?
If your cellphone already supports WML or another markup language (like HDML or Compact HTML), is there any advantage to being able to run Java programs on it as well? What can a Java program do that a set of WML decks can’t?
The first advantage is that Java is a proper programming language, in the procedural/object-oriented sense, and is used on a wide variety of platforms. WML is a declarative language, to which you graft some procedural logic using WMLScript, and is used only on cellphones. Java is more suited for complicated programming tasks.
The second advantage is that Java lets you work offline. With a Java-enabled cellphone it’s possible to download and install an application that you can then run without incurring connection charges, something you can’t really do when you’re browsing websites with the phone’s microbrowser. You can even run applications when you’re out of coverage, something that may be foreign to Europeans but something that we North Americans — with our vast geographical areas and competing, incompatible networks — have to deal with on a regular basis.
Of course, you can work offline to a degree with WML by using cached decks, but only if the decks are designed to be cached. And you really don’t have much control over what gets cached, since it’s all under the control of the browser and the deck creator.
Java 2 Micro Edition
One of the problems with Java is that the runtime system — the Java interpreter, the native code that interfaces to the operating system, and the Java runtime library — is quite large. When I say “large”, I mean several megabytes, clearly too much for small computing devices like today’s cellphones. And that’s where Java 2 Micro Edition (J2ME) comes in. Instead of merely trimming fat from the Java 2 Standard Edition (J2SE), J2ME is a complete rewrite of the Java runtime with the specific memory and processing power restraints of small devices in mind.
Central to J2ME are the concepts of configurations and profiles. A configuration defines the basic features of a Java runtime system: what the virtual machine must do, how much memory is required, and the core set of runtime classes (ideally a subset of ones in J2SE). A profile builds on top of a configuration (and even on top of other profiles) by adding classes geared for a specific family of devices or specific kinds of applications.
There are currently two configurations defined. The one that interests us is the Connected Limited Device Configuration, or CLDC for short, which is optimized for cellphones and other “limited” handheld devices. (To access any of the specifications referred to in this article, see the list of links I maintain at ericgiguere.com/microjava/links.html.) The CLDC defines a new virtual machine called the KVM, and you’ll often see people using the two terms interchangeably. Unlike the “classic” VM included with J2SE, the KVM is very memory-sensitive and is also easy to port to various platforms.
If you look closely at the CLDC, however, you’ll see that it only defines a very minimal set of runtime classes. In particular, there are no user interface classes. This and other higher-level functionality is left for the profiles to define. For the CLDC, a profile called the Mobile Information Device Profile has been defined which adds these basic features to the CLDC:
- application packaging and lifecycle (“MIDlets”, similar to applets)
- user interface (both low-level and high-level)
- data persistence (simple record databases)
- network connectivity (HTTP support)
The expert group that defined the MIDP specification reads like a “Who’s who” of the handheld world, including such leaders as Motorola, Nokia, Ericsson, Research in Motion, Palm and others. So when phone and handheld manufacturers talk about Java-enabling their devices, they’re usually referring to a MIDP-based J2ME implementation. In fact, Motorola was the specification lead for the MIDP, which brings us to the next topic….
Motorola’s First Java-Enabled Cellphone
Motorola is set to release its first Java-enabled cellphone this December, the i3000 (code-named “Condor”), one of its family of multi-communication devices that run on the iDEN (Integrated Digital Enhanced) network (the major operators of iDEN networks are Nextel in the US and Clearnet in Canada). If you’re unfamiliar with the technology behind iDEN, here’s a good summary and comparison to other technologies.
Although the i3000 is to be Motorola’s first Java-enabled phone, it won’t be the last. Motorola has publically committed to add Java support to all its new phone models, not just the iDEN phones. Motorola has a large group of developers working throughout the company on implementing J2ME for its devices.
Developers anxious to try out an actual i3000 will have to wait until the end of the year, but in the meantime you can download Motorola’s J2ME SDK from the iDEN developer website. You’ll have to register, but it’s free. As I write this, the current SDK on the site is a beta, Developer Drop 5, that complies with the MIDP 0.95 specification, so it’s slightly behind the MIDP 1.0 spec. Most of the functionality is there, however.
Once you’ve downloaded the SDK, install it by extracting the contents of the ZIP file into C:\MotoSDK. (You’ll need it there if you ever intend on using it with the CodeWarrior for Java development tool from Motorola’s subsidiary, Metrowerks.) After installation, go to the command line and run Motorola’s cellphone simulator:c:\MotoSDK> runMotoiDEN
You’ll see a simple MIDP sample running on your desktop just like that in the screenshot accompanying this article.
This is one of several examples included with the SDK. It also includes a very professional User’s Guide in PDF format that walks you through all the samples and gets you started with some very basic MIDP programming. You’ll still need to get and read the actual MIDP specification, of course, to do any serious programming.
Now that the MIDP 1.0 specification is final (it just happened last month) and the i3000 is soon to be released, you can expect to see an updated SDK show up soon with complete support for the SDK. I know that I can hardly wait to get my hands on an actual device!
More on J2ME programming next time…