Java 2 Micro Edition (J2ME) combines a resource-constrained JVM and a set of Java APIs for developing applications for mobile devices. This article is the first in a series. This time, after a quick introduction to J2ME, I will provide a step-by-step guide to creating J2ME applications, also known as MIDlets, using a simple example. This will cover how to test and deploy these MIDlets as well. Finally, I will round out this installment with a look at the lifecycle of a MIDlet.
J2ME Introduction
What is J2ME? Cut away the hype and the excess fat and you are left with yet another (set of) Java APIs. Since these APIs cannot run on a traditional Java Virtual Machine (JVM), due to the limited size of mobile devices in regards to memory and resource availability, J2ME defines a limited version of the JVM as well. In a nutshell:
J2ME combines a resource constrained JVM and a set of Java APIs for developing applications for mobile devices.
Do you, as a developer, have to install this JVM and the APIs on mobile devices? No. Device manufacturers install and prepackage their devices with this JVM (and associated APIs). As a developer, you only need to develop applications targeting these devices and install them. Easier said than done!
J2ME can be divided into three parts, as shown in Figure 1: a configuration, a profile, and optional packages. A configuration contains the JVM (not the traditional JVM, but the cut-down version) and some class libraries; a profile builds on top of these base class libraries by providing a useful set of APIs; and optional packages, are well, an optional set of APIs that you may or may not use when creating your applications. Optional packages are traditionally not packaged by the device manufacturers, and you have to package and distribute them with your application. The configuration and profile are supplied by the device manufacturers and they embedded them in the devices.
he most popular profile and configuration that Sun provides are the Mobile Information Device Profile (MIDP) and Connected Limited Device Configuration (CLDC), respectively. As the name suggests, CLDC is for devices with limited configurations; for example, devices that have only 128 to 512KB of memory available for Java applications. Consequently, the JVM that it provides is very limited and supports only a small number of traditional Java classes. (This limited JVM is actually called the KVM.) Its counterpart, the Connected Device Configuration (CDC) is for devices with at least 2MB of memory available and supports a more feature-rich JVM (but still not a standard JVM).
The MID profile complements the CLDC configuration very well because it minimizes both the memory and power required for limited devices. It provides the basic API that is used for creating application for these devices. For example, it provides the javax.microedition.lcdui package that allows us to create the GUI elements that can be shown on a (limited) device running the MID profile on top of a CLDC configuration. Note that MIDP cannot be used with CDC devices. CDC devices get their own set of profiles, like the Foundation and Personal profiles. However, I will not cover these profiles or the CDC here, and will concentrate on using MIDP and CLDC only.
The latest versions of MIDP and CLDC are 2.0 and 1.1, respectively. Not many devices currently support these versions, but the list is growing rapidly. Sun maintains a list of devices according to version.
Acquiring and Installing the J2ME Development Kit
Getting started with developing applications (henceforth called "MIDlets") for the J2ME platform is easy. Although device manufacturers install and prepackage their devices with this JVM (and associated APIs), you still need to install the J2ME Wireless Toolkit 2.2 on your development machine. Before that, however, you must also have the Java Development Kit (JDK), version 1.4.2 or greater, installed.
Warning: I had problems getting the Wireless Toolkit to work properly with JDK 5.0. If you don't need the latest features in version 5.0, it is best to stick to any 1.4.2 version. I have used 1.4.2_05 for all examples in this series.
You need this Toolkit because it contains tools that are important in generating MIDlets. This Toolkit provides the development environment for the MIDP 2.0 and CLDC 1.1 (and for MIDP 1.0 and CLDC 1.0, since these parameters are backwards compatible), and it provides the optional packages required for the optional libraries, like 3D and Mobile Media applications. Lastly, it provides the ability to sign your MIDlets so that they can be authenticated before installation on a remote mobile device.
Once you download the installation package for the Toolkit, install it in the directory of your choice. The default, on Windows, is C:\WTK22, and this will be the installation directory for the examples in this series as well. I will not explain the directories created under this folder just now. Before I do that, let us try and understand the process of generating a MIDlet from scratch.
Pages: 1, 2, 3
