J2ME

Explanation of J2ME:

1. Short for Java 2 Platform Micro Edition. J2ME is Sun

Microsystems' answer to a consumer wireless device platform.
J2ME allows developers to use Java and the J2ME wireless toolkit
to create applications and programs for wireless and mobile
devices.
2. (Java 2 Platform, Micro Edition) A version of Java 2 for cell
phones, PDAs and consumer appliances. J2ME uses the K Virtual
Machine (KVM), a specialized Java interpreter for devices with
limited memory. The Connected Limited Device Configuration
(CLDC) provides the programming interface for wireless
applications. The Mobile Information Device Profile (MIDP)
provides support for a graphical interface, networking and storage.

3. J2ME stands for 'Java 2 Platform, Micro Edition' and it stripped-

down version of the popular Java programming language designed
to work on mobile phones.

J2ME - now officially known as 'Java Platform, Micro Edition', or

just 'Java ME' - allows mobile phones to run basic applications
such as 2D games or simple web browsers. These apps are also
known as 'MIDlets'. The J2ME language was developed by Sun
Microsystems.

J2ME applications can be downloaded and installed onto your

phone from a variety of download sites, such as [Link]
 At last count, there are more than 2 billion J2ME-enabled mobile
phones and devices in circulation globally.

In 2005, Sun renamed J2ME to Java ME.

J2ME consists of two elements

1. Configurations
(A.) 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.
(B.) Connected Limited Device Configuration

The CLDC contains a strict subset of the Java

class libraries, and is the minimal needed for a
Java virtual machine to operate.

(C.) Connected Device Configuration

CDC is a larger subset of J2SE, containing almost
all the libraries that are not GUI related.
(D.) Personal, mobile information devices
that are capable of intermittent networked
communications—mobile phones, two-way
pagers, personal digital
assistants (PDAs), and organizers
supported by the Connected,
Limited Device Configuration (CLDC)

(E.) Shared-connection information devices

(F.) connected by fixed, uninterrupted
(G.) network connection—set-top boxes, Internet TVs,
Internet-enabled screen phones, high-end
communicators, and car entertainment/navigation
systems
 (H.) supported by the Connected Device
(I.) Configuration (CDC)

2. Profiles

(A.) Profiles are APIs built on top of configurations to

provide a runtime environment for a specific device,
such as a PDA, cell phone, or set-top box. The profile
manages the application, user interface, networking and
I/O.

In order to support Java apps, manufacturers need to

implement a profile for their specific devices.

(B.) Mobile Information Device Profile

Designed for cell phones, MIDP boasts an LCD-

oriented GUI API, and MIDP 2.0 includes a basic
2D gaming API. Applications written for this
profile are called MIDlets. Almost all new cell
phones come with a MIDP implementation, and it
is now the de facto standard for downloadable cell
phone games.

Information Module Profile

The Information Module Profile (IMP) is a J2ME

profile for embedded, "headless" devices such as
vending machines, industrial embedded
applications, security systems, and similar devices
with either simple or no display and with some
limited network connectivity.
Originally introduced by Siemens Mobile and
Nokia as JSR-195, IMP 1.0 is a strict subset of
MIDP 1.0 except that it doesn't include user
interface APIs — in other words, it doesn't
include support for the Java package
[Link]. JSR-228,
also known as IMP-NG, is IMP's next generation
that is based on MIDP 2.0, leveraging MIDP 2.0's
new security and networking types and APIs, and
other APIs such as PushRegistry and
platformRequest(), but again it doesn't
include UI APIs, nor the game API.

IMP applications are called IMlets, but in reality

they are MIDlets. They subclass MIDlet, and
follow the same packaging, deployment, security
and life-cycle as MIDlets.

Foundation Profile

A headless version of J2SE.

Personal Basis Profile

Extends the Foundation Profile to include

lightweight GUI support in the form of an AWT
subset.

Personal Profile

This extension of Personal Basis Profile includes

a more comprehensive AWT subset and adds
applet support.
(C.) Foundation Profile

A headless version of J2SE.

Personal Basis Profile

Extends the Foundation Profile to include

lightweight GUI support in the form of an
AWT subset.

Personal Profile

This extension of Personal Basis Profile

includes a more comprehensive AWT subset
and adds applet support.
 

The creators of the J2ME platform delineated pervasive devices into two
distinct
categories:
•

Defining a Java Platform for Pervasive Devices

Configurations and profiles are the main elements that comprise J2ME’s
modular design. These two elements enable support for the plethora of
devices that J2ME supports.

JAVA PPLICATION

PROFILE

CONFIGURATION :
LIBRARIES :
JVM
HOST OPERATING SYSTEM

DEVICE
HARDWARE
The J2ME platform consists of a set of layers that
support a basic runtime environment with core Java libraries
and a Virtual Machine (VM), a set of system-level application
programming interfaces (APIs) in a configuration, and a set of

application-level APIs in a profile.

The Connected Device Configuration (CDC)

The Connected Device Configuration (CDC) intends to capture just the
essential capabilities of each kind of device in the category of devices it
targets, namely,devices with 2 MB or more of total memory, including
both RAM and ROM. As you saw in Figure 1.1, a configuration
specifies both the set of Java VM features that are supported and a set of
class libraries. The CDC specifies the use of the full Java 2 platform
VM, which, in this context, is called the Compact Virtual Machine
(CVM).
The CVM.
Although the CVM supports the same features as the J2SE VM, it
is designed for consumer and embedded devices. This means that the
standard J2SE VM has been reengineered to suit the constraints of
limited-resource devices.
The features of the resulting offspring CVM are:
• advanced memory system
• small average garbage collection pause times
• full separation of VM from memory system
• modularized garbage collectors
• generational garbage collection
In particular, the CVM has been engineered to offer the following
features:
• portability
• fast synchronization
• execution of Java classes out of read-only memory (ROM)
• native thread support
• small class footprint
• provision of interfaces to and support for real-time operating system
(RTOS)
services
• mapping Java threads directly to native threads
• support for all Java 2, v1.3 VM features and libraries: security, weak
references,
Java Native Interface (JNI), Remote Method Invocation (RMI), Java
Virtual

Machine Debugging Interface (JVMDI)

CDC Package Name Description

[Link]
Standard IO classes and interfaces
[Link]
VM classes
[Link]
Reference classes
[Link]
Reflection classes and interfaces
[Link]
Math package
[Link]
Networking classes and interfaces
[Link]
Security classes and interfaces
[Link]
Security certificate classes
[Link]
Text package
[Link]
Standard utility classes
[Link]
Java Archive (JAR) utility classes
[Link]
ZIP utility classes
[Link]
CDC generic connection framework classes and Interfaces

The Foundation Profile

From the programmer’s perspective, a profile is required to do “useful”

work. A profile defines the layer that contains the APIs that the
programmer usually manipulates.
Connected, Limited Device Configuration (CLDC)
The second of the two J2ME configurations, the Connected, Limited
Device Configuration (CLDC), supports personal, mobile devices,
which constitute a significantly less powerful class of devices than the
one that the CDC supports. The CLDC specification identifies devices in
this category as having the following
characteristics:
• 160 to 512 KB total memory available for the Java platform
• 16-bit or 32-bit processor

• low power consumption, often battery powered

• intermittent network connectivity (often wireless) with potentially

limited Bandwidth

J2SE
CDC
CLDC (can not use java.*
namespace)
The CLDC is a proper subset of the CDC. Neither
the CLDC nor the CDC is a proper subset of the J2SE platform,
however, because both of these configurations add new classes
necessary to deliver services on their respective families of devices.

Java Language Support. The CLDC specification omits support for the
Following features of the Java language:
• floating point calculations
• object finalization
• the [Link] class hierarchy in its entirety

The lack of floating point support is the main language-level difference

between a Java virtual machine that supports CLDC and a standard J2SE
VM that is visible to programmers. This means that programs intended
to run on the CLDC cannot use floating point literals, types, or values.
You can’t use the float built-in type, and the [Link] class has
been removed from CLDC libraries. This feature is not present because
of the lack of floating-point hardware or software on most mobile
devices Object finalization is also absent. This means that the
[Link]()method has been removed from the CLDC [Link]
[Link] exception hierarchy has also been removed from the
CLDC libraries and is therefore not available to applications. The
primary reason that error handling is absent is memory constraints on
mobile devices. This typically doesn’t create any disadvantages for
applications development; after all, applications are not supposed to
recover from error conditions. And the resource cost of implementing
error handling is expensive, beyond the capabilities of today’s mobile
devices. Moreover, error recovery is device-specific on embedded
devices like mobile phones. In consequence, it doesn’t make sense to
stipulate the recovery mechanism that devices should use. This
mechanism may well be outside the scope of an embedded VM.

Java Virtual Machine and Library Support. The CLDC specifies

requirements for a Java virtual machine. It defines a VM that is highly
portable and designed for resource-constrained small devices. Support
for several features that exist in a standard J2SE VM have been omitted
from the CLDC specification. The following list describes the features
that are not supported in a CLDC-compliant VM. The features in this list
have been omitted because of either changes to libraries or security
concerns:
• Java Native Interface (JNI)
• user-defined class loaders
• reflection
• thread groups and thread daemons
• finalization (no [Link]() method in CLDC libraries)
• weak references
• errors (a small subset of J2SE errors is supported)
• class file verification

Among these unsupported features, class file verification deserves

further [Link] VM in the CLDC specification still performs this
process, but it uses a two-step process and a different algorithm that
requires fewer computation resources than the standard J2SE verifier. In
addition, there is a new preverification tool, which you will learn about
in chapter 2.
The VM that comes with the CLDC reference implementation is called
the Kilobyte Virtual Machine (KVM), so named because it uses only a
few KB of runtime memory. It is a reference implementation that
adheres to the CLDC specification’s description of a compliant VM. The
KVM is not a full-featured J2SE [Link] specification of the features
that a VM supports includes a specification of the libraries that it
supports. The CLDC specification details the libraries that an
implementation must support.
As you know, a configuration is the basis for one or more profiles. The
CLDC is a configuration on top of which one or more profiles are to be
built in the same way that the Foundation Profile is built on top of the
CDC. The intention is that the APIs in the CLDC profile support
application development for the mass market of personal devices. The
CLDC therefore targets third-party application [Link] is
somewhat different than the CDC, which targets OEM developers.
The first three packages use the java. prefix in their name because each
one contains a subset of the standard J2SE platform classes. The last
one, however, must use the javax. prefix because it defines a new
“standard extension” that is not part of the core Java platform.
CLDC Package Name Description
[Link] Standard Java IO classes and packages; subset of the J2SE
package
[Link] VM classes and interfaces; subset of the J2SE package
[Link] Standard utility classes and interfaces; subset of the J2SE
package
[Link] CLDC generic connection framework classes and
interfaces
Mobile Information Device Profile.
Because the category served by the CLDC encompasses so many
different types of personal devices, potentially many different profiles
are necessary to support them all. The most popular and well known of
these is the Mobile Information Device Profile (MIDP), sometimes
called the MID Profile. The MIDP layers atop the CLDC and defines a
set of user interface (UI) APIs designed for contemporary wireless
devices.
Following in the tradition of Java parlance, MIDP applications are called
MIDlets.
A MIDlet is a Java application that uses the MIDP profile and the CLDC
[Link] book concentrates on teaching you how to write
MIDlets, because the vast majority of J2ME programmers will
encounter the CLDC/MIDP platform far more often than other J2ME
platforms. And, from a practical standpoint, the MIDP is the only profile
currently [Link] MIDP specification, like the CDC’s Foundation
Profile, was produced by an expert group, in this case, the Mobile
Information Device Profile Expert Group,which is an international
forum that includes representatives from several companies in the
mobile device arena. The MIDP targets mobile information devices
(MIDs), such as mobile phones, two-way pagers, and so forth, which
have roughly the following characteristics:
• screen size of approximately (at least) 96x54 pixels
• display depth of 1 bit
Table 1.4 CLDC Packages
CLDC Package Name Description
[Link] Standard Java IO classes and packages; subset of the
J2SE package
[Link] VM classes and interfaces; subset of the J2SE package
[Link] Standard utility classes and interfaces; subset of the J2SE
package
[Link] CLDC generic connection framework classes and
interfaces
Another profile, the PDA Profile, is currently in its definition stage.
PDAs also belong
to the general category of mobile information devices. The PDA
profile
might never be implemented, however, because it’s questionable
whether it offers
enough differences and enhancements to the MIDP specification to
warrant
its development. The PDA Profile also poses portability challenges
for developers.

Because the range of MID capabilities is so broad, the MIDP established

a goal to address the least common denominator of device capabilities.
The MIDP, therefore,
specifies the following APIs:
• application (MIDP application semantics and control)
• user interface
• persistent storage
• networking
• timers

MIDP Package Name Description

[Link] UI classes and interfaces
[Link] Record management system (RMS) supporting
persistent device storage
[Link] MIDP application definition support class
types
[Link] MIDP generic connection framework classes and
interfaces
[Link] Standard Java IO classes and interfaces
[Link] VM classes and interfaces
[Link] Standard utility classes and interfaces
Device Application Management Systems
All J2ME applications—MIDlets and others—are real Java applications
that run under the control of a Java VM. But what controls the Java VM,
for instance on a mobile phone? There’s no command shell from which
you can invoke your favorite
Java applications like you do on your workstation. Starting, stopping,
and managing the execution of J2ME applications is controlled by
application management software (AMS) that resides on the device. In
fact, the AMS controls the entire
application lifecycle, from installation, upgrade and version
management, to
removal of application software.
The device manufacturer typically provides the AMS software. This is
the most
logical scenario because AMS software must work in conjunction with
the
device’s native system software, which, presumably, the manufacturer
knows
best. Nevertheless, third parties can also develop AMS systems for
specific
devices. AMS software could be written, for example, in Java or in some
native
language such as C.

APPLICATION
FOUNDATION
PROFILE or MIDP
CDC or CLDC
HOST OPERATING
SYSTEM
DEVICE HARDWARE

Figure 1.3 The CDC targets fixed-connection, shared, stationary

devices. The CLDC targets personal, mobile, limited-connection
devices.
J2ME Glossary

Java 2 Platform, Micro or Mobile Edition) is a technology that allows programmers to use the
Java programming language and related tools to develop programs for mobile wireless
information devices such as cellular phones and personal digital assistants (PDAs). J2ME
consists of programming specifications and a special virtual machine, the K Virtual Machine,
that allows a J2ME-encoded program to run in the mobile [Link]

3G Third generation (3G) wireless networks will offer faster data transfer rates
than current networks. The first generation of wireless (1G) was analog
cellular. The second generation (2G) is digital cellular, featuring integrated
voice and data communications. So-called 2.5G networks offer incremental
speed increases. 3G networks will offer dramatically improved data transfer
rates, enabling new wireless applications such as streaming media.
3GPP The 3rd Generation Partnership Project (3GPP) is a global collaboration
between 6 partners: ARIB, CWTS, ETSI, T1, TTA, and TTC. The group aims
to develop a globally accepted 3rd-generation mobile system based on GSM.
802.11 802.11 is a group of specifications for wireless networks developed by the
Institute of Electrical and Electronics Engineers (IEEE). 802.11 uses the
 Ethernet protocol and CSMA/CA (carrier sense multiple access with collision
avoidance) for path sharing.
API An Application Programming Interface (API) is a set of classes that you can
use in your own application. Sometimes called libraries or modules, APIs
enable you to write an application without reinventing common pieces of code.
For example, a networking API is something your application can use to make
network connections, without your ever having to understand the underlying
code.
AMPS Advanced Mobile Phone Service (AMPS) is a first-generation analog, circuit-
switched cellular phone network. Originally operating in the 800 MHz band,
service was later expanded to include transmissions in the 1900 MHz band, the
VHF range in which most wireless carriers operate. Because AMPS uses
analog signals, it cannot transmit digital signals and cannot transport data
packets without assistance from newer technologies such as TDMA and
CDMA.
CDC The Connected Device Configuration (CDC) is a specification for a J2ME
configuration. Conceptually, CDC deals with devices with more memory and
processing power than CLDC; it is for devices with an always-on network
connection and a minimum of 2 MB of memory available for the Java system.
CDMA Code-Division Multiple Access (CDMA) is a cellular technology widely used
in North America. There are currently three CDMA standards: CDMA One,
CDMA2000 and W-CDMA. CDMA technology uses UHF 800Mhz-1.9Ghz
frequencies and bandwidth ranges from 115Kbs to 2Mbps.
CDMA One Also know as IS-95, CDMAOne is a 2nd generation wireless technology.
Supports speeds from 14.4Kbps to 115K bps.
CDMA2000 Also known as IS-136, CDMA2000 is a 3rd generation wireless technology.
Supports speeds ranging from 144Kbps to 2Mbps.
CDPD Developed by Nortel Networks, Cellular Digital Packet Data (CDPD) is an
open standard for supporting wireless Internet access from cellular devices.
CDPD also supports Multicast, which allows content providers to efficiently
broadcast information to many devices at the same time.
cHTML Compact HTML (cHTML) is a subset of HTML which is designed for small
devices. The major features of HTML that are excluded from cHTML are:
JPEG image, Table, Image map, Multiple character fonts and styles,
Background color and image, Frame and Style sheet.
CLDC The Connected, Limited Device Configuration (CLDC) is a specification for a
J2ME configuration. The CLDC is for devices with less than 512 KB or RAM
available for the Java system and an intermittent (limited) network connection.
It specifies a stripped-down Java virtual machine1 called the KVM as well as
several APIs for fundamental application services. Three packages are
minimalist versions of the J2SE [Link], [Link], and [Link]
packages. A fourth package, [Link], implements the
 Generic Connection Framework, a generalized API for making network
connections.
configuratio In J2ME, a configuration defines the minimum Java runtime environment for a
n family of devices: the combination of a Java virtual machine (either the
standard J2SE virtual machine or a much more limited version called the
CLDC VM) and a core set of APIs. CDC and CLDC are configurations. See
also profile, optional package.
CVM The Compact Virtual Machine (CVM) is an optimized Java virtual machine1
(JVM) that is used by the CDC.
Deck A deck is a collection of one or more WML cards that can be downloaded, to a
mobile phone, as a single entity.
EDGE Enhanced Data GSM Environment (EDGE) is a new, faster version of GSM.
EDGE is designed to support transfer rates up to 384Kbps and enable the
delivery of video and other high-bandwidth applications. EDGE is the result of
a joint effort between TDMA operators, vendors and carriers and the GSM
Alliance.
ETSI The European Telecommunications Standards Institute (ETSI) is a non-profit
organization that establishes telecommunications standards for Europe.
FDMA Frequency-division multiple-access (FDMA) is a mechanism for sharing a
radio frequency band among multiple users by dividing it into a number of
smaller bands.
Foundation The Foundation Profile is a J2ME profile specification that builds on CDC. It
Profile adds additional classes and interfaces to the CDC APIs but does not go so far as
to specify user interface APIs, persistent storage, or application life cycle.
Other J2ME profiles build on the CDC/Foundation combination: for example,
the Personal Profile and the RMI Profile both build on the Foundation Profile.
Generic The Generic Connection Framework (GCF) makes it easy for wireless devices
Connection to make network connections. It is part of CLDC and CDC and resides in the
Framework [Link] package.
GPRS The General Packet Radio System (GPRS) is the next generation of GSM. It
will be the basis of 3G networks in Europe and elsewhere.
GSM The Global System for Mobile Communications (GSM) is a wireless network
system that is widely used in Europe, Asia, and Australia. GSM is used at three
different frequencies: GSM900 and GSM1800 are used in Europe, Asia, and
Australia, while GSM1900 is deployed in North America and other parts of the
world.
HLR The Home Location Register (HLR) is a database for permanent storage of
subscriber data and service profiles.
HTTPS Hyper Text Transfer Protocol Secure sockets (HTTPS) is a protocol for
transmission of encrypted hypertext over Secure Sockets Layer.
i-appli Sometimes called "Java for i-mode", i-appli is a Java environment based on
 CLDC. It is used on handsets in NTT DoCoMo's i-mode service. While i-appli
is similar to MIDP, it was developed before the MIDP specification was
finished and the two APIs are incompatible.
IDE An Integrated Development Environment (IDE) provides a programming
environment as a single application. IDEs typically bundle a compiler,
debugger, and GUI builder tog ether. Forte for Java is Sun's Java IDE.
iDEN The Integrated Dispatch Enhanced Network (iDEN) is a wireless network
system developed by Motorola. Various carriers support iDEN networks
around the world: Nextel is one of the largest carriers, with networks covering
North and South America.
i-mode A standard used by Japanese wireless devices to access cHTML (compact
HTML) Web sites and display animated GIFs and other multimedia content.
J2ME Java 2, Micro Edition is a group of specifications and technologies that pertain
to Java on small devices. The J2ME moniker covers a wide range of devices,
from pagers and mobile telephones through set-top boxes and car navigation
systems. The J2ME world is divided into configurations and profiles,
specifications that describe a Java environment for a specific class of device.
J2ME WTK The J2ME Wireless Toolkit is a set of tools that provides developers with an
emulation environment, documentation and examples for developing Java
applications for small devices. The J2ME WTK is based on the Connected
Limited Device Configuration (CLDC) and Mobile Information Device Profile
(MIDP) reference implementations, and can be tightly integrated with Forte for
Java
Java Card The Java Card specification allows Java technology to run on smart cards and
other small devices. The Java Card API is compatible with formal international
standards, such as, ISO7816, and industry-specific standards, such as,
Europay/Master Card/Visa (EMV).
JavaHQ JavaHQ is the Java platform control center on your Palm OS device.
JCP The Java Community Process (JCP) an open organization of international Java
developers and licensees who develop and revise Java technology
specifications, reference implementations, and technology compatibility kits
through a formal process.
JDBC for The JDBC Optional Package for CDC/Foundation Profile (JDBCOP for
CDC/FP CDC/FP) is an API that enables mobile Java applications to communicate with
relational database servers using a subset of J2SE's Java Database
Connectivity. This optional package is a strict subset of JDBC 3.0 that excludes
some of JDBC's advanced and server-oriented features, such as pooled
connections and array types. It's meant for use with the Foundation Profile or
its supersets.
JSR Java Specification Request (JSR) is the actual description of proposed and final
specifications for the Java platform. JSRs are reviewed by the JCP and the
public before a final release of a specification is made.
KittyHawk KittyHawk is a set of APIs used by LG Telecom on its IBook and p520
devices. KittyHawk is based on CLDC. It is conceptually similar to MIDP but
the two APIs are incompatible.
KJava KJava is an outdated term for J2ME. It comes from an early package of Java
software for PalmOS, released at the 2000 JavaOne show. The classes for that
release were packaged in the [Link] package.
kSOAP kSOAP is a SOAP API suitable for the J2ME, based on kXML.
kXML The kXML project provides a small footprint XML parser that can be used with
J2ME.
KVM The KVM is a compact Java virtual machine (JVM) that is designed for small
devices. It supports a subset of the features of the JVM. For example, the KVM
does not support floating-point operations and object finalization. The CLDC
specifies use of the KVM. According to folklore, the 'K' in KVM stands for
kilobyte, signifying that the KVM runs in kilobytes of memory as opposed to
megabytes.
LAN A Local Area Network (LAN) is a group of devices connected with various
communications technologies in a small geographic area. Ethernet is the most
widely-used LAN technology. Communication on a LAN can either be with
Peer-to-Peer devices or Client-Server devices.
LCDUI LCDUI is a shorthand way of referring to the MIDP user interface APIs,
contained in the [Link] package. Strictly speaking,
LCDUI stands for Liquid Crystal Display User Interface. It's a user interface
toolkit for small device screens which are commonly LCD screens.
MExE The Mobile Execution Environment (MExE) is a specification created by the
3GPP which details an applicatio n environment for next generation mobile
devices. MExE consists of a variety of technologies including WAP, J2ME,
CLDC and MIDP.
MIDlet A MIDlet is an application written for MIDP. MIDlet applications are
subclasses of the [Link] class that is defined
by MIDP.
MIDlet MIDlets are packaged and distributed as MIDlet suites. A MIDlet suite can
suite contain one or more MIDlets. The MIDlet suite consists of two files, an
application descriptor file with a .jad extension and an archive file with a .jar
file. The descriptor lists the archive file name, the names and class names for
each MIDlet in the suite, and other information. The archive file contains the
MIDlet classes and resource files.
MIDP The Mobile Information Device Profile (MIDP) is a specification for a J2ME
profile. It is layered on top of CLDC and adds APIs for application life cycle,
user interface, networking, and persistent storage.
MIDP-NG The Next Generation MIDP specification is currently under development by
the Java Community Process. Planned improvements include XML parsing and
 cryptographic support.
Mobitex Mobitex is a packet-switched, narrowband PCS network, designed for wide-
area wireless data communications. It was developed in 1984 by Eritel, an
Ericsson subsidiary, a nd there are now over 30 Mobitex networks in operation
worldwide.
Modulation Modulation is the method by which a high-frequency digital signal is grafted
onto a lower-frequency analog wave, so that digital packets are able to ride
piggyback on the analog airwave.
MSC A Mobile Switching Center (MSC) is a unit within a cellular phone network
that automatically coordinates and switches calls in a given cell. It monitors
each caller's signal strength, and when a signal begins to fade, it hands off the
call to another MSC that's better positioned to manage the call.
Obfuscation Obfuscation is a technique used to complicate code. Obfuscation makes code
harder to understand when it is de-compiled, but it typically has no affect on
the functionality of the code. Obfuscation programs can be used to protect Java
programs by making them harder to reverse-engineer.
optional An optional package is a set of J2ME APIs providing services in a specific
package area, such as database access or multimedia. Unlike a profile, it does not define
a complete application environment, but rather is used in conjunction with a
configuration or a profile. It extends the runtime environment to support device
capabilities that are not universal enough to be defined as part of a profile or
that need to be shared by different profiles. J2ME RMI and the Mobile Media
RMI are examples of optional packages.
OTA Over The Air (OTA) refers to any wireless networking technology.
PCS Personal Communications Service (PCS) is a suite of second-generation,
digitally modulated mobile-communications interfaces that includes TDMA,
CDMA, and GSM. PCS serves as an umbrella term for second-generation
wireless technologies operating in the 1900MHz range
PDAP The Personal Digital Assistant Profile (PDAP) is a J2ME profile specification
designed for small platforms such as PalmOS devices. You can think of PDAs
as being larger than mobile phones but smaller than set-top boxes. PDAP is
built on top of CLDC and will specify user interface and persistent storage
APIs. PDAP is currently being developed using the Java Community Process
(JCP).
PDC Personal Digital Cellular (PDC) is a Japanese standard for wireless
communications.
PDCP Parallel and Distributed Computing Practices (PDCP) are often used to
describe computer systems that are spread over many devices on a network
(wired or wireless) where many nodes process data simultaneously.
Personal The Personal Profile is a J2ME profile specification. Layered on the
Profile Foundation Profile and CDC, the Personal Profile will be the next generation of
 PersonalJava technology. The specification is currently in development under
the Java Community Process (JCP).
PersonalJav PersonalJava is a Java environment based on the Java virtual machine1 (JVM)
a and a set of APIs similar to a JDK 1.1 environment. It includes the Touchable
Look and Feel (also called Truffle), a graphic toolkit that is optimized for
consumer devices with a touch sensitive screen. PersonalJava will be included
in J2ME in the upcoming Personal Profile, which is built on CDC.
PNG Portable Network Graphics (PNG) is an image format offering lossless
compression and storage flexibility. The MIDP specification requires
implementations to recognize certain types of PNG images.
POSE Palm OS Emulator (POSE).
PRC Palm Resource Code (PRC) is the file format for Palm OS applications.
preverificati Due to memory and processing power available on a device, the verification
on process of classes are split into two processes. The first process is the
preverification which is off-device and done using the preverify tool. The
second process is verification which is done on-device.
profile A profile is a set of APIs added to a configuration to support specific uses of a
mobile device. Along with its underlying configuration, a profile defines a
complete, and usually self-contained, general-purpose application environment.
Profiles often, but not always, define APIs for user interface and persistence;
the MIDP profile, based on the CLDC configuration, fits this pattern. Profiles
may be supersets or subsets of other profiles; the Personal Basis Profile is a
subset of the Personal Profile and a superset of the Foundation Profile. See also
configuration, optional package.
Provisionin In telecommunications terms, provisioning means to provide
g telecommunications services to a user. This includes providing all necessary
hardware, software, and wiring or transmission devices.
PSTN The public service telephone network (PSTN) is the traditional, land-line based
system for exchanging phone calls.
RMI Remote method invocation (RMI) is a feature of J2SE that enables Java objects
running in one virtual machine to invoke methods of Java objects running in
another virtual machine, seamlessly.
RMI OP The RMI Optional Package (RMI OP) is a subset of J2SE 1.3's RMI
functionality used in CDC-based profiles that incorporate the Foundation
Profile, such as the Personal Basis Profile and the Personal Profile. The
RMIOP cannot be used with CLDC-based profiles because they lack object
serialization and other important features found only in CDC-based profiles.
RMIOP supports most of the J2SE RMI functionality, including the Java
Remote Method Protocol, marshalled objects, distributed garbage collection,
registry-based object lookup, and network class loading, but not HTTP
tunneling or the Java 1.1 stub protocol.
RMI Profile The RMI Profile is a J2ME profile specification designed to support Java's
Remote Method Invocation (RMI) distributed object system. Devices
implementing the RMI Profile will be able to interoperate via RMI with other
Java devices, including Java 2, Standard Edition. The RMI Profile is based on
the Foundation Profile, which in turn is based on CDC.
RMS The Record Management System (RMS) is a simple record-oriented database
that allows a MIDlet to persistently store information and retrieve it later.
Different MIDlets can also use the RMS to share data.
SDK A Software Development Kit (SDK) is a set of tools used to develop
applications for a particular platform. An SDK typically contains a compiler,
linker, and debugger. It may also contain libraries and documentation for APIs.
SIM A Subscriber Identity Module (SIM) is a stripped-down smart card containing
information about the identity of a cell-phone subscriber, and subscriber
authentication and service information. Because the SIM uniquely identifies the
subscriber and is portable among handsets, the user can move it from one kind
of phone to another, facilitating international roaming.
SMS Short Message Service (SMS) is a point-to-point service similar to paging for
sending text messages of up to 160 characters to mobile phones.
SOAP The Simple Object Access Protocol (SOAP) is an XML- based protocol that
allows objects of any type to communicated in a distributed environment.
SOAP is used in developing Web Services.
SSL Secure Sockets Layer (SSL) is a socket protocol that encrypts data sent over the
network and provides authentication for the socket endpoints.
T9 T9 is a text input method for mobile phones and other small devices. It replaces
the "multi-tap" input method by guessing the word that you are trying to enter.
T9 may be embedded in a device by the manufacturer. Note that even if the
device supports T9, the Java implementation may or may not use it. Check your
documentation for details.
TDMA Time Division Multiple Access (TDMA) is a second-generation modulation
standard using bandwidth allocated in the 800 MHz, 900 MHz, and 1900MHz
ranges.
Telematics Telematics is a location-based service that routes event notification and control
data over wireless networks to and from mobile devices installed in
automobiles. Telematics makes use of GPS technology to track vehicle latitude
and longitude, and displays maps in LED consoles mounted in dashboards. It
connects to remote processing centers that turn provide server-side Internet and
voice services, as well as access to database resources.
Tomcat Tomcat is a reference implementation of the Java servlet and JavaServer Pages
(JSP) specifications. It is intended as a platform for developing and testing
servlets.
UDDI Universal Description, Discovery, and Integration (UDDI) is an XML-based
 standard for describing, publishing, and finding Web services. UDDI is a
specification for a distributed registry of Web services.
UMTS Developed by Nortel Networks, Universal Mobile Telecommunications Service
(UMTS) is a standard that will provide cellular users a consistent set of
technologies no matter where they are located worldwide. UMTS utilizes W-
CDMA technology.
VLR The Visitor Location Register (VLR) is a database that contains temporary
information about subscribers.
WAE The Wireless Application Environment (WAE) provides a application
framework for small devices. WAE leverages other technologies such as WAP,
WTP, and WSP.
WAP Wireless Application Protocol (WAP) is a protocol for transmitting data
between servers and clients (usually small wireless devices like mobile
phones). WAP is analogous to HTTP in the World Wide Web. Many mobile
phones include WAP browser software to allow users access to Internet WAP
sites.
WAP A WAP Gateway acts as a bridge allowing WAP devices to communicate with
Gateway other networks (namely the Internet).
W-CDMA Wideband Code-Division Multiple Access (W-CDMA), also known as IMT-
2000, is a 3rd generation wireless technology. Supports speeds up to 384Kbps
on a wide-area network, or 2Mbps locally.
WDP Wireless Datagram Protocol (WDP) works as the transport layer of WAP.
WDP processes datagrams from upper layers to formats required by different
physical datapaths, bearers, that may be for example GSM SMS or CDMA
Packet Data. WDP is adapted to the bearers available in the device so upper
layers don't need to care about the physical level.
WMA The Wireless Messaging API (WMA) is a set of classes for sending and
receiving Short Message Service messages. See also SMS.
WML The Wireless Markup Language (WML) is a simple language used to create
applications for small wireless devices like mobile phones. WML is analogous
to HTML in the World Wide Web.
WMLScript WMLScript is a subset of the JavaScript scripting language designed as part of
the WAP standard to provide a convenient mechanism to access mobile phone's
peripheral functions.
WSP Wireless Session Protocol (WSP) implements session services of WAP.
Sessions can be connection-oriented and connectionless and they may be
suspended and resumed at will.
WTLS Wireless Transport Layer Security protocal (WTLS) does all cryptography
oriented features of WAP. WTLS handles encryption/decryption, user
authentication and data integrity. WTLS is based on the fixed network
Transport Layer Security protocal (TLS), formerly known as Secure Sockets
 Layer (SSL).
WTP Wireless Transaction Protocol (WTP) is WAP's transaction protocol that works
between the session protocol WSP and security protocol WTLS. WTP chops
data packets into lower level datagrams and concatenates received datagrams
into useful data. WTP also keeps track of received and sent packets and does
re-transmissions and acknowledgment sending when needed.

J2ME  (Features)
J2ME stands for Java 2 Platform, Micro Edition. The edition of the Java
platform that is targeted at small, standalone or connectable consumer and
embedded devices. The J2ME technology consists of a virtual machine and a
set of APIs suitable for tailored runtime environments for these devices. The
J2ME technology has two primary kinds of components – configurations and
profiles.

J2ME Documentation
Data Sheets

 J2ME Technologies Overview

 J2ME Connected Device Configuration (CDC)
 J2ME Web Services Specification (JSR 172)
 J2ME Wireless ToolKit
 Java Device Test Suite
 Java Technology for the Wireless Industry
 High-Performance Java Wireless Technologies

CLDC Technology

Two virtual machines are available to support CLDC. The K Virtual Machine
is our smallest virtual machine for CLDC, and supports handheld consumer
devices with 128K to 512K of available memory for the Java technology stack.
The CLDC HotSpot Implementation adds adaptive compilation for a dramatic
increase in performance, with minimal increase in memory footprint.

 CLDC HotSpot Implementation 1.1 White Paper (PDF, 190K)

 KVM Data Sheet
 KVM White Paper (PDF, 380K)
CLDC 1.1

 CLDC Specification, V1.1

 CLDC API Documentation, V1.1 (ZIP, 340K), (PDF, 3036K)

CLDC 1.0.4

 CLDC Specification, V1.0

 CLDC API Documentation, V1.0 (ZIP, 307K), (PDF, 2243K), Japanese (ZIP, 1.4MB)

MIDP Overview

MIDP 2.0

 MIDP 2.0 Specification, (JSR 118)

 MIDP Datasheet
 White paper: What's New in MIDP 2.0
 Wireless developer home page for MIDP
 MIDP 2.0 Style Guide
 Programming Wireless Devices with the Java 2 Platform, Micro Edition

MIDP 1.0

 MIDP 1.0 Specification, (JSR 37)

 White Papers:
   MIDP APIs for Wireless Applications (PDF, 171K, 14 pages)
   Applications for Mobile Information Devices (PDF, 106K, 17 pages)
   Java Technology and the New World of Wireless Portals and mCommerce
 Over The Air User Initiated Provisioning Recommended Practice (PDF, 99K, 24
pages)
 Programming Wireless Devices with the Java 2 Platform, Micro Edition
 MIDP 1.0 Style Guide (HTML) (ZIP, 667K)

CLDC Optional Packages

 Mobile Media API

Specification, V1.0
Release Notes
Porting Guide (PDF, 874K)
White paper: Bringing Time-Based Multimedia to Consumer Devices (PDF, 95K)
 Wireless Messaging API
Reference Implementation (PDF, 645K)
 Bluetooth API
Java Partner Site (Motorola)

Generic Connection Framework Optional Package (GCF-OP) - NEW

The Generic Connection Framework was developed for use in the J2ME
platform as an alternative to the more complex networking and I/O APIs
contained in the [Link] and [Link] packages of the J2SE platform. By
providing the Generic Connection Framework as an optional package (GCF-
OP) to the J2SE platform, J2ME applications written to a number of common
protocols in the [Link] package can migrate to the J2SE
platform.

 GCF Overview
 GCF-OP for J2SE Platform
 GCF-OP Specification

Java Technology for the Wireless Industry (JTWI) - NEW

Defines the industry standard for the next generation of Java technology
enabled mobile phones.

 JTWI Profile Overview

 JTWI Specification

J2ME Wireless Toolkit

Tools for the development of MIDP compliant applications targeted at mobile

information devices.

J2ME Wireless Toolkit 2.1 - NEW

 User's Guide (PDF, 1197K; HTML)

 Basic Customization Guide (PDF, 701K; HTML)
 Binary Release Notes

J2ME Wireless Toolkit 2.0_01

 User's Guide (PDF, 978K; HTML)

 Basic Customization Guide (PDF, 619K; HTML)
 Binary Release Notes

J2ME Wireless Toolkit 1.0.4

 User's Guide (PDF, 890K; HTML)

 Basic Customization Guide (PDF, 553K; HTML)
 Binary Release Notes

 J2ME Wireless Toolkit FAQ

  Mobile Media API Emulator for Wireless Toolkit
o Release Notes
o User's Guide (PDF, 263K)

CDC Technology

CDC is a standards-based framework for building and delivering applications

that can be shared across a range of network-connected consumer and
embedded devices.

 CDC White Paper (PDF, 1.4MB)

 CDC Specification (JSR 36)
 Foundation Profile
Foundation Profile is a set of Java APIs that support resource-constrained
devices without a standards-based GUI system.
o Foundation Profile Specification (JSR 46)
o Porting Guide (PDF, 814K)
o Release Notes
 Personal Basis Profile
Personal Basis Profile is a set of Java APIs that support resource-constrained
devices with a standards-based GUI framework based on lightweight
components. Personal Basis Profile also includes support for the xlet
interface and all of the APIs included in Foundation Profile.
o Personal Basis Profile Specification (JSR 129)
o Programmer's Guide (PDF, 1.2MB)
o Porting Notes
o Release Notes
 Personal Profile
Personal Profile is a set of Java APIs that support resource-constrained
devices with a standards-based GUI framework based on AWT peer
components. Personal Profile also includes support for the applet interface
and all of the APIs included in Personal Basis Profile.
o Personal Profile Specification (JSR 62)
o Programmer's Guide (PDF, 1.3MB)
o Porting Notes
o Release Notes
 CDC Optional Packages
Optional packages are technology-specific APIs that extend the functionality
of a Java application environment.
o RMI Optional Package
RMI Optional Package Specification (JSR 66)
o JDBC Optional Package
JDBC Optional Package Specification (JSR 169)

Security and Trust Services API (SATSA) for J2ME - NEW

  JSR 177 Overview

Java Card Technology

Enables the Java programming language to run on smart cards and other small
devices.

 Java Card Platform Data Sheet - NEW

 Java Card 2.2.1 Platform Specification
 Java Card 2.2 Platform Specification

Follow the previous links to download the Java Card 2.2.1or 2.2 Platform
Specification bundle (ZIP format), which contains the following documents
(PDF format):

 Java Card API Specification

 Java Card Runtime Environment Specification
 Java Card Virtual Machine Specification
 Java Card Specification Release Notes

 Java Card 2.2 RMI Client Application Programming Interface

 Java Card 2.2 Off-Card Verifier White Paper
 Java Card 2.2 Development Kit (including documentation)
 Java Card Technology for Smart Cards: Architecture and Programmer's Guide

Other J2ME Technologies

Java Embedded Server Software

Enables home appliances to be networked to each other and the Internet and to
receive services on demand.

 Open Services Gateway Initiative Specification, V1.0

 Java Embedded Server Software 2.0 Download
 API Documentation (ZIP, 139K)
 Java Embedded Server Software 2.0:
   Tutorial (Microsoft Windows) (PDF, 219K)
   Tutorial (Solaris Environment) (PDF, 219K)
   Technical FAQ

PersonalJava Application Environment

A Java virtual machine and class library that enables applications for home,
office, and mobile consumer devices.

 PersonalJava API Specification, V1.2

Java TV Technology

Provides a development and deployment platform for interactive digital

television.

 Java TV API Specification, V1.0

 Java TV API Technical Overview (PDF, 577K)

Java Telephony API

JTAPI is an extensible API designed to scale for use in a range of domains.

 JTAPI Documentation
 JTAPI Whitepapers

//This is the MIDP version of the familiar HelloWorld program.

import [Link];
import [Link];
import [Link];
import [Link];
/**
Creates the "Hello world" program in J2ME MIDP.
Note that the class must be public so that the device
application management software can instantiate it.
*/
public class HelloWorld extends MIDlet
 

{
// The Displayable. This component is displayed on the
// screen.
private Form form;
// The Display. This object manages all Displayable
// components.
private Display display;
// A public no-arg constructor is necessary, even though
// the system calls startApp()! The AMS calls the
// class's no-arg constructor to instantiate the class.
// Either create a public no-arg constructor, or declare
// no constructors, and let the compiler create a public
// no-arg constructor.
//
public HelloWorld()
{
super();
}
public void destroyApp(boolean destroy)
{
form = null;
notifyDestroyed();
}
public void pauseApp()
{
}
public void startApp()
{
// Create a Displayable widget.
form = new Form("Hello, World");
// Add a string to the form.
String msg = "My first MIDlet!";
[Link](msg);
// This app simply displays the single form created
// above.
display = [Link](this);
[Link](form);
}
}

First, notice that this application defines a class called HelloWorld, which
extends [Link]. All MIDlets must extend this class.
The HelloWorld class is the primary class of your application. For this reason,
it must be declared public. Moreover, you must declare a public no-argument
constructor, or ensure that there are no constructors, in which case the compiler
will define a no-argument constructor for you. Readers who are familiar with
Java applets will recognize the similarity between the applet and MIDlet
lifecycle control models.
 
In the program above, the startApp(), pauseApp(), and destroyApp() methods
override abstract declarations from the MIDlet class. Notice that all the
initialization code goes in the startApp() method rather than in the constructor.
You certainly can put some initialization code in your constructor; it will be
executed before the call to startApp(). However, the startApp() method is
always called as the entry point for your MIDlet.

What about a main() method? The Java language definition requires all Java
applications to have a main() method with the following signature:

public static void main(String [] args)

If J2ME applications are real Java applications, then there must be a main
method somewhere that is the real entry point used by the VM to start the
process of executing the application. In fact, there is such a method. It's part of
the MIDP implementation (not the application), and, typically, the AMS
software calls it. The AMS handles application invocation requests, for
instance, by spawning a thread for each MIDlet startup request and controlling
the MIDlet from that thread. Actual details are implementation dependent. In
Sun's J2ME Wireless Toolkit, the class [Link] defines the main()
method.

The startApp() method creates an object called a form and passes a string to the
constructor that represents the form's title. A form is an instance of the class
[Link], which is a kind of screen that you can see on
your display. It's so named because it functions somewhat like an HTML form
—it contains one or more visual items, such as strings.

Next, the startApp() method creates a regular String object and adds it to the
form. It then gets a reference to an object called a display, and it sets the form
object as the currently displayed entity of the display.

After all this code executes, you see the screen. When you click or press the
handset
button that tells the device to hang up, the AMS invokes destroyApp(), which
simply eliminates all references to the form object previously created. It's now
subject to garbage collection. The AMS then terminates the MIDlet.

You're responsible for properly disposing of objects created by your MIDlets.

In this contrived case, it shouldn't matter whether or not you set the reference to
the form variable to null, because the MIDlet terminates. But in general, you
need to properly manage the references to your program's objects, just as you
would in any Java program.

The MIDlet Life-Cycle learning path is a bit different from others in format.
Many simply state goals and prerequisites briefly, then provide links to the
content. This one provides the basic content directly, and along the way
furnishes links to other resources.
This learning path will focus on source code. Why? Ultimately in a product
life-cycle, someone must actually create an instantiation of a design that was
based an architecture that was begotten by an idea. Business cases, designs, and
architectures cannot be compiled to run on devices. Someone actually has to
produce code that embodies the design, meets high standards of quality, and
meets users' needs. This coding task includes crafting a build environment,
managing a source base, and serving it all up in a form that allows the the
developers to crank out the product in its deliverable form, on demand. Control
and repeatability are key elements of software product management.

So where does all this lead? Virtually all source code is layered on top of
existing application progamming interfaces (APIs). How well you understand
the APIs you consume, and how correctly you use them, directly affect the
quality of your product. Merely reading the API specifications isn't enough.
Code that reflects a deep understanding of the API, and that demonstrates
correct patterns of use, both reinforce the specification and provide idioms that
can be directly employed by other developers. The purpose of this learning path
is to help you produce that kind of code.

 Introduction
 JADs and JARs
 The Security Model
 Installation
 Removal
 The First Program
 Execution States
 Sample Source
 Summary

Introduction

Understanding the MIDlet life-cycle is fundamental to creating any MIDlet.

The life-cycle defines the execution states of a MIDlet – creation, start, pause,
and exit – and the valid state transitions. 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.

JADs and JARs

The basic components of any MIDlet suite you will deliver are the Java
Application Descriptor (JAD) file and the Java Archive (JAR) file. Together,
these two items are the MIDlet suite.

The JAD file, as the name implies, describes a MIDlet suite. The description
includes the name of the MIDlet suite, the location and size of the JAR file, and
the configuration and profile requirements. The file may also contain other
attributes, defined by the Mobile Information Device Profile (MIDP), by the
developer, or both. Attributes beginning with MIDlet- or MicroEdition- are
reserved for use by the AMS. The JAD file syntax is similar to that of the
[Link] class found in the J2SE environment.

A MIDlet suite on a device is identified by the attribute tuple (MIDlet-Name,

MIDlet-Version, MIDlet-Vendor). The JAR file will be installed from the
location MIDlet-Jar-URL. The size of the download must agree with the
MIDlet-Jar-Size value.

The JAR contains one or more MIDlets, specified in the JAD using the
MIDlet-<n> attribute. The syntax is:

MIDlet-n : MIDletName , [IconPathname] , ClassName

where:

 n is the MIDlet number, starting at 1 and incremented by 1 for each MIDlet.

 MIDletName is the user-visible name of the MIDlet.
 IconPathname is the absolute pathname of a .png image file within the
JAR.
 ClassName is the name of a class that extends
[Link] and has a public, zero-argument
constructor.

A manifest file is located at /META-INF/[Link] within the JAR. The

manifest has the same syntax as the JAD file and it may share the same
attributes. The rules for attribute location and lookup are described in the
technical tip "Retrieving MIDlet Attributes." The manifest is a key component
of the MIDP 2.0 signed-MIDlet model. In a signed MIDlet suite, attributes in
the JAD must agree with those in the manifest. While you can modify the JAD
file attributes easily, you can't modify those in the signed MIDlet without re-
signing the MIDlet suite.

In addition to the Java class files and the manifest, the JAR file may contain
other resources. These may be images that the MIDlet can load using the
[Link](String) method. The
application can also use [Link](String)
to access any resource in the JAR file as a [Link]  – any
resource execpt a class file, that is. The String argument that either method
expects is a pathname identifying a resource in the JAR file. The definition and
rules for pathname use are found in the "Application Resource Files" section of
the JSR 118: Mobile Information Device Profile (MIDP) 2.0 specification, on
page 36.

The Security Model

The J2ME security model is a scaled-down version of the J2SE model. It has
been adapted to work within the contrained resources common among J2ME
devices.

The rules are:

 Class files are verified for interface compliance before inclusion in a JAR file.
 There is a limited API set: the Connected Limited Device Configuration
(CLDC), one or more related profiles, and licensee open classes.
 Downloading and management of Java applications take place in native code
within the Java virtual machine1. There are no user-defined class loaders.
 There is no Java Native Interface (JNI), and no user extensions are allowed.
 System classes cannot be overridden.

The short of it is:

 You cannot modify the runtime environment.

 You cannot modify yourself.
 You cannot escape the runtime environment.

Installation

There are two ways to install a MIDlet suite. The first, called direct, involves
some direct connection between the device and the development platform –
commonly cable, infrared, or Bluetooth link. In the case of the Nokia 6100, for
example, it's a Nokia DKU-5 USB cable and the Nokia PC Suite software,
which includes Nokia Application Installer. You develop the MIDlet suite,
perhaps test it in an emulator, then install it using the USB cable and Nokia
Application Installer. While this method is efficient for testing on your own
device, it is hardly suitable for deploying an application to millions of end
users.

Over-the-air provisioning (OTA) makes large-scale deployment possible – even

easy. A device can install a MIDlet suite from a remote server using the
device's built-in browser. Simply entering the URL of the suite's JAD file into
the browser address field starts the installation process. In general terms:
 1. The client device sends an HTTP GET request to the server for the given URL.
2. The server sends an HTTP response with the suite's JAD file as the message
body.
3. The client verifies the HTTP response and extracts the suite's MIDlet-Jar-
File and MIDlet-Jar-Size attributes.
4. The device sends an HTTP GET request for the JAR file.
5. The server sends an HTTP response with the JAR file as the message body.
6. The device verifies the message and the JAR file.
7. The device asks the user to verify installation.

This description omits steps relating to signed MIDlet suites, permissions, and
push-registry entries, collapsing them into the "verifies message and JAR file"
step. Error handling has also been omitted to simplify presentation.

The success of the installation process depends on correct functioning of the

web server and the device's browser. Characteristics of the network between
the device and server can affect installation too. One frequent cause of OTA
failure is a size limit that network elements impose on the size of the JAR file.
Another is specifying incorrect MIME types for JAD and JAR files. The
correct MIME type for a JAD file is text/[Link]-descriptor
and for a JAR file is application/java-archive.

Removal

Here's the easiest part: Because a MIDlet suite is a self-contained entity,

deleting it is simple. Most devices allow the user to select a MIDlet suite and
choose a Delete option from a menu. At this point the device likely asks for
confirmation; a positive response removes the MIDlet suite, including any
push-registry entries and record stores created by any MIDlet in the suite.

On a Sony Ericsson T616, for instance, the deletion process looks like this:

1. Press the joystick button to access the application page.

2. Using the joystick, scroll to the Entertainment icon and select it.
3. Select the Games & More item from the list.
4. Select a MIDlet from the list.
5. Press the More button.
6. Select the Delete option from the list.
7. Select Yes in the Delete confirmation dialog. (The MIDlet is deleted.)
8. Select OK in the Deleted confirmation dialog.

Different devices have different procedures but the idea is the same; in the end the
MIDlet suite is gone.
The Quintessential First Program

Since the days of Kernighan and Ritchie's The C Programming Language

(1978), the first program most developers attempt when they begin using a new
language or environment is Hello World. The C version contains only a few
lines, including the specification of an I/O library, and the output is only a
simple greeting, but this venerable program gives you the chance to prove
much: that you can write, build, debug (if necessary), and run a program. So
developers using Java technology won't be left out, the article "Wireless
Development Tutorial Part I" provides a J2ME version of Hello World and
instructions on building it.

Execution States

When a MIDlet begins execution, the AMS first calls the zero-argument
constructor to create a new instance of the MIDlet. The constructor typically
does little or no initialization. The AMS framework provides transitions that
you can use as control points for resource management, as you'll soon see.
When the constructor returns, the AMS places the MIDlet in the Paused state.
To shift the MIDlet to the Active state the AMS calls the [Link]()
method.

A transition from the Active state back to the Paused state occurs whenever the
AMS calls [Link](). You can think of this method as the inverse of
startApp(). The MIDlet is not being terminated, but it should release any
resources it obtained in startApp(). The MIDlet may shift from Paused to
Active or back any number of times during its execution, each time on a call to
startApp() or pauseApp().

These transition methods give you the opportunities you need to manage
resources effectively. Typically, you'll use startApp() to allocate record
stores, network connections, UI components, and such, and use pauseApp() to
release these resources.

public class Mandy extends MIDlet {

private boolean once = false;

Mandy() {
}

public void startApp() {

if ( once == false ) {
once = true;
// acquire one-time resources
 }
// acquire "other" resources
}

public void pauseApp() {

// release "other" resources
}
}

The only question left is: What differentiates one-time resources from other
resources? There is no definitive answer, only a set of guidelines:

 UI components are generally regarded as one-time resources.

 Background threads can be regarded as one-time resources.
 Timers and Tasks are usually one-time resoruces.
 Network connections and IO streams are usually not one-time resources.
 Resources that can be shared between MIDlets are not one-time resources.

The sequence of acquisition and release can be coded in LIFO order, as stack
operations; that is, if you acquire resources in the order A-B-C, release them in the
order C-B-A.

The MIDlet may enter the Destroyed state from either Paused or Active, on a
call to [Link](). This method releases any resources acquired in
the constructor, and saves any state information.

There are a few variations on this Paused/Active/Destroyed theme. First, a

MIDlet may voluntarily enter the Paused state by calling
[Link](). In a similar fashion, it may call
[Link]() to inform the AMS that the MIDlet can now be
considered Destroyed. The destroyApp() method is actually called with a
boolean argument. If this boolean is true, the MIDlet will be in the
Destroyed state when destroyApp() returns. If this boolean is false,
however, the MIDlet can request not to enter the Destroyed state by throwing a
MIDletStateChangeException. Note that this is only a request to the AMS.
Finally, a call to [Link]() will tell the AMS that the MIDlet
is interested in entering the Active state. How can a Paused MIDlet make the
call to resumeRequest(), you ask? While it's idle in most ways, a MIDlet in
the Paused state may handle asynchronous events such as timers and callbacks.

There are still some open questions here, about the interactions between the
AMS and the MIDlet. These can be characterized as the why and the when. For
example, when is startApp() called, and why is pauseApp() called? The
 specification is intentionally vague in these areas, allowing implementations to
follow the rules while also allowing host runtime environments to vary. By way
of an example: Suppose a mobile phone detects an incoming Multimedia
Messaging Service (MMS) message. The AMS may pause an executing MIDlet
to free up memory needed by the MMS message. If the pause operation doesn't
free enough memory, the AMS may then invoke destroyApp() to release
more. The indeterminate answers to such questions may not be the ones
developers are looking for, but they are as definitive as the specification writers
can make them.

Sample Source

Source code available from the Java mobility site comes in two forms: one for
online viewing and another for download. The download version is in J2ME
Wireless Toolkit application format. The following table also supplies a
reference to the article relevant to each sample. If you're using the J2ME
Wireless Toolkit, you can begin working with the source files simply by
unzipping the archive and moving the applications into the apps subdirectory
of your toolkit installation.

Article Online Download

Retrieving MIDlet Attributes [Link] [Link]

[Link]
Managing the MIDlet Life-Cycle with a Finite State Machine [Link]
[Link]

Wireless Application Programming: MIDP Programming and [Link]

[Link]
Packaging Basics [Link]

Wireless Development Tutorial, Part I [Link] [Link]

Which brings us to the toolkit itself – the J2ME Wireless Toolkit, of course, a
state-of-the-art toolbox for developing wireless applications based on MIDP.
The current release at this writing, 2.2, supports CLDC 1.0 and 1.1, MIDP 1.0
and 2.0, and seven other J2ME JSRs. The toolkit allows the developer to
choose the JSRs that best match the target environment, build JAD and JAR
files, and run MIDlets in an emulator before deploying them on target devices.
The toolkit is available for download.