J2ME

What is J2ME or Java ME?

Primary components of the Java Platform, Micro Edition (Java ME, formerly J2ME) include Connected Device Configurations, Connected Limited Device Configurations, Mobile Information Device Profiles, along with many other tools and technologies that address Java solutions for the consumer and embedded device markets. Take your first step into learning more about these technologies. Definitions of terms, and what these new concepts can mean to you are available here

Application Development

Part 1: Creating MIDlets

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.

Figure 1.:

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

Understanding the Process of MIDlet Creation--Without the Toolkit

There are seven steps in the creation of a MIDlet. These steps are: designing, coding, compiling, preverification, packaging, testing, and deployment. Some of these steps are not strictly MIDlet-centric (for example, every application needs to be designed, coded, and compiled), but we will cover them here because there are MIDlet-centric differences. The Toolkit abstracts a lot of these steps so that it is easier for you in the overall scheme of things. This is fine and dandy once you know the process, but when you are only starting out, you really should be coding by hand, rather than using a sugar-coated abstraction.

To ensure that we get a hands-on understanding of these steps, let us take the help of a simple example. We will create a MIDlet that, when executed, will print the current date and time on a mobile device for a short time. Along with this in mind, keep Figure 2 handy to understand the sequence of these steps. Also, note that I will explain the lifecycle of MIDlets later. For the moment, let's get a simple MIDlet up and running, which will illustrate these steps.

Figure 2.:

Steps to MIDlet creation

Step 1: Design

MIDlets are different from other applications that you may have created, simply because MIDlets run in an environment that is very different. There are several issues, not just those that are most visible (for example, the interactivity of your MIDlet with the user), but others that impact its usability.

For the example application, our Date-Time MIDlet does not need user interactivity. It needs to display the current date and time for a few seconds when the user executes the MIDlet. For simple cases like this, it is perhaps sufficient to mimic the design of the MIDlet by drawing it on a piece of paper. For more complex designs with multiple screens, it is best to design the screens professionally before starting the actual coding process. Step 2: Code

Each MIDlet must extend the abstract MIDlet class found in the javax.microedition.midlet package, much like creating an applet by extending the java.applet.Applet class. At the minimum, your MIDlet must override three methods of this abstract class, startApp(), pauseApp(), and destroyApp(boolean unconditional). Here is the DateTimeApp class:

package com.j2me.part1;

import java.util.Date;

import javax.microedition.lcdui.Alert; import javax.microedition.lcdui.Display; import javax.microedition.midlet.MIDlet;

public class DateTimeApp extends MIDlet {

 Alert timeAlert;
 public DateTimeApp() {
   timeAlert = new Alert("Alert!");
   timeAlert.setString(new Date().toString());
 }
   public void startApp() {
   Display.getDisplay(this).setCurrent(timeAlert);
 }
 public void pauseApp() {
 }
 public void destroyApp(boolean unconditional) 
 {
 }

}