J.E.N.I.

Chapter 1
Mobile Application Development
1.1 Objectives
In this chapter, we will discuss the characteristics of mobile devices, and how it influence the
programming development for this device. We will be introduced to the Java 2 Mobile Edition
(J2ME), including the importance of configuration and profile.
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 has many types in terms of size, design and layout, but these have very
different characteristics from desktop systems.

Small in size
Mobile device has a small size. Consumers want the smallest device for their
convenience and mobility.

Limited memory
The mobile device also has a small memory, namely primary (RAM) and secondary
(disk). This restriction is one of the factors that influenced the programming for various
types of these devices. With restrictions on the amount of memory, special
considerations must be taken to maintain the use of this expensive resource

Limited processing power

A mobile system that is not as tough as their desktop counterparts. Size, technology and
costs are some of the factors that affect the status of these resources. For hard disk and
RAM, you can find them in sizes that fit with a small package.

Low power consumption

Pengembangan Perangkat Mobile

Mobile devices spend less power compared to a desktop machine. This device should
save power because they run on the circumstances in which limited power provided by
the batteries.

Robust and reliable

Because mobile devices are always brought anywhere, these must be strong enough to
face collisions, movements, and occasional droplets of water.

Limited connectivity
The mobile device has a low bandwidth, some of these are not even connected. Most of
them use a wireless connection.

Short wakeup time

These consumer devices start up in seconds, most of these are always on. Try to take
the case of a mobile phone, they boot in seconds, and most people do not turn off their
mobile phones even on evenings. PDA will light up if you press the power button.

1.3 J2ME Overview

1.3.1 JAVA Platform
Java was made in 1991 by James Gosling. Initially named Oak, in honor of the tree outside
Gosling's window. Later the name was changed to Java because there has been a language
named Oak.
The actual motivation of Java is the need for a language that can be used on a variety of
platforms that can be incorporated into a variety of electronic products such as toaster and
fridge. One of the first projects developed JAVA using a remote control that is named Star 7.
At the same time, the World Wide Web and the Internet is growing very fast. Gosling realize
that Java can be used for Internet programming.
With the release of version 1.2, the Java platform has been broken down into several editions:
The Standard Edition (J2SE), Enterprise Edition (J2EE), Mobile Edition (J2ME), and JavaCard API.

J2SE Java 2 Platform, Standard Edition

Desktop applications

J2EE Java 2 Platform, Enterprise Edition

Enterprise applications with a focus on

webserver side development, including
servlet, JSP, EJB, and XML

J2ME Java 2 Platform, Micro Edition

Mobile devices

JavaCard

Smart Cards

Servers

Optional
Packages

Desktop
machines

High-end
Low-end
consumer
consumer
devices
devices

Optional
Packages

Smart
Cards

J2EE

Personal Profile

J2SE
Foundation Profile

MIDP

CDC

CLDC

Java Virtual Machine

Java
Card

KVM

Card VM

Java 2 Micro Edition (J2ME)

Figure 1:

Java Platform

1.3.2 J2ME Overview

J2ME is a set of specifications and technologies that focus on consumer devices. This device has
a limited amount of memory, spend a little power from the battery, small screen and low
network bandwidth.
With the proliferation of mobile consumer devices from phones, PDAs, game box to home
appliances, Java provides an environment that is portable to develop and run applications on
this device.
J2ME program, like all programs are translated by JAVA VM. The program is compiled into
bytecode and Java Virtual Machine (JVM) translates it. This means that these programs are not
directly related to the device. J2ME provides an interface that corresponds to the device. These
applications do not have to be compiled again to be able to run on different machines.
Lies in the core of J2ME configuration and profiles. A configuration describes the basic runtime
environment of a system J2ME. It describes the core library, virtual machines, and network
security features.

Applications
Profile
Configuration

Optional
OEM
Packages
APIs
Libraries
{
Java Virtual Machine

Device Operating System

Figure 2:

J2ME Architecture

A profile provides additional libraries for a particular class at a device. Profiles provides a user
interface (UI) API, persistence, messaging library, etc.
A set of additional libraries or additional package provides the ability to add program. This
package entered into J2ME devices may vary as depending on the capabilities of a device. For
example, some devices MIDP does not have Bluetooth built-in, so the Bluetooth API is not
provided in this device.

1.3.3 Configuration
A minimal configuration describe the features of a complete Java runtime environment. To
ensure portability and interoperability on limited resources (restricted memory, processor,
connections) capabilities between different optimal kinds of devices, configuration describes no
additional features. The J2ME configuration describes a minimum complement of JAVA
technology. It is a profiles task to describe the additional libraries for a category of certain
devices.

Configuration illustrates:

the subset of the Java programming language

the functionality of the Java Virtual Machine (VM)

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) describes and refers to the following area:

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

This particular feature of J2SE, which moved from 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 might breach security. JNI
also require intensive memory so it is not possible to support the lower memory a mobile
device.

1.4.2 CLDC Device Characteristics

Devices targeted by CLDC has 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).

CLDC does not describe the installation and life cycle of an application, interface (UI) and event
handling (event handling). It is the mission profile which are under CLDC to describe this area.
In particular, the MIDP specification describes the cycle life MIDP application (MIDlet), UI library
and event handling (javax.microedition.lcdui. *).

1.4.3 Class Verification

CLDC specification requires all classes to pass the verification process at two levels. The first
verification conducted outside the device prior to the installation on the device. The second
verification occurred on the device during runtime and executed by the KVM.

File.java

Install

compile (javac)

verify
(runtime)

File. class

prev

erify

interpret

class
File.

Development Machine
Figure 3:

Target Device

Two Levels Process Verification

1.4.4 Generic Connection Framework

The Generic Connection Framework API provides the basis for the connection in the CLDC. This
framework provides a common foundation for connections such as HTTP, Socket, and
Datagrams. GCF provides a set of APIs that separates all common and ordinary types of
connection. It should be noted that not all types of connections needed to be implemented by
MIDP devices.
Interface hierarchies that can be expanded from GCF can make the leveling process. New type
of connection may be added to this framework to expand this hierarchy.

Connection

StreamConnectionNotifier

DatagramConnection

InputConnection

OutputConnection

StreamConnection

ContentConnection

Figure 4:

Hierarchy GCF
connection

1.5 CDC
Connected Device Configuration (CDC) is a super set of the CLDC. CDC provides Java runtime
environment that is broader than the CLDC and closer to J2SE environment.

CDC Java Virtual Machine (CVM) fully supports the Java Virtual Machine (JVM). CDC lists all of
the CLDC API. CDC provides a larger subset of all class J2SE.
For CLDC, CDC does not describe every class UI. UI Library is described by profiles under this
configuration.
All classes contained in the CDC comes from this package:

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 incorporated inside the GCF. CDC requires additional connection types such as file and
support datagram.

1.6 JTWI
The Java Technology for the Wireless Industry (JTWI) establishes a set of services and
specifications standard. Based on JTWI specification, the keyword is "to minimize fragmentation
API in mobile telephone market, and for predictable send specification, clear specification for the
manufacturers, operators and application developers."
With adjustments to JTWI, many applications will run in a broader set on the device. The device
will also make manufacturers better because a large application will be available for their
devices.

MIDlets
MIDP 2.0

WMA
1.1

MMAPI Optional
1.1
Packages

OEM
APIs

CLDC 1.0 or 1.1

Device Operating System

Figure 5:

JTWI Components

1.7 MIDP
The Mobile Information Device Profile (MIDP) was on top of the CLDC. You cannot write
mobile applications using only the CLDC API. You must keep utilize MIDP that defines the UI.
MIDP, CLDC specifications and such as most other APIs are already illustrated through Java
Community Process (JCP). JCP involves a group of experts from more than 50 Companies,
which consists of a mobile device manufacturer, software developer. MIDP continues to develop,
with future versions that have passed rigorous process JCP.

MIDP specification describes an MID device that has these minimum characteristics:

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)

Networking:

Two-way, wireless, possibly intermittent, with limited bandwidth

Sound:
The ability to play tones, either via dedicated hardware or via software algorithm.

MIDP application model describes, UI API, storage and strong networks, games and media APIs,
security policies, application deployment and provision of over-the- air.

1.8 MIDlet
An 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

MIDlet life begins when instantiated by the AMS. Originally signed MIDlet status "Pause" after
the newly created command. AMS call a public constructor with no arguments from MIDlet. If
an exception occurs in the constructor, the MIDlet enters the status "Destroyed" and dispose of
it immediately.

MIDlet into the status "Active" on the startup method call () by AMS.

MIDlet into the status of "Destroyed" when AMS destroyApp invoke (). This status also reaccessed when method notifyDestroyed () returned successfully to the application. Note that
the MIDlet can only enter the status of "Destroyed" once in their lifetime.

Pengembangan Perangkat Mobile

10

new
destroyApp()

startApp()

Paused
Destroyed
Active

pauseApp()

destroyApp()

Figure 6:

MIDlet Life Cycle

1.8.2 MIDlet suites

MIDlet applications are packaged and sent into the device as MIDlet suites. A MIDlet suite
consists of a Java Archive (JAR) and an additional Java Application Descriptor (JAD).
JAD file is a text file that contains a set of attributes, some are needed.

1.9 Exercises
1.9.1 What are the advantages of using Java as the development and
platform runtime for mobile devices??

Applications are very portable

Rich, illustrated by connecting to devices

Low memory usage (KVM)

Secure runtime environment

Dynamic applications

Pengembangan Perangkat Mobile

1
1

1.9.2 What motivated you to write programs for mobile device?

The challenge of optimizing writing applications

New learning experience

Pleasure factors