Académique Documents
Professionnel Documents
Culture Documents
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
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.
J.E.D.I.
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.
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.
desktop applications
JavaCard
Smart Cards
J.E.D.I.
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
J.E.D.I.
environment for a J2ME system. It defines the core libraries, the virtual machine, security
and networking features.
1.3.3
Configuration
J.E.D.I.
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.
J.E.D.I.
1.4.2
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.
J.E.D.I.
1.4.4
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.
J.E.D.I.
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.
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.
J.E.D.I.
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,
Memory:
256 kilobytes of non-volatile memory for the MIDP implementation, beyond
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
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.
11
J.E.D.I.
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
12
J.E.D.I.
1.9.2
13