Developing software for mobile phones using J2ME

Kristian Nylund

Email:

ACM Classification: D.2.0, D.2.3

ACM SIGs: SIGMOBILE, SIGSOFT

Abstract

This paper presents the Java 2 Micro Edition and in particular its use when developing software for mobile phones. An overview and some background on J2ME is presented, followed by some technical descriptions of J2ME itself and of aspects relating to the creation of software with J2ME. Basic knowledge of Java and object-oriented programming is assumed.

Table of Contents

1Introduction

2Overview of J2ME

2.1Implementing J2ME

2.2Specification structure

3Configurations and profiles

3.1Configuration - CLDC

3.2Profile - MIDP

4Creating MIDlets

4.1Sample MIDlet - Hello World

4.2MIDP Components

4.2.1Networking

4.2.2User interface

4.2.3Permanent storage

4.3Packaging and publishing MIDlets

5Development tools

5.1Software Development Kits

5.2Integrated Development Environments

6Applications for J2ME

7Conclusion

8References

1Introduction

The advent of Java 2 Micro Edition (J2ME) and its implementation in mobile phones has finally made it possible for third-party developers to create software for mobile phones, an area which before, apart from in the case of some high-end phones, has been in total control of the phone manufacturers. Presently, almost all new handsets come equipped with the ability to run J2ME – applications (called MIDlets), and the possibilities for developers are considerable.

J2ME is a version of Java aimed at smaller devices, such as Personal Digital Assistants (PDA), Set-Top boxes, and mobile phones.

In this paper I will present the J2ME environment, with an emphasis on the Mobile Information Device Profile (MIDP) and its use in developing software for mobile phones. I will start with an overview and some history on J2ME, what it entails for manufacturers to implement it, and present the different configurations and profiles of J2ME and how they differ.

Next, I will go into a little more detail about the configurations and profiles, with an emphasis on those relating to J2ME on mobile phones. In the following chapter I will describe the basics of creating J2ME – applications, providing some source-code examples. After this, I will present some of the development tools available for J2ME-development, such as Integrated Development Environments (IDE) and Software Development Kits (SDK).

Finally, I will explore some of the practical applications that J2ME makes possible, with regard to mobile services and wireless applications.

2Overview of J2ME

J2ME, announced at the JavaOne Developer Conferences in June 1999, is a highly optimized Java run-time environment aimed at a wide range of smaller devices, such as pagers, Personal Digital Assistants (PDA), mobile phones and set-top boxes ([JoGo01]). It is already used in a variety of devices, the most recent of which are mobile phones. Since Java – enabled phones entered the market, the interest in J2ME – development has surged, and the amount of available MIDlets on the Internet just keeps growing.

2.1Implementing J2ME

J2ME in itself is not a specific piece of software or specification. It just means Java for small devices ([Knu01]). The actual specification is contained in the configurations and profiles, which in turn need to be implemented by the device manufacturers.

In the case of mobile phones, it is common for the manufacturers to implement some device-specific extensions in addition to the profile itself, such as the ability to control the loudspeaker and vibrator on the phone. It should be noted that creating MIDlets that take advantage of these extra features no longer adhere to the original specifications, and thus cannot be used on devices which do not support them, i.e. devices from other manufacturers.

2.2Specification structure

To specify the Java Runtime Environment (JRE), J2ME uses configurations and profiles. The configurations determine which Java Virtual Machine (JVM) is used and the profiles determine the application by adding domain-specific classes ([JoGo01]).

There are currently two configurations defined for J2ME, Connected Limited Device Configuration (CLDC) and Connected Device Configuration (CDC). CLDC is used for smaller, 16 or 32 bit devices with limited amounts of memory (e.g. PDAs and mobile phones), while CDC is used for 32 bit devices with over 2 MB of memory (e.g. Set-top boxes). This paper will concentrate on CLDC.

The profiles are built on top of the configurations. For CLDC, there are a variety of profiles, e.g. KJava and MIDP. KJava is Sun's proprietary profile, containing a Sun-specific API that runs on the Palm OS ([JoGo01]). MIDP is geared towards devices like mobile phones and two-way pagers, and will be profile focused on in this paper.

3Configurations and profiles

J2ME technologies are based on configurations and profiles. These are defined through the Java Community Process (JCP), and they are subject to compatibility tests.

A configuration defines the minimum set of class libraries available for a range of devices, and it may not contain optional features. A profile specifies a collection of APIs that supplement a configuration to provide capabilities for a specific device type ([Sun02]).

3.1Configuration - CLDC

As this paper focuses on J2ME on mobile phones, the configuration I will present is the CLDC. CLDC was created by the Java Community Process, which has standardized this configuration defined by Sun Microsystems as a "portable, minimum-footprint Java building block for small, resource-constrained devices" ([JoGo01]).

CLDC is targeted for devices with limited resources such as slow network connections, limited power, relatively small amounts of memory and constrained user interfaces.

The following requirements are defined for CLDC: ([JSR30])

For devices:

  • 128KB or more of non-volatile memory
  • 32 KB of volatile memory
  • Host operating system available to manage the underlying hardware, providing at least one schedulable entity to run the Java virtual machine

For the specification:

  • Java language and virtual machine features
  • Core Java libraries (java.lang.*, java.util.*)
  • Input/Output
  • Networking
  • Security
  • Internationalization

3.2Profile - MIDP

MIDP is the profile which extends the CLDC for use with, among other things, mobile phones. The profile addresses the display toolkit, user input, persistent data storage and networking over wireless telephony connection.

The requirements defined for MIDP are: ([JSR37])

For devices:

  • Screen with resolution 96x54 pixels, 1-bit color depth and pixel shape 1:1
  • One or more of the following user-input mechanisms: one-handed keyboard, two-handed keyboard or touch screen.
  • 128 KB of non-volatile memory for the MIDP components
  • 8 KB of non-volatile memory for application-created persistent data
  • 32 KB of volatile memory for the Java runtime
  • Two-way, wireless, possibly intermittent networking with limited bandwidth
  • Basic capabilities for reading and writing non-volatile memory, using the network and timers, writing bit-mapped graphics and handling user input.

For the specification:

APIs for the following:

  • Application
  • User interface
  • Persistent storage
  • Networking
  • Timers

4Creating MIDlets

There are a few requirements that every functional MIDlet needs to fill:

  • javax.microedition.midlet.* and javax.microedition.lcdui.* must be imported
  • The main class must extend the abstract MIDlet class
  • public void commandAction(Command c, Displayable d) from the CommandListener – interface needs to be implemented in order to handle any kind of user input.
  • The following abstract methods from the MIDlet class must be defined ([Cym01]):
  • public void startApp(), allocates system resources and initializes the application
  • public void pauseApp(), temporarily suspends the application
  • public void destroyApp(boolean unconditional), releases resources and disposes of the MIDlet

An important fact about MIDP is the absence of the Float – class; floating-point calculations in MIDlets are not supported.

A unique property of MIDlets is the ability to have several MIDlets share resources, such as a database, within the context of a single JVM by grouping them together in a so-called MIDlet suite ([Whi01]).

Version 1.0 of the MIDP specification considers all MIDlets "untrusted", and as such they are executed in a sandbox. This enforces security by preventing MIDlets from accessing sensitive functions on the device. The upcoming version 2.0 of MIDP introduces trusted MIDlets, which would have access to these functions. The origin and integrity of these MIDlets would have to be verified by the device.

4.1Sample MIDlet - Hello World

Listing 1 shows a simple MIDlet displaying the words "Hello World" in a TextBox (see section 4.2.2). The result of running the MIDlet in the Nokia 6310i emulator can be seen in Figure 1.

Listing 1:

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

public class HelloWorldMIDlet extends MIDlet implements CommandListener {

private Command exitCommand;

private Display display;

private TextBox tb;

public HelloWorldMIDlet() {

exitCommand = new Command("Exit", Command.EXIT, 1);

tb = new TextBox("Example MIDlet", "Hello, World!", 20, 0);

tb.addCommand(exitCommand);

tb.setCommandListener(this);

}

public void startApp(){

display = Display.getDisplay(this);

display.setCurrent(tb);

}

public void pauseApp(){}

public void destroyApp(boolean unconditional) {}

public void commandAction(Command c, Displayable d) {

if (c == exitCommand) {

destroyApp(false);

notifyDestroyed();

}

}

}

Figure 1

4.2MIDP Components

In this section I will give brief descriptions of the most often used components defined in the MIDP standard. These components, in addition to the slightly modified java.io, java.lang and java.util packages included from standard Java, are what the developer has at his disposal when creating MIDlets.

4.2.1Networking

MIDP includes support for several types of network connections.

Components: (package javax.microedition.io)

Interfaces:

ConnectionThe most basic type of connection.

ContentConnectionConnection that provides content length, type, and encoding information.

DatagramGeneric datagram connection.

DatagramConnectionDefines necessary capabilities for a datagram connection.

HttpConnectionConnection that provides capabilities for interfacing through HTTP.

InputConnectionDefines necessary capabilities for input streams.

OutputConnectionDefines necessary capabilities for output streams.

StreamConnectionDefines necessary capabilities for stream connections.

StreamConnectionNotifierDefines necessary capabilities for connection notifiers.

4.2.2User interface

The MIDP's user interface is abstracted by a so-called screen. A screen is an object that handles graphical rendering and user input. A MIDlet basically consists if several screens, only one of which can be active at any given time.Only items on the active screen can be accessed.

Components: (packagejavax.microedition.lcdui)

Interfaces:

ChoiceDefines capabilities for components implementing selection of a number of predefined choices.

CommandListenerDefines methods that need to be implemented in order to handle user input.

ItemStateListenerDefines methods that need to be implemented for receiving indication of changes in items on a Form.

Classes:

AlertDisplays a message to the user regarding an error or an exceptional event.

CanvasBase class for writing applications that need access to the low- level events and drawing to the display.

ChoiceGroupA group of predefined, selectable entries of which one or several can be chosen.

CommandRepresents information about an action, such as a label, a type, and a priority. The resulting behaviour is defined in the implementation of the CommandListener – interface.

DateFieldAn editable component for representing dates and times.

DisplayRepresents the display and input system of the device.

FontHandles fonts and font metrics.

FormUsed when several displayable components need to be displayed simultaneously, by grouping them together.

GaugeImplements a bar graph display.

GraphicsProvides simple 2D graphics operations.

ImageHolds graphical images in the Portable Network Graphics (PNG) – format.

ListThe most frequently used graphical component in MIDlet programming. It displays a list of entries of which one or several can be chosen, similarly to the ChoiceGroup – class.

StringItemAllows strings to be put on a Form.

TextBoxA screen consisting of a field that allows the user to input or edit numerical or alphanumerical text.

TextFieldLike TextBox, but instead of being a screen, a TextField is used as a component on a Form.

TickerImplements a ticker string that runs continuously across the screen.

4.2.3Permanent storage

MIDP defines a mechanism of storing data persistently, i.e. the data is saved between invocations of a MIDlet. This is done using a simple record-oriented database.

Components: (package javax.microedition.rms)

Interfaces:

RecordComparatorImplemented to define how records in a particular RecordStore compare to each other.

RecordEnumerationProvides a bidirectional enumeration of the contents of a RecordStore.

RecordFilterImplemented to filter out records from a RecordStore according to specified rules.

RecordListenerImplemented to receive events from a RecordStore.

Classes:

RecordStoreConsists of records which stay persistent between invocations of the MIDlet.

4.3Packaging and publishing MIDlets

A finished MIDlet or MIDlet suite consists of a compressed Java Archive (jar) – file and a Java Application Descriptor (jad) – file. The jar – file contains everything the MIDlet suite needs to run, such as the class – files and possible pictures. The jad – file is a manifest describing the application, e.g. its size, author and version. The device needs this file to run the application it describes.

The process of creating the jad/jar consists of the following steps:

  • Compile the classes
  • Preverify the classes
  • Create the jar file
  • Create the jad file

Preverification checks the class – files to make sure that they do not try to perform any invalid operations.

Listing 2 shows what the jad-manifest for the Hello World – example could look like.

Listing 2:

MIDlet-1: HelloWorldMIDlet

MIDlet-Jar-Size: 1389

MIDlet-Jar-URL: HelloWorldMIDlet.jar

MIDlet-Vendor: Kristian Nylund

MIDlet-Version: 1.0

There are other attributes that can be defined in the manifest, but those listed in Listing 2 are required.

There are several ways of transferring the MIDlet suite to the device, e.g. by cable, infrared (IR), Bluetooth or Over-The-Air (OTA) using the Wireless Application Protocol (WAP). Of these, the only method that is available on all Java-enabled mobile phones is OTA.

5Development tools

Since MIDP in itself is only a specification, an implementation needs to be obtained before MIDlet development can begin. Sun provides a basic implementation called the J2ME Wireless Toolkit, and the phone manufacturers provide SDKs suitable for their respective phones.

In this chapter I will present a few of these SDKs, as well as some IDEs which allow integrating of these SDKs.

5.1Software Development Kits

The J2ME Wireless Toolkit is available from It provides a fundamental implementation of CLDC/MIDP, an emulation environment, documentation and examples.

Nokia provides tailored SDKs for each of their Java-enabled phones. These include the MIDP implementation extended by some Nokia-specific capabilities, an emulator, a programming environment with JAR/JAD packaging and examples. They are available from

The Motorola iDEN SDK is available from It provides an implementation of CLDC/MIDP, and emulator, a JAD/JAR packaging tool and project management facilities.

Siemens provides the Siemens Mobility Toolkit SDK for developing J2ME applications for Siemens phones. The SDK includes the MIDP implementation with Siemens-specific enhancements, an emulator and documentation. It is available from

Sony-Ericsson does not yet provide a complete SDK for download, but an emulator which can be used with the IDEs presented in the next section is available from

5.2Integrated Development Environments

There are several IDEs available for Java development, some commercial and some free. Many of these support J2ME development, either as a built-in ability or as an extension by the SDKs presented in the preceding section. Here I will present a few of these IDEs.

The BorlandJBuilder is available in several versions, one of which if free of charge. J2ME development is supported both through the Borland Mobile Set and through integration of SDKs. More information can be found at

The Sun ONE Studio is an IDE also available both commercially and free of charge. The Mobile Edition used for J2ME development is free. More information can be found at

The Metrowerks CodeWarrior Wireless Studio is a commercially available IDE which is intended for J2ME development. Information about this product can be found at the manufacturers' website,

6Applications for J2ME

Although most of the MIDlets found on the web are either games or small utilities, the biggest promise lies in the wireless communication aspect of J2ME. Since MIDP defines APIs for many types of network communication, including HTTP, the possibilities for client/server type applications are considerable, for consumer – oriented applications as well as for tailored solutions for various industries.

An important restriction regarding hand-held, networked terminals has long been the size of the device and, is some cases, the need for a mobile phone in addition to the device to provide network connectivity. J2ME disposes of this restriction; the application can now be run solely on a mobile phone, which an increasing number of people carry anyway.

The most compelling scenarios for the usage of J2ME involve databases and client-programs running on mobile phones, providing access to the database from almost anywhere. Applications for this can be found for most industries, the concept of having an almost unlimited amount of information stored in a database available on a mobile phone could be extended to serve a multitude of purposes.

An interesting possibility would be for grocery stores to provide the contents of their stock – databases via a MIDlet. This would allow consumers to check the availability and price of items in different stores, while perhaps keeping a shopping list in a RecordStore and comparing the price of this "shopping basket" between stores. By using standard barcode numbers as identification for items, the application could work for different stores.

7Conclusion

The popularity of the Java programming language only seems to be rising, and new areas in which to use it are discovered constantly. Java on mobile phones is certainly an important concept, one which provides a wealth of new possibilities.

In this paper I have given a brief overview of Java on mobile phones, as well as presented some practical aspects of developing applications for mobile phones. While the contents of the paper provide some important background information on how to get started in MIDlet development, some further reading is necessary to achieve proficiency in this area. The references provided should prove to be good further reading for those who desire more information.

8References

[Cym01]MichaelCymerman: Device programming with MIDP, JavaWorld, 2001

[JoGo01]Shari Jones, StevenGould: J2ME: Step by step, IBM developerWorks, June 2001

[JSR30]Java Community Process: JSR-000030 J2ME Connected, Limited Device Configuration Specification Version 1.0a, May 2000

[JSR37]Java Community Process: JSR-000037Mobile Information Device Profile Specification Version 1.0a, December 2000

[Knu01]JonathanB.Knudsen: Developing with Java 2, Micro Edition, APress, June 2001

[Sun02]Sun Microsystems: J2ME Configurations,

[Whi01]JimWhite: Big Plans for J2ME, JavaPro May 2001 Issue, Fawcette Technical Publications