UNIT-II

What is J2ME or Java ME?

Java Platform, Micro Edition (Java ME) provides a robust, flexible environment for
applications running on mobile and embedded devices: mobile phones, set-top boxes,
Blu-ray Disc players, digital media devices, M2M modules, printers and more.

Java ME technology was originally created in order to deal with the constraints
associated with building applications for small devices. For this purpose Oracle defined
the basics for Java ME technology to fit such a limited environment and make it possible
to create Java applications running on small devices with limited memory, display and
power capacity.

J2ME Architecture

J2ME consists of two elements -- configurations and profiles.

Configurations provide a set of libraries and a virtual machine for a category of wireless
device. There are two configurations for J2ME, one for fixed wireless devices and one for
mobile wireless devices.

Profiles are APIs built on top of configurations to provide a runtime environment for a
specific device, such as a PDA, cellphone, or set-top box. The profile manages the
application, user interface, networking and I/O.

J2ME currently defines two configurations:

Connected Limited Device Configuration (CLDC)

CLDC is aimed at the low end of the consumer electronics range. A typical CLDC
platform is a cell phone or PDA with around 512 KB of available memory. For this
reason, CLDC is closely associated with wireless Java, which is concerned with allowing
cell phone users to purchase and download small Java applications known as MIDlets to
their handsets. A large and growing number of cell phone vendors have signed
agreements with Sun Microsystems that will allow them to begin using this technology,
so the number of handsets with the capability to be programmed in Java
will probably grow rapidly in the next few years.

Connected Device Configuration (CDC)

CDC addresses the needs of devices that lie between those addressed by CLDC and the
full desktop systems running J2SE. These devices have more memory (typically 2 MB or
more) and more capable processors, and they can, therefore, support a much more
complete Java software environment. CDC might be found on high-end PDAs and in
smart phones, web telephones, residential gateways, and set-top boxes. Each
configuration consists of a Java virtual machine and a core collection of Java classes that
provide the programming environment for application software. Processor and memory
limitations, particularly in low-end devices, can make it impossible for a J2ME virtual
machine to support all of the Java language features or instruction byte codes and
software optimizations provided by a J2SE VM. Therefore, J2ME VMs are usually
defined in terms of those parts of the Java Virtual Machine Specification and the Java
Language Specification that they are not obliged to implement. As an example of this,
devices targeted by CLDC often do not have floating point hardware, and a CLDC VM is
therefore not required to support the Java language types float and double or any of the
classes and methods that require these types or involve floating-point operations.

It is important to note that configuration specifications do not require implementations to

use any specific virtual machine. Vendors are free to create their own VM or license a
third-party VM, provided that it meets the minimum requirements of the specification.
Sun provides reference implementations of both configurations, each of which includes a
conforming virtual machine:

 The CLDC reference implementation is a source code and binary product for the
Windows, Solaris and Linux platforms. It includes the Kilobyte Virtual Machine
(KVM), a reduced-functionality VM that has a very small memory footprint and
incorporates a garbage collector that is optimized for a memory-constrained
environment. KVM, which is discussed in Chapter 2, is likely to be used as the
basis for most CLDC implementations in the near future, but there are other VMs
that could be used instead, such as the J9 VM from IBM.
 The CDC reference implementation is a source code-only product for Linux and
the Wind River VxWorks real-time operating system. The VM included with this
product, called CVM (see Chapter 7), implements the full range of J2SE VM
features as required by the CDC specification. However, it does not include the
HotSpot technology found in the J2SE Version 1.3 VM or even a just-in-time
compiler (JIT) as found in earlier J2SE releases. Several third-party vendors,
including Insignia Solutions and IBM, have plans to release their own CDC
implementations that include different virtual machines.

A configuration also includes a core set of Java language classes. The core class libraries
defined for a configuration (and for profiles) are required to be based on those of the Java
2 platform. This promotes as much compatability as possible between applications
written for different J2ME platforms and those written with J2SE, and it also reduces the
learning curve for J2ME developers. Broadly speaking, this means that developers can
rely on the following: 

 Where possible, J2ME must reuse J2SE classes and packages. This means that,
for example, it would not be acceptable for a J2ME configuration or profile to
eschew the java.util.Date class and introduce one of its own.1 As a result,
everything that you know about J2SE can be carried forward to J2ME, provided
you know the exceptions that apply to the configuration and profiles you are
working with. That information is available in the reference section of this book.
 When a J2SE class is incorporated into J2ME, new methods and fields may not be
added to it. Similarly, new classes cannot be added to a coopted J2SE package.
These rules ensure that code written for J2ME that uses only those classes it
shares with J2SE will compile and work on J2SE, thus making it possible to share
code between these platforms

CLDC Profiles

There are two types of profiles

1. MIDP

2. IMP

Mobile Information Device Profile (MIDP)

This profile adds networking, user interface components, and local storage to CLDC.
This profile is primarily aimed at the limited display and storage facilities of mobile
phones, and it therefore provides a relatively simple user interface and basic networking
based on HTTP 1.1. MIDP is the best known of the J2ME profiles because it is the basis
for Wireless Java and is currently the only profile available for PalmOSbased handhelds.
Information Module Profile

The Information Module Profile is specified in JSR 195 and is designed for vending
machines, network cards, routers, telephone boxes and other systems with either simple
or no display and some form of limited two way network access. Only APIs for
application creation, storage, and network access are defined. These are a subset of the
javax.microedition.io, rms and midlet packages in MIDP. Siemens mobile and Nokia put
forward this specification to the JCP.

CDC Profiles

Foundation Profile

The Foundation Profile extends the CDC to include almost all of the core Java 2 Version
1.3 core libraries. As its name suggests, it is intended to be used as the basis for most of
the other CDC profiles.

Personal Basis and Personal Profiles

The Personal Basis Profile adds basic user interface functionality to the Foundation
Profile. It is intended to be used on devices that have an unsophisticated user interface
capability, and it therefore does not allow more than one window to be active at any time.
Platforms that can support a more complex user interface will use the Personal Profile
instead. At the time of writing, both these profiles are in the process of being specified.

RMI Profile

The RMI Profile adds the J2SE Remote Method Invocation libraries to the Foundation
Profile. Only the client side of this API is supported.
Game Profile

The Game Profile, which is still in the process of being defined, will provide a platform
for writing games software on CDC devices. At the time of writing, it is not certain
whether this profile will be derived from the Foundation Profile or based directly on
CDC.

Introduction to Midlets

What is MIDlet?

A MIDlet is a Java application framework for the Mobile Information Device Profile
(MIDP). MIDlet is a MID Profile application which is managed and controlled by the
Application Management Software (AMS) built in the device.
 
The application management software (AMS) is the software on a device that manages
the downloading and life-cycle of MIDlets. The AMS provides the runtime environment
for a MIDlet. It enforces security, permissions, and execution states, and provides system
classes and scheduling.

Just as J2SE applications have an entry point (any class with a main() method). MIDlets
javax.microedition.midlet.MIDlet class that offers the abstract startApp() method which
serves as the entry point to your MIDlet.

One should extend the abstract javax.microedition.midlet.MIDlet class or in other words

the MIDlet needs to be a subclass (derived) of (from) javax.microedition.midlet.MIDlet
class.
The javax.microedition.midlet.MIDlet class acts as an interface between the MIDlet
and the application management software.

Life-Cycle of MIDlet

Understanding the MIDlet life-cycle is fundamental to creating any MIDlet. The life-
cycle defines the execution states of a MIDlet:

There are three possible states in a MIDlet's life-cycle as shown in Figure 1:

•  Paused

•  Active

•  Destroy  

MIDlet has three life-cycle notification abstract methods related to MIDlet lifecycle:

• startApp()

• pauseApp()

• destroyApp(boolean unconditional)
Active State

/**
* startApp() method is called to change
* paused state to active state.
*/

protected void startApp() {

Display.getDisplay(this).setCurrent(helloForm);
}

Midlet's startApp() method is called to change the paused state to active state. Here the midlet is
displayed on Electronic Data Interface(EDI) screen of the mobile phone. The midlet is ready to
react to any user interaction as the midlet implements Command Listener Interface.
Paused State

/**
* The MIDlet frees as much resources as it can.
*/

protected void pauseApp() {}

When MIDlet's pauseApp() is called. The MIDlet frees as much resources as it can. startApp()
can be called after paused state and the application becomes active again.

Destroyed State

/**
* Midlet cleans up resources before the application exits.
*
*/

protected void destroyApp(boolean bool) {}

MIDlet.destroyApp() is used to do cleaning up before the application exits.

Hello World Application in Midlets using Netbeans

J2ME tutorial – How to create a simple MIDlet application with

NetBeans

The purpose of this tutorial is to present the basic elements needed for mobile Java
applications (MIDlets) development. The notions described will be sufficient to build a
simple application J2ME HelloWorld application.
Resources necessary for the project development are open-source and can be downloaded
from the Internet:

 visual development environment (IDE) that includes Java ME (Micro Edition), it

is not mandatory, because sources can be compiled from the command line; the
example described in this tutorial is created with NetBeans; this IDE, current
version 6.9.1, can be downloaded at http://www.netbeans.org/ and although there
are several distributions available select the one that contains Java ME
technology; the least complex visual development environment used for Java
mobile applications is included in Sun Java Java ME Software Development Kit
(http://java.sun.com/javame/sdk/index.jsp), Sun Java Wireless Toolkit for CLDC;
 emulators of mobile devices that support Java applications; such an emulator is
already integrated in the distribution of NetBeans; the simulated mobile device is
a generic one; if you want to test the application in a specific environment (for a
specific mobile device) you may use resources made available to by the
manufacturer; eg  for Nokia devices, a source for SDKs (Standard Development
Kit) of different generations and models is forum.nokia.com;

The first thing to do is to create a Java ME mobile application (MIDlet).

1. open NetBeans environment

2. choose File -> New Project
3. in Java ME category select a Mobile Application project type.
New J2ME Project in NetBeans

4.  define the location (and uncheck the Create Hello MIDlet)

5.  at the third step – Default Platform Selection, are defined next resources:

 used emulator; implicitly, if you installed just NetBeans, without any SDKs, is
available only Sun Java Wireless Toolkit 2.5.2 for CLDC;
 type of mobile device (color or monochrome screen, qwerty keyboard);
 configuration of the device, for this simple project select CLDC-1.0; CLDC or
Connected Limited Device Configuration is a standard that describes the
hardware features of your mobile device; version 1.0 of the standard describes a
device with 128 KB for Java virtual machine, 32 MB dynamic memory, visual
interface and limited ability to connect to a data network; this standard is defined
by a consortium, which includes major manufacturers of mobile devices, to help
software developers to establish the hardware limits of the device; also these
settings have an impact on how the project will be compiled;
  device profile; for this project select MIDP-2.0; MIDP or Mobile Information
Device Profile is an extension of the hardware configuration (CLDC) describing
the software characteristics of the device with reference to the available
frameworks and Java virtual machine;
 the chosen combination ( CLDC-1.0 MIDP-2.0) is valid for more than 75% of
mobile devices released after 2005 (in your mobile device specifications you can
find all of these).

Platform Selection for J2ME mobile application

Once the MobileApplication type project has been created we must define the context
based on which we will build the application. This means inserting a MIDlet type
resource using NetBeans menu options (File -> New File …) or through the context
menu (New -> MIDlet) activated with right-click on the project name.
By adding a MIDlet resource type, a file with the .java extension, it is generated the
MidletHelloWorld class, that is derived from MIDlet abstract class.

Initially, this class has the form:

import javax.microedition.midlet.*;
public class MidletHelloWorld extends MIDlet {
public void startApp() {
 }
 
public void pauseApp() {
}
 
public void destroyApp(boolean unconditional) {
}
}

and it overrides some abstract methods:

 startApp() – starter function of the application (entry point); it is the first

function to be executed, after the MidletHelloWorld instance has been created;
 pauseApp() – the function is executed at the occurrence of an event that involves
blocking the MIDlet application; a common scenario in a mobile device
application includes receiving a phone call during the execution of the
application;
 destroyApp() – function used to close the application; it is executed at the end of
the application and contains routines used to release resources; acts like a
destructor function;

The code sequence, from the above sample, is the smallest and simplest MIDlet program.
This program does not has any visual effects because it was finished immediately after it
is launched in execution.

If we think to an application written in C, the MIDlet MidletHelloWorld, in current form,

is equivalent to

void main ()
{
}

The three methods are required by the MidletHelloWorld class, because it is a a situation
generated by derivation from a MIDlet abstract class. They manage possible states in
which the application may be. This concept is also seen in other Java applications, like
applets.

To post a message on the screen, the application must have access to the graphics
resources controller’s. This is done by defining a Display object which is initialized at
the start of the application.

public class MidletHelloWorld extends MIDlet {

//reference to the application display manager
private Display display = null;
public void startApp() {
if(display==null)
display = Display.getDisplay(this);
}
 
public void pauseApp() {
}
 
public void destroyApp(boolean unconditional) {
}
}

Because the hardware and software characteristics of mobile device impose restrictions
on Java Mobile Applications (things are totally different from Java applications for PC),
we can only develop applications that display information within a single form (or
window) at a time.

Moreover, because the screen is small, this form covers all the device’s display. To
manage the visual resources and to establish what form is active we will use the Display
reference.

To display the on-screen text Hello World! we need a form and a container for that string.
Thus we use a TextBox type form (this is NOT the TextBox control from other
programming languages) which is a form containing only one dialog box control with a
default Multiline property (text is displayed by default on multiple lines). The reason for
the existence of this type of visual resource is given also by the limited resources we have
on a mobile device. Other forms types allow more complex applications, but they will be
described in another post.

By adding the TextBox form,the code becomes:

import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;
 
public class MidletHelloWorld extends MIDlet {
//reference to the application display manager
private Display display = null;
 
//TextBox use to print the Hello Word message
private TextBox tbMainForm;
 
public MidletHelloWorld(){
tbMainForm = new TextBox("My First MIDlet","Hello World !",100,0);
}
 
public void startApp() {
if(display==null)
display = Display.getDisplay(this);
//activate the form
display.setCurrent(tbMainForm);
}
 
public void pauseApp() {
}
 
public void destroyApp(boolean unconditional) {
}
}

In the previous code sequence, you may notice that the form display was realized in the
startApp method via the setCurrent function of the Display object.
Compiling and running the code we will obtain the next image in the emulator:

At the emulator start, it does not immediately execute the application. To start it you must
select the Launch button (bottom right of the emulator).

Hello World Midlet example

Although the application is quite simple, it illustrates very well the structure of a MIDlet,
and all these concepts are present in any other J2ME applications.

To test the mobile application in a real environment, your personal mobile phone, the
MIDlet from this example must be installed on your mobile device. This is done by
sending to the phone (by Bluetoth, IR, wireless or data cable) the two files that are in the
dist subdirectory of the project (this is applicable only for Netbeans). If the project is
called MobileApplicationHelloWorld, then the two files are
MobileApplicationHelloWorld.jad (description of the application) and
MobileApplicationHelloWorld.jar (application bytecode source ).

Manifest File

The table below lists all available attributes that may be defined within the manifest file.

Table 1
Attribute Purpose
MIDlet-Name Name of the MIDlet
MIDlet-Version Version number of the MIDlet
MIDlet-Vendor Who created the MIDlet
MIDlet-Icon Icon associated to show alongside the MIDlet-Name by the
application manager.
MIDlet-Description Text describing the MIDlet
MIDlet-Info-URL URL that may have more information about the MIDlet
and/or the vendor
MIDlet-<n> This attribute contains up to three pieces of information:
  • MIDlet name
  • Icon for this MIDlet (optional)
  • Class name the application manager will call to load this
MIDlet
MIDlet-Jar-URL URL of the JAR file
MIDlet-Jar-Size The JAR file size in bytes
MIDlet-Data-Size The minimum number of bytes required for persistent data
storage.
MicroEdition-Profile What J2ME Profile is required by the MIDlet
MicroEdition- What J2ME Configuration is required by the MIDlet.
Configuration