J.E.D.I.

Chapter 01
Mobile Application Development
1.1 Objectives
In this section, we will be discussing the characteristics of mobile devices and how they
affect program development for these devices. We will be introduced to the Java 2, Mobile
Edition (J2ME) Platform, including the importance of configurations and profiles.
At the end of the lesson, the student should be able to:
Identify the characteristics of mobile devices
Describe the J2ME architecture
Know the role of configurations and profiles
Identify the APIs provided by MIDP
Describe the MIDlet life cycle

1.2 Mobile Devices

Mobile devices may vary in size, design and layout, but they have some characteristics in
common that are totally different from desktop systems.
Small in size

Mobile devices are small in size. Consumers want smaller devices for mobility and
convenience.
Limited memory

Mobile devices also have small memory, both primary (RAM) and secondary (disk). This
limitation is one of the factors that affects writing programs for these types of devices.
Special considerations must be taken to conserve the use of this precious resource.
Limited processing power

Mobile systems are not as powerful as their desktop counterparts. Size, technology and
budget are some of the factors that affect the state of this resource. Like the disk storage
and RAM, you can only fit so much of these resources in such a small package.
Low power consumption

Mobile devices consume less power than desktop machines. These devices must conserve
the use of power because they run on a limited supply from batteries.

Mobile Application Development

J.E.D.I.

Robust and reliable

Because mobile devices are always carried along, they must be robust enough to stand
the force of bumps, motion and occasional drops.
Limited connectivity

Mobile devices have low bandwidth, some of them not connected at all. Most of them use
wireless connections.
Short wakeup time

These consumer devices startup in seconds and most of them are always on. Take the
case of mobile phones: they boot up within seconds and most people do not turn them off
even at night. PDAs wake up the second you press their power button.

1.3 J2ME Overview

1.3.1

Java Platform

Java was created in 1991 by James Gosling et. al. of Sun Microsystems. Initially called
Oak in honor of the tree outside Gosling's window, its name was changed to Java because
there was already a language called Oak.
The original motivation for Java was the need for platform independent language that
could be embedded in various consumer electronic products like toasters and refrigerators.
One of the first projects developed using Java was a personal hand-held remote control
named Star 7.
At about the same time, the World Wide Web and the Internet were gaining popularity.
Gosling et. al. realized that Java could be used for Internet programming.
With the release of version 1.2, the Java platform was classified into several editions:
the Standard Edition (J2SE), Enterprise Edition (J2EE), Mobile Edition (J2ME) and Java
Card API.

J2SE Java 2 Platform, Standard Edition

desktop applications

J2EE Java 2 Platform, Enterprise Edition

enterprise applications w/ focus on web

server-side development including servlets,
JSP, EJB and XML

J2ME Java 2 Platform, Micro Edition

mobile and handheld devices

JavaCard

Smart Cards

Mobile Application Development

J.E.D.I.

Figure 1: The Java Platform

1.3.2

J2ME Overview

The Java 2 Platform, Mobile Edition (J2ME) is a set of specifications and technologies that
focus on consumer devices. These devices have limited amount of memory, less processing
power, small screens and low network bandwidth.
With the proliferation of mobile consumer devices from phones, PDAs, and gaming boxes
to home appliances, Java provides a single portable environment for developing and
running applications on these devices.
J2ME programs, like all Java programs, are interpreted. Programs are compiled into byte
codes and interpreted by the Java Virtual Machine (VM). This means that programs do not
have to deal with the intricacies of the devices. J2ME provides a consistent interface with
the devices. Applications do not have to be recompiled to be able to run on different
machines.
At the core of J2ME lies the configuration and profiles. A configuration defines basic runtime

Mobile Application Development

J.E.D.I.

environment for a J2ME system. It defines the core libraries, the virtual machine, security
and networking features.

Figure 2: J2ME Architecture

A profile adds additional libraries for a certain class of devices. Profiles provide user
interface (UI) APIs, persistence and messaging libraries, among others.
A set of optional libraries or optional packages provide additional program functionality.
Inclusion of these packages in a J2ME device may vary depending on the capabilities of
the device. For example, some MIDP devices do not have built-in Bluetooth, so the
Bluetooth APIs are not included in these devices.

1.3.3

Configuration

A configuration defines the minimal features of a complete Java runtime environment. To

guarantee optimal portability and interoperability between various kinds of resourceconstrained devices (memory, processor, connection constrained), configurations do not
define optional features. A J2ME configuration defines a minimum complement of Java
technology. It is up to the profiles to define additional (possibly optional) libraries for a
certain device category.
A configuration defines:
the subset of the Java programming language
the functionality of the Java Virtual Machine (VM)

Mobile Application Development

J.E.D.I.

core platform libraries

security and networking features

1.3.4

Profiles

A profile defines additional sets of APIs and features for a particular market, device
category or industry. While a configuration defines the base libraries, profiles define the
libraries that are important to make effective applications. These libraries include the user
interface, networking, and storage APIs.

1.4 CLDC
The Connected Limited Device Configuration (CLDC) defines and addresses the following
areas:
Java language and Virtual Machine (VM) features
Core libraries (java.lang.*, java.util.*)
Input/Output (java.io.*)
Security
Networking
Internationalization

1.4.1

Missing features

Features from the J2SE that had been removed from the CLDC are:
finalization of class instances
asynchronous exceptions
some error classes
user-defined class loaders
reflection
Java Native Interface (JNI)
thread groups and daemon threads

Reflection, Java Native Interface (JNI), and user-defined class loaders are
potential security holes. JNI is also memory intensive and might not be
supported by the low memory of mobile devices.

Mobile Application Development

J.E.D.I.

1.4.2

CLDC Device Characteristics

The devices targeted by the CLDC have the following characteristics:

at least 192kb of memory for Java platform (160kb non-volatile memory for
VM and libraries and 32kb volatile memory for VM runtime)
16 or 32 bit processor
low power consumption (usually battery powered)
limited, intermittent network connection with limited bandwidth (usually
wireless)

The CLDC does not define application installation and life-cycle, user interfaces and event
handling. It is up to the profiles under CLDC to define these areas. In particular, the MIDP
specification defines the MIDP application (MIDlet) life-cycle, the UI library, and event
handling (javax.microedition.lcdui.*).

1.4.3

Class Verification

The CLDC specification requires that all classes pass a two-phase verification process. The
first verification (preverification) is done off-device prior to installation on the device. The
second verification occurs on-device during runtime and is performed by the KVM.

Mobile Application Development

J.E.D.I.

Figure 3: Two-phase Verification Process

1.4.4

The Generic Connection Framework

The Generic Connection Framework provides the basic API for connections in CLDC. This
framework provides a common foundation for connections like HTTP, Sockets, and
Datagrams. The GCF provides a generic and common set of API that abstracts all types of
connections. It should be noted that not all connection types are required to be
implemented by the MIDP devices.
The extensible interface hierarchy of the GCF makes generalization possible. New
connection types may be added into this framework by extending this hierarchy.

Mobile Application Development

J.E.D.I.

Figure 4: The GCF Connection Hierarchy

1.5 CDC
The Connected Device Configuration (CDC) is a superset of the CLDC. It provides a broader
Java runtime environment than the CLDC and is a closer match to the J2SE environment.
The CDC Java Virtual Machine (or the CVM) is a full-featured Java Virtual Machine (VM).
The CDC contains all the API from the CLDC. It provides a larger subset of the J2SE classes.
Like the CLDC, the CDC does not define any user interface (UI) classes. The UI libraries
are defined by the profiles under this configuration.

Mobile Application Development

J.E.D.I.

The classes included in the CDC come from the following packages:

java.io
java.lang
java.lang.ref
java.lang.math
java.net
java.security
java.security.cert
java.text
java.util
java.util.jar
java.util.zip

CDC also includes the Generic Connection Framework. This requires additional connection
types like file and datagram support.

1.6 JWTI
The Java Technology for the Wireless Industry (JWTI) specifies a set of services and
standard specifications. According to the JWTI specification, its key goal is "to minimize
API fragmentation in the mobile phone device market, and to deliver a predictable, clear
specification for device manufacturers, operators, and application developers."
By conforming to the JWTI, applications will run on a wider set of devices. Device
manufacturers will also benefit because of a larger set of applications that will be available
for their devices.

Mobile Application Development

J.E.D.I.

Figure 5: JWTI Components

1.7 MIDP
The Mobile Information Device Profile (MIDP) builds on top of the CLDC. No useful mobile
applications can be written by just using the CLDC APIs. It is in MIDP that user interface
APIs are defined.
The MIDP specification, much like the CLDC and other APIs, has been defined through the
Java Community Process (JCP). It involved an expert group from more than 50 companies
composed of mobile device manufacturers, carriers, and software developers. MIDP is
continually evolving, with future versions going through the same rigorous process (JCP).
Future versions of MIDP are expected to be backward compatible, as is the case with
MIDP1 and MIDP 2.0.
The MIDP specification defines a MID device to have these characteristics as a minimum:
Display:
Screen-size: 96x54
Display depth: 1-bit
Pixel aspect ratio: approximately 1:1
Input:
One or more of the following user-input mechanisms: one-handed keyboard,

two-handed keyboard, or touch screen

Memory:
256 kilobytes of non-volatile memory for the MIDP implementation, beyond

what's required for CLDC.

8 kilobytes of non-volatile memory for application-created persistent data

128 kilobytes of volatile memory for the Java runtime (e.g., the Java heap)

Mobile Application Development

10

J.E.D.I.

Networking:
Two-way, wireless, possibly intermittent, with limited bandwidth
Sound:
The ability to play tones, either via dedicated hardware, or via software

algorithm.

MIDP defines the application model, user interface API, persistent storage and networking,
gaming and media API, security policies, application deployment, and over-the-air
provisioning.

1.8 MIDlet
A MIDP application is called a MIDlet. The device's application management software
(AMS) interacts directly with the MIDlet with the MIDlet's create, start, pause, and destroy
methods.
The MIDlet is part of the javax.microedition.midlet package. A MIDlet must extend the
MIDlet class. It can request parameters from the AMS as defined in the application
descriptor (JAD).
A MIDlet does not have (and MUST NOT have) a public static void main(String[] argv)
method. It will not be recognized by the AMS as the program's starting point.

1.8.1

MIDlet Life Cycle

A MIDlet's life begins when it is instantiated by the AMS. It initially enters the "Paused"
state after being created with the new command. The AMS calls the "public no argument"
constructor of the MIDlet. If an exception occurs at the constructor, the MIDlet is put into
a "Destroyed" state and discarded immediately.
The MIDlet enters the "Active" state upon calling the startUp() method by the AMS.
The MIDlet enters the "Destroyed" state when the AMS calls the destroyApp() method.
This state is also entered when the notifyDestroyed() method returns succesfully to the
application. Take note that the MIDlet enters the "Destroyed" state only once in its lifetime.

Mobile Application Development

11

J.E.D.I.

Figure 6: MIDlet Life Cycle

1.8.2

MIDlet Suites

MIDP applications are packaged and delivered into devices as MIDlet suites. A MIDlet suite
consists of a Java Archive (JAR) and an optional Java Application Descriptor (JAD).
A JAD file is a text file containing a set of attributes, some of which are required.

1.9 Exercises
1.9.1

What are the advantages of using Java as a

development and runtime platform for mobile
devices?

highly portable applications

rich, well defined interfaces to the device
low memory footprint (KVM)

Mobile Application Development

12

J.E.D.I.

secure runtime environment

dynamic applications (can download applications to a device)

1.9.2

What would motivate you to write programs for

mobile devices?

the challenge of writing optimized applications

new learning experience
fun factor

Mobile Application Development

13