Upload
phungtu
View
214
Download
2
Embed Size (px)
Citation preview
CHAPTER2
MOBILE PLATFORMS
Pervasive Java
EDITORS’ INTRO
Welcome to the first installment of Standards, Tools, & Best Practices. This department will report on the latest in standards activities and development tools as they pertain to pervasive computing. The intended audience includes practitioners, technologists, and systems researchers who want to base their prototyping activities on industry standards and tools. I plan to discuss several exciting topics including
• platform standardization
• mobile services and their discovery protocols
• sensor networks
• wearable computers and their applications
• peer-to-peer programming over ad hoc networks
• standards and applications for smart homes
• commercial mobility-support middleware (data synchronizers,
Web, databases, email, and so forth)
• mobile commerce
I welcome suggestions and contributions for additional topics. In this first issue, I highlight pervasive Java—a surge of wireless and mobile platform standardization activities led by Sun Microsystems. Driven by a fast-pace proliferation of portable devices and appliances with embedded computers, pervasive Java (also called wireless Java and mobile Java) attempts to bridge the gap between disparate devices and platforms, and profitable business and application development. —Sumi Helal
Standards, Tools, & Best Practices
Today, mobile devices and gadgets come with more than just a
cool and cutting-edge design; they come equipped with small
brains and a common language, making them smarter and more
powerful than ever before. Perhaps they’re a little too smart—after
all, they can adapt and morph into each other and become many-in-
one super devices. Mobile phones with PDA capabilities and PDAs
packaged as mobile phones have started to invade the marketplace.
Furthermore, it won’t be long before we can shoot a presentation
right off our mobile phones or use a mobile phone as a wireless
mouse to more easily surf the Web on a laptop. Appliances are also
gaining amazing intelligence, thanks to embedded computers and
tiny communication interfaces. Pointof-sale equipment, gas pumps,
automobile dashboards, and digital cameras are examples of
today’s smart appliances. Refrigerators with Web pads,
microwaves that download recipes, and stereo systems that mute
when the phone rings are among the many smart appliances on the
horizon. The impressive leap in this technology led to a rapid
proliferation of many kinds of portable and embedded devices.
This proliferation signaled the beginning of a new and exciting era
of computing. It also quickly underpinned the new requirements
we must meet to mobilize this technology. The most critical
requirement was the need for a common yet flexible computing
and communication environment that could be fitted for— and
shared by—devices of different makes and capabilities.
Realizing this need, and recognizing that one size does not fit all,
Sun Micro-systems introduced the Java 2 Platform, Micro Edition,
a set of specifications that pertain to Java on small devices, ranging
from pagers and mobile phones to set-top boxes and car navigation
systems. Since its introduction, J2ME has evolved according to the
Java Community Process, a formalized process and an open
Sumi Helal, Chapter 22
Standards, Tools, & Best Practices
organization of international Java developers and licensees whose
charter is to develop and revise Java technology specifications,
reference implementations, and technology compatibility kits.
The J2ME specifications are divided into configurations that are
specific to different device categories. Each configuration is
specialized into a set of profiles, which are specifications of
particular types of devices within a device category. Here, I
introduce J2ME and its configurations and profiles, emphasizing
mobile phones and PDAs that use the Mobile Information Device
Profile. In the next issue, I’ll survey available J2ME development
toolkits and MIDP devices, including mobile phones and PDAs.
2.1 JAVA 2 PLATFORM, MICRO
EDITION
In June 1999, Sun Microsystems introduced J2ME, targeted for
consumer electronics, portables, and embedded devices. This was
part of a reorganization effort of the Java technology into
Enterprise, Standard, and Micro editions (see Figure 2.1). To
support the kind of flexibility and customizable deployment that
the portables and embedded marketplace demand, the J2ME
architecture is composed of three modular and scalable layers: Java
Virtual Machine, Configurations, and Profiles.
The JVM layer implements a JVM customized for a particular
device’s host operating system and that supports a particular J2ME
configuration.
The configuration layer defines a minimum set of JVM features
and core Java class libraries available on a particular category of
Sumi Helal, Chapter 2 3
Standards, Tools, & Best Practices
devices. These devices represent a particular market segment and
can be thought of as the lowest common denominator of the Java
platform features that a developer can assume will be available on
all devices.
Figure 2.1. One Java, three editions.
Figure 2.2. The relationship between Java 2 Platform, Micro
Edition configurations and the Java 2 Standard Edition.
Sumi Helal, Chapter 24
Standards, Tools, & Best Practices
The profile layer defines the minimum set of application
programming interfaces available on a particular group of devices,
which are developed on the underlying configuration. Profiles
serve two main purposes: device specialization (APIs that capture
or exploit particularities of the device interface and capability) and
device portability (APIs that behave consistently on any device
supporting the profile). Applications written for a particular profile
should therefore port to any device that conforms to that profile.
Generally, a device can support multiple profiles on which
different applications are built.
The configuration that defines small, mobile devices is called the
Connected, Limited Device Configuration. Examples of CLDC
devices are mobile phones and pagers. These devices will have
memory between 160 and 512 Kbytes and use the Kilobyte Virtual
Machine (KVM). A CLDC device uses either a 16- or 32-bit
processor and a low-bandwidth wireless network connection. The
only profile currently developed for the CLDC configuration is the
MIDP.
The Connected Device Configuration is considered a fixed type of
device that is always connected but still relatively resource poor.
An example would be set-top boxes such as a satellite TV receiver
or WebTV. The CDC configuration is a superset of the CLDC,
which ensures their compatibility. Figure 2.2 shows the
relationship between the various configurations.
Here, I highlight the main features of the KVM–CLDC
configuration and the MIDP. (For more information, see the Sun
Microsystems white paper, “Java 2 Platform Micro Edition (J2ME)
Technology for Creating Mobile Devices,” at
http://java.sun.com/products/cldc/ wp/KVMwp.pdf.)
Sumi Helal, Chapter 2 5
Standards, Tools, & Best Practices
2.1.1 KVM
The KVM is a new, smaller runtime environment for resource-
constrained devices. It is in the range of 40 to 80 Kbytes—hence
the “K” in KVM. Developing the KVM originated as a project,
known as the Spotless System, to create an execution engine for
the Palm PDA. The Spotless System development team soon
discovered that the runtime environment’s size is derived mainly
from its runtime libraries.
GLOSSARY
CDC Connected Device Configuration
CLDC Connected, Limited Device Configuration
J2ME Java 2 Platform, Micro Edition
J2SE Java 2 Platform, Standard Edition
JAD Java Application Descriptor
JAM Java Application Manager
JAR Java Archive
JVM Java Virtual Machine
KVM Kilobyte Virtual Machine
MIDP Mobile Information Device Profile
They then extracted classes that were too bloated or not as
critical to the system. The primary features eliminated were
The Java Native Interface, because native functionality is implementation dependent
The user-defined class loader, because CLDC will have a class loader that users can’t override, replace, or reconfigure
Reflection, to eliminate RMI, serialization, or any other features reliant on reflection
Thread groups and daemon threads (although the system supports multithreading)
Finalization of class instances
Weak references
Sumi Helal, Chapter 26
Standards, Tools, & Best Practices
AWT (Java Abstract Window Toolkit), which the developers
replaced with limited user interface classes, developed from the
javax.microedition. lcdui package
The floating-point type (although the system enables long
integers)
Figure 2.3. Relationships between Kilobyte Virtual Machine,
Connected Limited Device Configuration, and Mobile Information
Device Profile layers.
A reference implementation of KVM written in the C language is
available. Most of the code is common to all existing and future
implementations. A relatively small amount of platform-dependent
code is isolated in a few files. Porting KVM to a particular device
amounts to modifying only these dependency files. A special
startup mechanism of KVM and its applications is included in this
reference implementation. This is needed because, unlike a
general-purpose machine, small devices do not have a command-
Sumi Helal, Chapter 2 7
Standards, Tools, & Best Practices
line or special interface to start software atop the native operating
system. The Java Application Manager serves as an interface
between the native operating system and KVM. JAM downloads
and launches a J2ME application on top of KVM by connecting to
an HTTP server (using a serial line interface or some other means,
such as “over the air” in the case of mobile phones) to download
the application (called MIDlet) and a metadata file that describes
it. JAM uses the metadata file to uncompress and install the
MIDlet.
2.1.2 CLDC
The CLDC configuration defines a standard Java platform for
small, resource-constrained, connected devices and enables the
dynamic delivery of Java applications and content to those devices.
The small footprint configuration (limited to about 128 Kbytes) is
designed to run on many small devices, making minimal
assumptions about the native system software available. CLDC is
implemented as a set of additional classes contained in a separate
package (the java.io, java.lang, java.util, and javax.nicroedition.io
packages). This facilitates CLDC porting to different platforms.
CLDC requires that a JVM be able to identify and reject invalid
class files. The standard verification technique, such as that used
by J2SE (Standard Edition), is expensive in terms of memory use.
To reduce client-side verification overhead, CLDC uses a dual pre-
verification and verification process to push part of the verification
process into the development latform. The developer must pre-
verify the server or desktop prior to downloading the CLDC
MIDlet application into the mobile device. The pre-verification
process generates information (known as stackmap attributes) that
Sumi Helal, Chapter 28
Standards, Tools, & Best Practices
should be downloaded to the mobile device along with the
application classes. To streamline the packaging of this pre-
verification information and to enable dynamic downloading of
third-party applications and content, CLDC requires
implementations to support the distribution of Java applications
using compressed Java Archive (JAR) files. Whenever a Java
application intended for a CLDC device is created, it must be
formatted into a JAR file, and class files within a JAR file must
contain the stackmap attributes. The MIDP also imposes a similar
data requirement on third-party MIDlets.
2.1.3 MIDP
The MIDP is a set of JavaAPIs that, together with the CLDC,
provides a complete J2ME application runtime environment
targeted at mobile information devices, such as mobile phones,
PDAs, and two-way pagers. It is the only profile currently fully
specified for CLDC (another profile that specializes only on PDAs
—the PDA profile is currently being developed). The MDIP
provides API classes related to interface, persistence storage,
networking, and application model. For instance, the MIDP
specifications provide an API for persistent storage in the form of a
RecordStore. This is a Java object that can be instantiated and used
to store data objects as raw bytes. The profile also provides a set of
requirements for device manufactures to use as guidelines if they
want their devices to be CLDC and MIDP branded. For example,
the MIDP minimum display requirements are a 96 × 54 pixel
screen-size, a display depth of 1 bit, and a pixel shape (aspect
ratio) of approximately 1:1. Another MIDP minimum requirement
is memory, which is 128 Kbytes of RAM, 8 Kbytes of application-
created data, and 32 Kbytes of Java heap.
Sumi Helal, Chapter 2 9
Standards, Tools, & Best Practices
To enable the distribution of third-party MIDlets, developers must
generate a metadata file. Once they package an application (classes
and all auxiliary components) into a JAR file, the developers must
generate an associated Java Application Descriptor (JAD) and ship
it along with the JAR file. Toolkits exist to aid developers with the
packaging and to help them generate the JAR and JAD files. JAD
contains information that the JAM will use to properly verify and
configure the MIDlet application at loading time and that the
MIDlet will use during execution time.
MIDP has been created through the Java Community Process (see
the Java Specification Request JSR37 at http://
jcp.org/jsr/detail/37.jsp). The goal of the consortium that created
the MIDP (which consisted mainly of device manufacturers) was
to create an open third-party application development environment
for mobile information devices. Device manufacturers may include
additional original equipment manufacturer classes (such as APIs
optimized for packet data communication, gaming, or animated
images). MIDlet applications created or preinstalled on the device
by the manufacturers may use these additional classes and APIs.
Third-party developers, however, may not access the native device
operating system, or any OEM classes or applications. Figure 2.3
shows the architectural view of the relationships between the
KVM, CLDC, and MIDP layers.
2.1.4 Hello World MIDlet
Figure 2.4 shows a Hello World MIDlet. The MIDlet contains the
constructor method as well as the methods startApp(), pauseApp(),
and destroyApp(). It calls the first method when the application
starts or restarts after a pause state. It calls the pauseApp() during
Sumi Helal, Chapter 210
Standards, Tools, & Best Practices
the phone’s idle or paused mode and calls destroyApp() right
before it is unloaded. The JAM will create the Hello World
MIDlet, and then the public, no-argument constructor is called.
Figure 2.4. The Hello World MIDlet.
The JAM will then call theMIDlet’s startApp() method, which
loads the display to the instance of the Form class mainscreen. This
instance creates the Form used to hold the StringItem instance,
strItem, properly initialized to display “Hello World.” By
appending strings and many other components to the form, the
information is displayed into the Java phone.
Pervasive Java is a significant technology development that is
truly enabling mobile and pervasive computing. It is transforming
Sumi Helal, Chapter 2 11
/** HelloWorld.java*/package com.mot.j2me.midlets.tutorials;import javax.microedition.lcdui.*;import javax.microedition.midlet.*;
/** A simple Hello World midlet*/public class HelloWorld extends MIDlet {
private Form mainscreen;private Display myDisplay;
HelloWorld1() {myDisplay = Display.getDisplay(this);mainscreen = new Form("Hello World");StringItem strItem = new StringItem("Hello", "HelloWorld");mainscreen.append(strItem);
}
public void startApp() throwsMIDletStateChangeException{
myDisplay.setCurrent(mainscreen);}protected void pauseApp() {}protected void destroyApp(boolean unconditional)
throws MIDletStateChangeException {}
}
/** HelloWorld.java*/package com.mot.j2me.midlets.tutorials;import javax.microedition.lcdui.*;import javax.microedition.midlet.*;
/** A simple Hello World midlet*/public class HelloWorld extends MIDlet {
private Form mainscreen;private Display myDisplay;
HelloWorld1() {myDisplay = Display.getDisplay(this);mainscreen = new Form("Hello World");StringItem strItem = new StringItem("Hello", "HelloWorld");mainscreen.append(strItem);
}
public void startApp() throwsMIDletStateChangeException{
myDisplay.setCurrent(mainscreen);}protected void pauseApp() {}protected void destroyApp(boolean unconditional)
throws MIDletStateChangeException {}
}
Standards, Tools, & Best Practices
mobile devices and appliances from just “cool” gadgets into
essential players and integrated elements in the pervasive
computing world. By making mobile devices and appliances
smarter and by training them to speak the same language (allowing
baby devices to speak weaker dialects of the language), we’ve
come far closer to what a few pioneers in this field envisioned
years ago. The stage is now set to realize this vision, and the
opportunities are numerous to elevate and push the frontiers of
research and development, in pursuit of a better, more effective use
of computers in our lives.
Sumi Helal, Chapter 212
Standards, Tools, & Best Practices
Pervasive Java, Part II In the first issue, I covered Java 2, Micro Edition (J2ME)
technology, focusing on its Connection Limited Device
Configuration (CLDC) and Mobile Information Device Profile
(MIDP) (see the “Part I” sidebar). Here, I take a closer look at
J2ME’s business and commercial side, comparing several
development toolkits and addressing challenges the growing
community of J2ME developers faces.
2.2 J2ME PLATFORMS
Java-enabled phones and PDAs are a fast-growing market. Over
three million Java handsets have been sold since April 2001, and
companies are racing and teaming up with each other to capture a
piece of this new market. The main players are handset and PDA
manufacturers, wireless providers, Sun Micro-systems, and
companies specializing in software development tools.
GLOSSARY
3G Third-Generation Wireless Networks
CLDC Connected, Limited Device Configuration
IDE Integrated development environment
J2ME Java 2 Platform, Micro Edition
JCP Java Community Process
JSP Java Specification Request
MIDP Mobile Information Device Profile
OEM Original equipment manufacturer
PDA Personal Digital Assistant
PDAP PDA Profile
Sumi Helal, Chapter 2 13
Standards, Tools, & Best Practices
With new devices continually entering the marketplace, it would
be of little value to survey all available devices. Instead, I take a
quick sampling of Java-enabled phones and PDAs. For complete,
up-to-date information from over 12 different manufacturers, see
JavaMobiles (www.javamobiles.com), the MicroJava Network
(www.microjava.com/devices), and the Sun Microsystems Web
site (http://wireless.java.sun.com/device).
2.2.1 Java-enabled phones
I surveyed three markets: Japan, North America, and Europe.
Starting with Japan, its leading wireless provider, NTT DoCoMo,
was the first to adopt J2ME technology. Its Java-enabled i-mode
phones and services have attracted over 30 million subscribers
since February 1999. In fact, i-mode has been a success story for
DoCoMo, turning around its performance and revenues in the past
couple of years. Currently, i-mode phones don’t use the MIDP
profile (instead, they use DoJa or DoCoMo Java), but the company
plans to migrate the phones to the next MIDP generation (MIDP
2.0) by the end of the year.
Japan’s third-largest wireless carrier, J-Phone Communications,
has outlined its Java service for mobile phones and plans to offer
geographic information and multimedia services (with JPEG and
PNG graphics synchronized with sounds). The J-Phone group
offers several handsets based on J2ME technology, including a
built-in digital camera, color display, and 3D graphics engine,
which can display images with total freedom of perspective. The
service’s 3D features are offered in the form of J-Phone’s original
equipment manufacturer (OEM) proprietary Java library.
Sumi Helal, Chapter 214
Standards, Tools, & Best Practices
Mitsubishi, Matsushita, NEC, Sony, Fujitsu, Toshiba, and Sharp
are among the main handset manufacturers in the Japanese market
(see Figure 2.5).
Figure 2.5. A small sample of commercially available Java-
enabled phones.
PART 1
As I discussed in the January–March issue, J2ME specifications are divided into configurations that are specific to different device categories. Each configuration is further divided into profiles, which are specifications of particular types of devices within a device category. For instance, the Connected Limited Device Configuration is targeted toward devices with limited network connection. The Connected Device Configuration is a more powerful configuration targeted towards devices such as set top boxes. See the last issue’s column for further details.
In the US, Motorola introduced the world’s first MIDP-compliant
Java phone, the Motorola i85s. Motorola was also the first handset
manufacturer to introduce Java phones to the North American
Sumi Helal, Chapter 2 15
Standards, Tools, & Best Practices
market. The J2ME phones, serviced mainly by Nextel
Communications, are based on the iDEN wireless technology and
are currently directed at business users. The iDEN Java phones
provide OEM proprietary support for TCP/IP and mobile
networking, which makes these handsets unique in the North
American marketplace. Phones can be serviced with routable,
static IPs (a form of mobile IP), which lets the phones serve as
both mobile application clients and as mobile servers. Motorola
plans to move other handsets (for example, PCS and GSM) to the
J2ME platform.
SPECIFICATIONS
The specifications of the i95s, the first color-enabled J2ME mobile phone introduced in North America, are
Airlink Interface: iDEN/TDMA
Carrier: Nextel Communications
Platform/configuration/profiles: KVM/CLDC 1.0/MIDP 1.0
Display: 8-bit color display with PNG and JPEG support
Memory: The i95s has data memory, program memory,
and heap memory. The phones are supplied with approximately 1.5 Mbytes of data memory, approximately 1.5 Mbytes of program memory, and 640 Kbytes of heap memory. Data memory is used as an initial download storage of MIDlets, persistent storage for MIDlet programs available through APIs, and voice recordings handled by the native phone OS. Program memory stores a program in an executable image format after it has been loaded from the data memory, expanded, and verified. Heap memory is used for runtime execution of programs.
Network protocols: UDP and TCP/IP (wireless packet data,
including server sockets) and routable IP addressing (HTTP as well as SSL and HTTPS)
Serial interface: Java Serial Interface API
In January 2002, Sprint Communications announced its plans to
use third-generation phones from Hitachi when it launches its 3G
Sumi Helal, Chapter 216
Standards, Tools, & Best Practices
service in the US later this year. Sprint’s next-generation 3G
network (known as 3G1X) will provide up to 144-kbit-per-second
wireless packet data streams.
In one of the most ambitious efforts yet to use Java in cell phones,
mobile phone maker Nokia has announced that it will ship 50
million Java-enabled mobile phones by the end of 2002 and 100
million by 2003. The Finnish company wooed its biggest
competitors to join a mobile phone standard plan that will put Java,
among other features, in next-generation phones. If Nokia goes
through with its plans, the company could effectively increase the
number of existing Java phones by over 30 percent.
For space limitation, I list specifications for only one phone—the
Motorola i95cl (see the “Specifications” sidebar). It is the first
color-enabled Java phone to enter the US market, and it has
roughly twice the performance and features as the Motorola i85s.
(It is worth mentioning that this doubling in performance occurred
over 14 months.)
2.2.2 Java-enabled PDAs
So far, the only profile supported in commercially available
devices is the MIDP. Its capabilities are intentionally limited and
cannot replace native applications on PDAs such as the Palm,
PocketPC, or Nokia 9210 communicator. Nevertheless, J2ME is
supported on some of today’s PDA platforms, including the Palm
OS, RIM BlackBerry, and Windows CE (see Figure 2.6).
The Java Community Process (JCP) is developing a new CLDC
profile specification geared toward PDAs. This PDA Profile is
supposed to offer greater sophistication than MIDP, including a
richer user interface. The PDAP aims to provide a standard set of
Sumi Helal, Chapter 2 17
Standards, Tools, & Best Practices
Java APIs for small, resource-limited handheld devices
characterized as having
No less than 512 Kbytes total memory (ROM plus RAM)
available for 86 PERVASIVEcomputing
http://computer.org/pervasive Comparison of J2ME tools and
development toolkits. Java runtime and libraries, and no more
than 16 Mbytes total memory
Limited power, typically battery operated
UIs of varying degrees of sophistication with displays that have
a total resolution of at least 20,000 pixels, a pointing device,
and character input
Palm is actively driving the formation of the PDAP (Java
Specification Request 75, http://jcp.org) through the JCP.
Unfortunately, the PDAP has been so long in the making that it
might be too limited for where PDAs are headed and might not do
justice to the capabilities of a high-end device such as the Compaq
iPAQ. We will have to wait and see, but PDAP might be too little,
too late.
2.3 J2ME DEVELOPMENT TOOLKITS
To make business sense out of this emerging technology, we must
create a profitable community of J2ME developers. Online
communities such as the Motorola iDEN Developer Community
(www.idendev.com) and the Sprint PCS Application Developer
Program (www. developer.sprintpcs.com) offer shared resources
and communication forums among their registered developers. In
addition, handset manufacturers, carriers, and specialized software
productivity companies are offering several J2ME development
Sumi Helal, Chapter 218
Standards, Tools, & Best Practices
toolkits that aim to accelerate the process of introducing new
applications.
Figure 2.6. Sample Java-enabled PDAs.
J2ME developers must consider several factors when deciding
which toolkit best suits their needs. Developers also must often
deal with multiple toolkits, so knowing how they differ helps. Of
utmost importance are quality device emulators that can reliably
test a J2ME application on prospective devices. J2ME applications
also must pass through a preverification process, which lets the
desktop compiler verify that the compiled code can run with
J2ME’s K Virtual Machine (J2ME toolkits include pre-verification
tools that handle this process). In addition, several other features
such as packaging and debugging also play a role in deciding the
toolkit. Finally, most quality toolkits come complete with J2ME-
specific documentation and sample applications.
There are several different configurations available for the
software development kits. Some software packages presented here
are full-fledged J2ME software development kits with integrated
development environments (IDE), some are only development
front ends, and yet others are J2ME plug-ins to Java development
environments.
The following comparison of the main tools and software
development kits should help clarify the key aspects a developer
Sumi Helal, Chapter 2 19
Standards, Tools, & Best Practices
must examine when selecting a development environment (also see
Table 2.1).
2.3.1 CodeWarrior 6.0
CodeWarrior from Metrowerks combines an IDE with the original
MotoSDK development environment from Motorola
(www.metroworks.com/desktop/ java). Its MIDP support evolved
from a set of tools called the J2ME SDK Components Developer
Edition, formerly maintained and distributed by Motorola.
Developers can develop, debug, and test MIDlets using the
familiar CodeWarrior IDE but with the convenience of a graphical
user interface and menu-driven commands (the original MotoSDK
was command-line only). In addition, Code-Warrior 6 has more
bug fixes and enhancements, and developers can use Motorola
phone emulators to test MIDlets. The SKD comes with a JAD and
JAR packager and a handy debugger and preverifier.
2.3.2 Zucotto Wireless Whiteboard SDK
The Zucotto Wireless Whiteboard SDK is a free IDE and
emulation environment for developers to create and deploy J2ME
applications (www. zucotto.com/whiteboard/product_
downloads.html). The basic version (as well as support) is free, but
if you want the Bluetooth version, it will cost you some money.
The Zucotto package is by far the best overall package. It even
comes with a PNG editor for creating and editing the PNG
graphics files to be displayed in your MIDlet. This IDE is derived
from the Net-Beans package, so the interface looks similar to
Sun’s Forte interface (also derived from NetBeans). The software
Sumi Helal, Chapter 220
Standards, Tools, & Best Practices
Sumi Helal, Chapter 2 21
Standards, Tools, & Best Practices
development kit is the first to extend Bluetooth functionality to
wireless Java application development. This will come in handy
for emerging phones with integrated Bluetooth. Some of the
distinctive features include seamless creation of jad/jar files,
source-level debugging with multilevel tracing, a PNG Painter to
create colorful MIDP-compliant images, excellent documentation
to simplify development, and easy-toreuse templates and code
samples.
2.3.3 Sun Forte for Java
Forte for Java is a complete Java development environment
available from Sun (www.sun.com/forte). The Community Edition
is free, but commercial versions are available that have more
powerful functionality. Forte for Java supports Java development
in general with a configuration section for specific libraries and
compilers. You can set it up for Java IDE to use different J2ME
plug-ins, but you must set up Forte before installing the plug-in.
Forte 3.0 requires Java 2 1.3.1. It also requires the Netscape
browser version 4.7 or above.
2.3.4 Borland’s JBuilder 5.0 Personal and Mobileset
Combining Borland’s JBuilder 5.0 Personal and its Mobileset add-
on package (www.borland.com/jbuilder/ mobileset) lets developers
create MIDP applications and test them using one of three toolkits:
Sun’s Wireless Toolkit (any phone), Nokia’s Developer’s Suite for
J2ME (Nokia phones), or the Siemens Mobility Toolkit (Siemens
phones). JBuilder contains perhaps the nicest GUI features, such as
“drag and drop” creation of MIDlets and their resources. Similar to
Sumi Helal, Chapter 222
Standards, Tools, & Best Practices
CodeWarrior and Whiteboard, Jbuilder and Mobileset include
prime features such as a packager, debugger, and device editor.
They also offer clear online documentation. A free personal edition
is available, but it doesn’t package the jad and jar files for you.
2.3.5 IBM VisualAge Micro Edition
VisualAge Micro Edition is an IDE with a comprehensive set of
tools and runtime components for developing and deploying Java
applications on connected embedded devices (www.embedded.oti.
com). At its core is the J9 virtual machine, which is a single-
sourced, multiple processor and platform combination, a feature
that increases virtual-machine quality and provides a portability
layer. The latter gives developers the flexibility they need to port
applications to new processors and platforms quickly and easily.
The new J2ME Java Powered compatible configurations
(MIDP/CLDC) let developers create devices that can host several
applications written to the specifications. The combination of
virtual machine and J2ME Java Powered configurations and
profiles delivered across multiple target platforms, along with
integrated tooling, is an industry first.
However, IBM’s IDE differs from the others covered in this
column. It is built from a previous version that lets embedded Java
developers create their applications targeting the IBM J9 JVM.
This new version also allows the creation of J2ME applications,
although there is no device emulator available for it yet. This is a
professional package, but it is not integrated well for developers
who want to get set up and running quickly. It appears to be more
suited for embedded Java development.
Sumi Helal, Chapter 2 23
Standards, Tools, & Best Practices
2.3.6 Sun’s wireless toolkit
Sun’s toolkit is most appealing because it comes from the Java and
J2ME creator (http://java.sun.com/ products/j2mewtoolkit). There
is a version for Solaris and Linux, but Sun does not fully support it.
I tested one of the Windows packages (Windows 98/NT/ 2K
supported).
The toolkit requires the Java 2 Standard Edition 1.3.0 or higher. It
does not come with an editor, but does come with a special GUI
for compiling, preverifying, jad/jar file packaging, and device
emulation. The default development environment that the toolkit
supports is known as Ktoolbar, which lets developers edit project
settings using a GUI and select from a range of emulators to test
the application. The Sun toolkit installs nicely, and the user guide
that comes with it gets you started quickly. It explains how to run
an example MIDlet and create your own using one of many
different templates.
Although KToolbar is a great first step for J2ME beginners, the
toolkit can also integrate with Sun’s Forte development
environment to provide a full-featured J2ME solution with
sophisticated IDE. At the University of Florida, my students
and I took one of our own MIDlets we wrote and used the Forte
IDE to create a new MIDlet suite and to compile and emulate it.
Everything worked smoothly. The emulator includes several
default “skins” such as a color- and grayscalescreen mobile phone
and a two-way pager.
The latest version of the toolkit (1.0.4 Beta) became freely
available just before this issue went to press. It seems to include
powerful features such as support for profiling MIDlet’s
performance (memory, networking, methods, and so forth) as well
Sumi Helal, Chapter 224
Standards, Tools, & Best Practices
as support for obfuscators. The new version also provides much
better options for defining parameters of the target MIDP device’s
virtual machine. This is a great feature for the developer, which
lets him or her match the emulator’s performance with that of the
target device.
2.3.7 Nokia toolkit (beta)
The Nokia toolkit, which is available for free, comes with a GUI
interface to compile, package the jad/jar files, and emulate Nokia
devices (http://americas. forum.nokia.com/java/default.asp). This
package can be integrated into Sun’s Forte for Java or Borland’s
JBuilder to provide GUI project management functions. The only
device emulator provided is Nokia’s emulator.
2.3.8 Siemens Mobility Toolkit (beta)
The Siemens Mobility Toolkit is a set of tools based around
Siemens’s SL45i and 6688i mobile phones (www. siemens-
mobile.com). The SDK has two versions, a SL45i version for
European markets and a 6688i version (both available for free),
which includes emulator support for Chinese characters. The SDK
includes an emulator, the CLDC and MIDP classes, Siemens-
specific classes, and documentation. It comes with its own
emulator as well as command-line tools for compiling and
packaging the jad/jar combination. We can integrate this package,
like Sun’s WTK and Nokia’s Toolkit, into Sun’s Forte for Java or
Borland’s JBuilder to provide a GUI project management
functions. The only device emulator provided is a Siemens
emulator. Several other features, such as a device editor, are not
present in this toolkit.
Sumi Helal, Chapter 2 25
Standards, Tools, & Best Practices
Several challenges and uncertainties face application developers
that could limit pervasive Java’s progress. However, challenges
often bring new opportunities for creative research and better
practices.
For practical reasons, developers extensively use a device emulator
(of the type and “skin” of a target device) throughout most of an
application’s development and testing cycles. This unavoidable
emulation could be a major source of discrepancy between the
behavior of a MIDlet running on a given device emulator and that
running on an actual device, which raises a serious uncertainty
problem for the J2ME developer.
Another unexpected problem facing developers is the potential
difficulty in porting MIDlets across different MIDP devices. Each
device manufacturer can add its OEM’s “exotic features” to MIDP
in the form of an API. This has quickly led to market
fragmentation, which is contrary to the portability spirit of Java.
Developers will have to weigh the benefits of specializing their
applications for a specific device against the ease of porting their
MIDlets across multiple MIDP devices.
Developers could face another serious problem if they are unable
to freely download applications to MIDP devices. Consider the
wireless telecom industry. Currently, carriers attempt to stick to
their business territories when they deal with pervasive Java. One
legitimate goal is to increase revenue streams by selling minutes
(or packets) to subscribers and businesses. Another goal is to
safeguard against losing any business due to the loaded
applications (imagine voice over IP over Bluetooth on the phone).
Toward these goals, carriers are actively pursuing control of
application distribution to their subscribers’ Java phones.
Developers must follow whatever procedures the different carriers
Sumi Helal, Chapter 226
Standards, Tools, & Best Practices
set forth to be allowed to download MIDlets to the phones. This
could range from a registration requirement to signing legal
contracts.
Finally, developers risk lack of support for network-side
developments (especially Web services) in their development
processes. Most development toolkits focus on the MIDlet client,
which is certainly important. However, networked applications are
bound to use a “proxy” between the MIDlets and the network
resources and Web services. There is currently no support
available for developers to create MIDlet proxies. Many
functionalities and responsibilities of a MIDlet proxy are common
or at least similar, leading to code redundancy. For example,
protocol and graphics conversion are two examples of simple
adaptation tasks that any MIDlet proxy will have to perform.
Integrating MIDlet proxy support into J2ME Toolkits will speed
up development of the full application. Of late, the JSP has
proposed a Java Specification Request to address this need (JSR
172, accessible from http://jcp.org).
Sumi Helal, Chapter 2 27
Standards, Tools, & Best Practices
The .NET Compact Framework
EDITOR’S INTRODUCTION
The .NET Compact Framework lets developers easily and efficiently build robust applications that call XML Web services, thereby letting end users effectively access remote data, cache it locally for use when offline, and interact with it via rich user interfaces. This invited piece, written by Microsoft’s Craig Neable, highlights the .NET Compact Framework’s design goals, sheds light on what the first version contains, and speculates on future directions. —Sumi Helal
Over the last decade, three noteworthy trends have occurred—the
intersection of which has naturally led to the development of the
Microsoft .NET Compact Framework.
The first trend was the popularization of sophisticated development
and runtime environments that increase developer productivity and
application robustness. These environments offer features such as
integrated type safety at runtime, memory management (including
garbage collection), and a standardized, rich programming
framework that implements commonly used functionality. Such
environments become even more powerful when coupled with
development tools specifically designed to host and target their
complementary runtime environments. Microsoft Visual
Studio .NET and the .NET Framework are such a combination,
released in February 2002 and targeting Microsoft Windows.
The .NET Compact Framework was a natural extension, bringing
this high-productivity environment to devices with more limited
resources than desktop PCs.
The second trend was the impetus to write applications that
provide information and services in a wider variety of situations
than previously associated with traditional PCs. Specifically,
developers started writing applications targeting small devices
Sumi Helal, Chapter 228
Standards, Tools, & Best Practices
including PDAs, mobile phones, and various other embedded
devices. One major barrier for developing applications on these
types of devices, however, has been the deficiency of developer
skills and knowledge. Both the .NET Compact Framework and
the .NET Framework are based on the ECMA Common Language
Infrastructure standard (see the “What Is the CLI?” sidebar). So,
both source code and compiled binaries can run across Windows-
based desktops and servers and various other devices and
processors, thereby offering improved productivity and efficiency.
This is not to say that applications written for a server would
necessarily be useful running directly on a device, but it is a
testament to the portability of programming skills between these
two different targets.
WHAT IS THE CLI?
The CLI is an ECMA standard. It defines how to create applications in multiple high-level languages that can execute in different system environments without rewriting applications to consider each programming language or runtime environment’s specific characteristics. The CLI specifies many things to abstract these differences, including a file format for executables, a type system, a metadata system for binaries, the Microsoft Intermediate Language executed in the common language runtime, and a definition of the required base class libraries and how they should be factored. For more information, see www.ecma.ch.
The third trend was that developers throughout academia and
industry recognized that the Web is a well-deployed infrastructure
over which they can effectively connect applications. Therefore,
they have congregated and collaborated to standardize protocols
for doing so including SOAP and WSDL (Web Service
Description Language). (See the “Glossary” sidebar for terms used
throughout this department.) These protocols, generally known
collectively as XML Web services, are redefining how we think
Sumi Helal, Chapter 2 29
Standards, Tools, & Best Practices
about distributed data. Like the .NET Framework, Microsoft
designed the .NET Compact Framework from the ground up so
that it could easily access remote data using these Internet standard
protocols. It thus puts smart devices on par with PCs in terms of
their ability to access such data.
With its general availability in early 2003, the .NET Compact
Framework will offer developers a familiar, safe, and robust
programming environment that increases productivity. Developers
can use skills that they deploy for desktop and server development
directly on devices. Microsoft designed the .NET Compact
Framework to perform optimally on resource-constrained devices
and to let it call XML Web services as a central and native
platform component. It will release the platform simultaneously
with tools functionality in Visual Studio .NET, allowing end-to-
end development for devices running Windows CE.
2.4 NUTS AND BOLTS
In contrast to the .NET Framework, which is available for the
desktop or server running Windows, the .NET Compact
Framework is designed to run on a variety of different operating
systems and has a unique architecture to provide for this cross-OS
functionality. Known as the Platform Adaptation Layer, this
architecture provides an abstraction layer between the host
operating system’s specific APIs and the .NET Compact
Framework’s requirements. In the future, the .NET Compact
Framework could easily be ported to other host operating systems
by creating a corresponding PAL to match the common language
runtime’s (CLR) requirements and the new host operating system’s
capabilities.
Sumi Helal, Chapter 230
Standards, Tools, & Best Practices
Built on top of the PAL (see Figure 2.7), the .NET Compact
Framework implements a CLR. The runtime can run Microsoft
Intermediate Language, a processor-independent, model operation
code language that the compiler emits. It does this using a just-in-
time compiler (JIT) to convert this MSIL to the specific
processor’s machine code. For each processor the .NET Compact
Framework supports, there is a corresponding runtime
implementation that JIT compiles and that runs the applications.
The .NET Compact Framework supports all of the processors that
the Windows CE operating system supports, including
StrongARM, MIPS, x86, SH4, XScale, and several other related
processors.
GLOSSARY
CLI Common Language Infrastructure
CLR Common language runtime
JIT Just-in-time compiler
MSIL Microsoft Intermediate Language
PAL Platform Adaptation Layer
WSDL Web Service Description Language
Built on top of the CLR is the programming infrastructure from
which the entire system gets its name, the .NET Compact
Framework. The .NET Compact Framework’s core is a set of CLI-
compliant base class libraries that provide building block
functionality for all applications including basic file I/O,
networking, and XML.
In addition to meeting these ECMA-defined specifications,
the .NET Compact Framework includes higher-level functionality
such as XML Web service support and a graphics and Windows
Forms library that exploits the graphics capabilities of the
Windows CE operating system and Microsoft Pocket PC. An
Sumi Helal, Chapter 2 31
Standards, Tools, & Best Practices
interoperability mechanism that manages calls between the CLR
and natively compiled system components provides access to the
Figure 2.7. The .NET Component Framework.
platform’s native software components. Finally, the .NET Compact
Framework implements ADO.NET, the data-access technology
available in the .NET Framework. This data-access model consists
of an in-memory relation store that easily persists on disk as an
XML file or mapped to a device or server database. This lets
developers access data easily from remote databases, handle it in
memory, store it in local sources, and synchronize local sources
with remote ones.
2.5 CHOOSING THE RIGHT
PROGRAMMING LANGUAGE
Like the .NET Framework, the .NET Compact Framework answers
the age-old question, “What language is best?” Its novel response
Sumi Helal, Chapter 232
Standards, Tools, & Best Practices
is, “It doesn’t matter!” All code is compiled first to MSIL and then
to native code. Therefore, how the MSIL was originally created
does not impact the JIT, so developers can choose the language
best suited to the task at hand.
Microsoft currently supports two languages on the .NET Compact
Framework; C# (pronounced C-sharp) and Visual Basic .NET.
Because of this sourcecode-agnostic platform, Microsoft or third-
party language vendors might eventually add support for other
languages to meet developers’ language preference demands.
Indeed, at the time of writing this article, several independent
language and tools vendors are implementing their own languages
on the .NET Compact Framework.
2.6 BRINGING BIG FEATURES TO
SMALL DEVICES
The fundamental problems in designing the .NET Compact
Framework revolve around one concept: how to redesign and
refactor the feature-rich .NET Framework, which is designed to
run on desktop PCs and servers. Machines running the .NET
Framework typically run on Pentium-class or higher processors
with copious memory, whereas the .NET Compact Framework’s
hosts are small devices with few megabytes of memory and
processing speeds that might not even reach the triple digits. Thus,
the design goals were twofold:
Decrease the system’s footprint from the 20-plus Mbytes that
appear on machines running Windows to approximately 1.5
Mbytes.
Sumi Helal, Chapter 2 33
Standards, Tools, & Best Practices
Optimize the common language runtime’s various components
to provide the fastest-possible execution time on small devices.
2.6.1 The foundation: Execution and memory
management
The common language runtime must use JIT to compile code to
run on the host device and manage the memory available to
maximize the device’s performance.
In the .NET Compact Framework, the optimized JIT compiles
from MSIL to native code on a method-by-method or type-by-type
basis. It does not compile a segment of MSIL containing a
particular method or type to native code until the first time it is
called. Once it compiles that method, it caches the natively
compiled code for later reuse. The obvious advantage to this
system—compared to an interpreter-based system—is that each
and every time a particular method is called, it does not need to be
recompiled but, rather, can run as instructions native to the
processor. This adds overhead on the first method call in a
particular instance of an application. However, this cost is
amortized over subsequent calls of the method, bringing the
execution close to native speed over the life of the application and
reducing battery consumption by running more efficient code.
To optimize the memory used for execution, the CLR also has the
prerogative in situations of extreme memory pressure to “pitch”
compiled code—that is, to throw cached code out of memory to
provide a larger space in which the application can continue to run.
This happens only in extreme situations, such as when the
application loads large volumes of data into memory. It lets the
Sumi Helal, Chapter 234
Standards, Tools, & Best Practices
CLR reclaim memory occupied by seldom-run code to store data
or cache code that is run more frequently.
Finally, the garbage collector cleans up after the developer, while
the running application allocates and discards objects and types.
The garbage collector is a simple mark-and-sweep collector that
periodically marks memory that is marked for edit—that is,
memory containing objects and types no longer in scope. When the
ratio of marked memory to in-use memory hits a certain threshold,
heap compaction occurs, creating larger open pieces of memory
that the runtime can reallocate to the application for either code or
data storage.
The obvious advantage to this system is that each time a particular
method is called, it does not need to be recompiled but, rather, can
run as instructions native to the processor.
2.6.2 The building blocks: The .NET compact
framework libraries
The base class libraries are the fundamental building blocks of
every application. These are the libraries that provide such things
as file I/O, collections, primitive drawing types, localization and
globalization, and XML handling. These libraries provide a great
deal of functionality without requiring developers to reimplement
commonly used functionality every time they undertake a new
project.
Sumi Helal, Chapter 2 35
Standards, Tools, & Best Practices
2.6.3 Making connections: Networking and XML
Web services
The most interesting device applications are connected, which is
why Microsoft made it easy to connect the devices and share data
between them. At the network stack’s lowest level, the .NET
Compact Framework exposes both synchronous and asynchronous
socket operations to developers. Built on top of this model is a
richer HTTP layer, which lets developers build applications that
leverage the biggest data network in the world—the Internet.
At the most functionally rich end of the spectrum, the .NET
Compact Framework implements the SOAP 1.1 protocol
specification, which lets developers call remote methods over
HTTP and programmatically deal with the information returned at
the application level. This functionality puts devices on par with
other machines in distributed network architectures. Finally, many
small devices are enabled with infrared functionality, and the .NET
Compact Framework has built-in support to let people establish
connections and move data to other devices over this simple peer-
to-peer transport.
2.6.4 Data is power: Data access
On top of the base classes sits the ADO.NET components that
allow data access and handling. In the first version of the .NET
Compact Framework, there are two data providers that let
developers interact with specific data stores. One data provider lets
developers access Microsoft SQL Server 2000 on remote servers,
and another lets them access SQL Server CE, a local database that
runs on the device. SQL Server CE lets developers cache large
Sumi Helal, Chapter 236
Standards, Tools, & Best Practices
volumes of data on the device such that the data can be used while
offline; SQL Server CE also provides a synchronization
mechanism back to SQL Server.
This proves to be a powerful combination for developers,
simplifying mobile data access. In a few simple lines of code, the
developer can pull large volumes of data on the order of tens of
Mbytes down to the device. The device can then read and update
the data while the application works in a disconnected mode. Then,
another simple line of code lets the device synchronize changes
made to this data with the original server.
2.7 CHALLENGES AHEAD
Many difficult challenges undertaken with the .NET Compact
Framework—in particular, the functionalityto-performance ratio
and size—have proven to be within the system’s capabilities, as
each new preview and beta release move closer to the original
goals. Furthermore, Microsoft will continue to add more features
and functionality, working around design constraints.
Although the .NET Compact Framework solves many mobile
development problems, it does not completely solve some
particularly interesting development areas. These are the
challenges that application mobility and distributed networks
present.
One interesting and compelling problem the .NET Compact
Framework will continue to pursue through future releases is
increasingly better adoption of mobilephone-specific technology.
The types of functionality specific to mobile phones include using
text messages as a data transport between devices. Also, network
Sumi Helal, Chapter 2 37
Standards, Tools, & Best Practices
conditions over which devices—especially mobile phones—must
communicate typically tend to be more transient and unreliable
than traditional, permanently connected PCs. Other interesting
areas of development, however, do not completely pertain to the
implementation of the .NET Compact Framework but rather to the
challenges presented by application mobility and distributed
networks in general.
Another important area where the .NET Compact Framework will
strive to add value is in implementing and abstracting the ever-
emerging relevant standard protocols for sending data, messages,
and services to mobile devices over the network. Today, it is
difficult to move data to devices regardless of the particular
network the device is on, because simply addressing a device that
changes an IP address is frequently challenging. Because mobile
devices inherently have some of the greatest networking
requirements, they will be a strong testing ground for APIs that
support programming to these standards.
Finally, .NET Compact Framework development will continue to
extend into other form factors of devices. While the majority of
development with the .NET Compact Framework is likely to be on
PDAs and high-level mobile phones, other types of devices will
come into focus as demand grows for a rich
Because mobile devices inherently have some of the greatest
networking requirements, they will be a strong testing ground for
APIs that support programming to these standards.
development environment that is efficient for programming. This
presents perhaps the biggest challenge to the .NET Compact
Framework’s future development—to maximize portability of
applications and programming skills among different device form
Sumi Helal, Chapter 238
Standards, Tools, & Best Practices
factors without compromising the ability of applications to exploit
the unique and powerful resources for each of these different
platforms and form factors. Developers will want to minimize the
differences between similar applications for maintenance reasons.
However, applications that run identically on all form factors of
devices do not take full advantage of any of those platforms, so
they do not give end users the most dynamic application
experience. Providing the right level of abstraction of common
features has been—and will continue to be—one of the greatest
challenges, minimizing development efforts and maximizing end-
user experiences.
ith its release in early 2003, the .NET Compact Framework will
give devices the functionality that developers have come to expect
from modern, safe PC environments. The .NET Compact
Framework replicates this functionality so well that at a source-
code level, it is often impossible to tell whether the code was
written for a PC running the .NET Framework or a mobile phone
running the .NET Compact Framework. The .NET Compact
Framework lets developers take existing code and investment in an
application built for a PC and, with little modification, run it on a
variety of smart devices. It also lets devices participate in network
architectures on parity with other machines by letting them easily
consume XML Web services, display and process data locally, and
synchronize data back into the original source. The ultimate goal is
to open an entirely new opportunity for software developers
worldwide, letting them efficiently create solutions in the new and
exciting realm of mobile applications.
Sumi Helal, Chapter 2 39
Standards, Tools, & Best Practices
WAP: Present and Future
In 1997, several wireless-phone manufacturers organized an
industry group called the Wireless Application Protocol forum.
This group defined the WAP specification in the form of a long,
describes technical document series that defines standards for
implementing wireless-network applications. Hundreds of
industries strongly supported the WAP forum for standardization
to help the technology become widely adopted.
Unfortunately, most of the enthusiasm surrounding WAP has
evaporated owing to inherently low channel bandwidth, increased
round-trip delays, and a lack of security. WAP technology is
primitive and still evolving, and its future depends on how quickly
it can improve the transfer rate and effectively enhance its business
model.
2.8 THE WAP ARCHITECTURE
In the last few years, WAP has emerged as a standard Internet-
enabling wireless protocol and a browser framework for small,
limited-display-capable devices. WAP allows Internet access to
cell phones, PDAs, and other low-computational-power devices. In
addition, the lightweight WAP protocol has a layered architecture
and is designed to operate over a variety of wireless services,
including Code Division Multiple Access, Cellular Digital Packet
Data, General Packet Radio Service (GPRS), and so on.2.1 (For
more information on the layered architecture, see the “WAP
Layers” sidebar.)
Sumi Helal, Chapter 240
Standards, Tools, & Best Practices
Based on Internet standards such as HTTP, WAP wireless
protocols2.2–2.4 require transferring large amounts of mainly text-
based data. The WAP standard consists of two essential elements:
an end-to-end application protocol and an application environment
based on the browser. The application protocol is a communication
stack embedded in each WAP-enabled wireless device (also known
as the user agent). The server side defined as a WAP gateway
implements the other end of the protocol, which can communicate
with any WAP client.
The WAP network structure (see Figure 2.82.5) sets up a session
using these steps:2.6,2.7
1. A mobile telephone sends WAP requests to a WAP gateway.
2. The gateway, upon receiving a WAP request, sends an HTTP
request to a plain Web server, which provides the content
through a normal HTTP response (the Web server perceives
the gateway as a proxy server).
3. The gateway converts the HTTP response into a WAP response
for the mobile device.
4. The microbrowser in the mobile terminal interprets the
response and displays it appropriately.
2.9 WAP SUPPORTING COMPONENTS
WAP technology has three major supporting components. The first
is the Wireless Markup Language. WML is the WAP equivalent to
HTML and is based on XML.2.8 It makes optimal use of small
screens, with a built-in scalability from two-line text displays to
the full graphic screens on smart phones and communication
devices. The Wireless Application Environment specification
Sumi Helal, Chapter 2 41
Standards, Tools, & Best Practices
defines the syntax, variables, and elements used in a valid WML
file. WML employs the concept of decks and cards. Each card is a
frame displayed on the screen. We refer to a logical collection of
interlinked cards as a deck, usually stored in a single WML file.
The second is WMLScript, a client-side scripting language used
with WML that makes WML pages dynamic (similar to what
JavaScript2.9 allows with HTML). WMLScript makes minimal
demands on memory and CPU usage, omitting a number of
functions that are not required and that are present in other
scripting languages for wireless applications. Regular scripting
languages are resource intensive and can’t be used to display
interactive pages on a mobile phone. WMLScript is a scaled-down,
simplified script, developed specifically to fit the WAP
architecture of decks and cards. It lets the developer provide inter-
activity in WAP pages without taxing the valuable wireless
resources.
The third supporting component is Wireless Bitmaps. WBMP is
the default picture format for WAP. WBMPs are uncompressed,
monochrome blackand-white bitmaps for use in devices with small
screens and narrow bandwidth connections (see Figure 2.9).
However, the screen size and bandwidth, along with limited
graphics capabilities, are WBMP’s major constraints. Recent
developments in display technology provide color bitmaps for the
latest WAP browsers.
WAP LAYERS
The WAP protocol stack has five layers: application, session, transaction, security, and transport (see Figure A1). Each layer performs almost the same functions as the corresponding layers of the Internet model.
Application
The application layer consists of the Wireless Application Environment
Sumi Helal, Chapter 242
Standards, Tools, & Best Practices
and user agents. The most common type of user agent in the WAP architecture is a browser meant to interpret Wireless Markup Language and WMLScript. User agents that endeavor to provide services beyond those of a browser generally take advantage of the WAP specification’s Wireless Telephony Application features.
Session
The Wireless Session Protocol presents the application layer with a way to uniformly receive both “reliable” connection-oriented and “unreliable” connectionless transmissions.The WSP facilitates transmission mechanisms such as
• Providing HTTP functionality
• Enabling users to participate in long-lived data transmission sessions
• Allowing a server application to determine whether a client can support certain protocol facilities and configurations (this is known as “a capability negotiation”)
Transaction
The Wireless Transaction Protocol handles requests and responses to and from the user agent to the application server. The WTP concentrates on transaction services for online activities such as Web browsing. It is designed to decrease the number of transaction phases that typical wired-oriented protocols require.
Sumi Helal, Chapter 2 43
Standards, Tools, & Best Practices
Figure A. The five Wireless Application Protocol layers.1
Security
The Wireless Transport Layer Security implements many features to ensure secure data transmissions and to protect the users, the network and service operators, and the functionality of the upper layers of the WAP stack. The WTLS provides safe data transmission that could support services requiring a high level of security such as mobile e-commerce.
Transport
The Wireless Datagram Protocol transmits and receives data to and from the user agents. The WDP can exchange information with many types of wireless data carrier technologies or “bearers.” It effectively hides the differences in bearer technologies from the rest of the stack and provides a common interface to the upper-layer protocols. Layers can function independently of the underlying network and the wireless devices.
REFERENCE
1. D.P. Agrawal and Q.-A. Zeng, Introduction to Wireless and Mobile Systems, Brooks/Cole Publishing, Pacific Grove, Calif., 2003.
2.10 WAP ADVANTAGES
Many inherent WAP characteristics offer major advantages. First,
WAP saves time and money. A WAP-based application’s ability to
send and receive data in real time lets companies make field
changes and coordinate their staff more efficiently. Companies can
also speed up and automate their distribution cycle, thus
minimizing the required manpower.
Second, there’s no hardware obsolescence. One of the greatest
concerns for companies with mobile workers is the huge
investment in handheld hardware. Companies would be interested
Sumi Helal, Chapter 244
Standards, Tools, & Best Practices
if the standard could work on legacy hardware. This would help
them increase the lifetime of their prior ter decision-making and
enhanced business performance.
In addition, WAP’s invention has led to the development of WAP
telephony applications that add a telephony element to the basic
WAP infrastructure and make existing wireless network
capabilities available to enhance WAP services. WTAs provide a
framework for integrating wireless data and voice capabilities to
create innovative services.
Figure 2.8. A Wireless Application Protocol network architecture.
2.11 WAP CRITIQUES
Just as there is no dearth of WAP supporters, the number of WAP
bashers is growing. WAP technology is not flawless, and criticism
Sumi Helal, Chapter 2 45
Standards, Tools, & Best Practices
from leading technologists fall into the following categories.
Figure 2.9. Two images: (a) normal and (b) Wireless Bitmap.
2.11.1 WAP as a band-aid
WAP critics say that WAP is only a temporary fix. We will need it
only until greater bandwidth in the communication channel and
increased functionality in the personal terminal are widely
available. GPRS-enabled PDAs, which deliver
28.8 kbps, are already hitting the European market. Carriers such
as Verizon and Sprint are building 3G networks capable of
handling data and video.
2.11.2 Wrong bearer services
WAP is expensive when used with current bearer technologies.
With circuit-switched data, we can expect long connection calls for
any application that uses interactivity with the Internet or that lets
the user select more information.
2.11.3 Weak link
The WAP gateway must decrypt secure data coming from a caller
using Wireless Transport Layer Security, and then it must re-
Sumi Helal, Chapter 246
Standards, Tools, & Best Practices
encrypt the data before forwarding it to the bank or credit card
company (or anyone else receiving it). The reverse must also be
maintained. There is a window of vulnerability when the data is
momentarily unencrypted.
2.11.4 WAP designer’s nightmare
One of the biggest problems WAP developers face is that their
applications will likely be rendered in many different ways on
different mobile phones. Old WAP browsers support HDML
(Handheld Device Markup Language); later browsers support
WML. Different browsers treat certain tags and commands in
different ways, and myriad devices with the same browser also
function unpredictably. Generally, this lack of coordination among
handset providers, browsers, emulators, and the WAP standard
creates a frustrating environment for even the best developers.
2.11.5 User experience
So far, WAP has not lived up to its promise of being an exciting
way to access the Internet. Tradeoffs between functionality,
performance, and design have dampened user experiences. WAP
applications with broken links seem to be the norm, not the
exception. Some people have difficulty just figuring out how to
access the microbrowser on their mobile handset. Furthermore,
after waiting for 30 to 45 seconds to connect, users find what looks
like a walled garden that allows access only to certain sites. Access
to options such as “go to other sites” is cumbersome and
frustrating. Inputting a valid WAP URL through the existing
numeric keyboard is tedious.
Sumi Helal, Chapter 2 47
Standards, Tools, & Best Practices
2.11.6 Killer applications
The hype involving WAP has centered on the killer applications,
which were touted to herald a new era of mobile commerce.
However, even after almost five years of WAP development, a
stable killer application has yet to see the light of day. Many have
not yet been developed or, if developed, have not been marketed
well enough to catch consumers’ attention.
2.11.7 Pricing
The pricing of WAP services has been problematic for both
developers and consumers. On the developer side, operators have
not shared the wealth with content providers and have essentially
made it difficult for content providers to get any sort of valid return
for their efforts. No true, measurable incentives exist to develop
WAP content in the absence of wireless advertising and other
revenue agreements.
Many carriers offer an expensive flat-rate pricing fee to consumers,
in addition to subtracting voice minutes for time spent on data.
This impacts WAP services in two ways. First, carriers have no
efficient mechanism to establish fair revenue sharing with content
providers. Second, consumers are historically price-sensitive in the
services industry and view WAP as too expensive. An example of
how a correct business model can help WAP is Telesim, Turkey’s
second-largest GSM operator. It eliminated its monthly fee for
WAP usage and experienced a tenfold growth in its subscribers.
Sumi Helal, Chapter 248
Standards, Tools, & Best Practices
2.12 THIN VERSUS FAT CLIENTS
WAP, also implemented as a thin client, uses a centralized server
to store, fetch, and send data. The meager storage and low-memory
capacity would be sufficient to run varied applications using a thin
client. Remote-server-handling capability depends on the
bandwidth of the communication media between the server and the
client. On the other hand, fat clients implemented by Java 2 Micro
Edition and the .NET Compact Framework make storage and
processing more local than done remotely (for more information
on J2ME, see the Jan.–Mar. and Apr.–June 2002 installments of
this department; for information on .NETCF, see the July–Sept.
2002 installment). Fat clients require large memory and storage
capacities.
Each client type has its advantages and disadvantages. However, it
is difficult to say which is better, because both are application
oriented and the technology is constrained by technological
limitations. Whether wireless messaging should employ a thin or
fat client is still debatable.
The obvious disadvantage of a thin client might be its limited
feature set, which could worsen user experiences. Fat clients face
the storage constraints and limited processing power of mobile
devices. Applications such as the Virtual Private Network
(www.vpnc.org) and Virtual Network Connectivity (www.uk.
research.att.com/vnc) have allowed virtual access to desktops from
any computer. These technologies rely on the large bandwidth of
the wired medium. Much research has shown that thin-client
technology for desktops might not be a good practice for PC
management.2.10
Sumi Helal, Chapter 2 49
Standards, Tools, & Best Practices
The latest developments in memory and storage technologies for
handheld devices are enabling fat-client architecture by reducing
the burden on the bandwidth, because local processing would
eliminate some of the data transfer done at the remote server.
Because mobile devices go wherever we go, WAP technology
makes them suitable for the current storage, memory, and
processing capabilities of mobile devices. Unless there are
astronomical advances in the wireless medium to allow larger
bandwidths, fat clients seem to be the way to go for future
handheld devices.
AP optimists have been quick to rebut WAP shortcomings. WAP
security has been enhanced in the new version 2.0, and most
shortcomings have more to do with an inadequate business model
than the WAP technology itself. Also, analysts suggest that if
WAP is incompatible with current technologies, GPRS might
make it more practical.
WAP is an application protocol suite designed to function over any
bearer service. This is where GPRS comes into practice as an ideal
bearer for WAP resource requirements; its higher transfer rates are
needed to accommodate WAP’s unusually complex and frequent
network resource requirements. Furthermore, the increased
bandwidth will allow better and more varied applications with
pictures, video, and sound. Japan and South Korea are already
carrying packet data on their networks, and Europe is adhering to
the GSM standard
with many confirmed GPRS contracts. WAP technology could
bring about the convergence of mobile communications and the
Internet. With any newtechnology come risks, bugs, and
opportunities. With WAP, the opportunity and adventure definitely
outweigh the risks. However, WAP has not lived up to its lofty
Sumi Helal, Chapter 250
Standards, Tools, & Best Practices
expectations, and its growth has taken a beating. In responding to
the recent backlash against WAP, advocates quickly point out that
WAP exists today in a very primitive form.
Still, with the introduction of much faster bearer services such as
GPRS or UMTS and a proper consumer-oriented business model,
the struggling WAP might just get a much-needed lifeline.
Sumi Helal, Chapter 2 51
Standards, Tools, & Best Practices
Surviving Java for Mobiles
Mobile devices are gaining popularity worldwide, and constant
hardware improvement is increasing their computational power
every year. So, we can now equip mobile devices with more
powerful applications.
One of the most promising software platforms for mobile devices
is Java 2 Micro Edition. Sun representatives assert that 18 to 20
million mobile phones support the J2ME platform.2.11 Analysts
predict that within the next few years, this technology will become
omnipresent. According to Gartner Group estimates, in 2006,
approximately 80 percent of mobile phones will support Java.2.11
(For an introduction to Java for mobiles, see the Jan.–Mar. 2002
and Apr.–June 2002 installments of this column).
In our experience in creating applications for Java-enabled mobile
devices, we’ve had to deal with several unforeseen problems not
typical of desktop Java development projects. Unfortunately,
literature on the subject has only fleetingly mentioned most of
these problems. Here, we describe some of them and propose our
solutions.
2.13 DEVELOPING JAVA
APPLICATIONS FOR MOBILE
DEVICES
Software development is always constrained by the target
platform’s capabilities. This is especially true for the “ultralight”
Sumi Helal, Chapter 252
Standards, Tools, & Best Practices
J2ME platform, because developers face many difficulties related
to the platform’s physical limitations. These difficulties include:
The size of the application and its data (many business-class
mobile devices with more memory exist, but size is still a
problem for an overwhelming majority of phones— including
mass-market phones currently produced for entertainment
purposes and “legacy” phones still widely used)
Intermittent network connections with lower bandwidth
Small display size, which can cause problems for creating an
acceptable user interface
Primitive facilities for inputting text information
All these distinctive J2ME features are defined in the Connected
Limited Device Configuration (CLDC), which provides
specifications for all Java-enabled mobile phones and most PDAs.
2.13.1 Games for J2ME devices
Our first J2ME development projects were games for Java-enabled
mobile phones.
The initial task was to develop a demo application for illustrating
J2ME platform capabilities. We borrowed the first game’s script
from a traditional computer game, in which the user controls a
submarine and tries to destroy all enemies without dying (see
Figure 2.10). The game could store the best records and update
them using an HTTP server. It used a true-color image set and
looked best on mobile phones with a color display.
Sumi Helal, Chapter 2 53
Standards, Tools, & Best Practices
For the second game, we implemented an original scenario from
our client company in which the user controls a balloon. The goal
is to travel from the starting point to the terminal without colliding
with hills, birds, and so forth. For this game, we created a map
editor for the various levels to provide a user-friendly interface for
game designers and to store the data in a compressed binary form.
The main problem we encountered when developing these games
was minimizing each game and its data’s size to produce an
acceptable start-up time. For instance, the application size limit for
most popular Java-enabled phones was approximately 30 Kbytes.
However, remaining within this size limit using the usual coding
approaches is practically impossible. For example, the first version
of Submarines was 41.5 Kbytes.
We tried carrying out the optimizations Eric Giguere describes in
“Optimizing J2ME Application Size” (see
http://wireless.java.sun.com/midp/ttips/ appsize), but the resulting
code was still 37 Kbytes. To overcome this, we developed a new
technology for optimizing the size of standalone J2ME
applications.
2.13.2 Optimizing standalone J2ME applications
Our approach suggests that after creating the application’s initial
version, you must transform it by merging classes. Technically
speaking, we perform this by applying the inline class refactoring
pattern,2.12 even though the reasoning behind this transformation is
completely differ ent. In our case, this transformation’s main goal
was to remove all user-defined classes from the program so that
the final version would contain only standard classes that deal with
Sumi Helal, Chapter 254
Standards, Tools, & Best Practices
Figure 2.10. The Submarines (version 1.0) game for a Java-
enabled phone.
the user interface, display, timer, and so forth—that is, only the
indispensable minimum. In the case of Submarines, this
transformation had spectacular results: it reduced the application to
21 Kbytes.
We illustrate this refactoring on a small example adapted from a
real program (see Figure 2.11). The changes amount basically to
merging the user-defined classes with standard ones, creating new
interfaces, and moving methods to the new class.
After completing this transformation, however, achieving any
other significant decrease in size (that is, more than 1 Kbyte) is
hard. One of the still useful optimizations is obfuscation, which, in
this application domain, amounts to changing long identifiers to
shorter ones. In the case of Submarines, this optimization reduced
the size by 1.7 Kbytes to 19.3 Kbytes. Later, we managed to
further reduce the size to 18 Kbytes using the data-compression
techniques we tested while optimizing the second game.
Even though we developed the second game using the
optimizations just described, the first version was still too large for
the target platform (about 30 Kbytes). The problem was the
auxiliary data—including the layout of levels and graphics—which
formed more than 60 percent of the total application size. To
further reduce the application’s size, we wrote a WYSIWIG editor
Sumi Helal, Chapter 2 55
Standards, Tools, & Best Practices
for editing game levels that compressed the data into a binary
format. We also wrote a compression tool for graphics that pasted
the images together to optimize the ZIP algorithm used in Java
archive (JAR) files.
The compression tool, written in Java, takes a list of files as input
and produces two files as output. One output file is a simple
concatenation of all input files; the other is a hash table. This hash
table’s key is the relative path to the file from the JAR archive’s
root, and all keys point to the offset from the archive’s beginning
and the original file’s length.
Using a binary format to store the levels and using the archivator
for the images helped reduce our second game’s size to 22.4
Kbytes. The reason for the reduction is that the ZIP algorithm
creates a separate dictionary for every file. This approach yields
good results compressing large homogeneous files, but our case is
different. First, files with level descriptions are small (fewer than
100 bytes) and already compressed with a simple algorithm.
Second, the images are already stored in a PNG format, which also
uses a ZIP algorithm for compression. (The original reason for
using the PNG format for images on mobile devices was to avoid
implementing additional algorithms, thus reducing the Kilobyte
Virtual Machine’s size.) So, we can reduce the size only by
compressing the class headers, while the individual images can
even increase their size. File concatenation solves this problem.
From the programmer’s viewpoint, the decrease in application size
is not immediately clear; it becomes apparent only after generating
the corresponding JAR files. The development tools carry out
some optimizations, thus making them transparent to the
programmer. We hope that, in time, development tools will also
fully support the optimizations described here.
Sumi Helal, Chapter 256
Standards, Tools, & Best Practices
2.13.3 Portability issues
Universal portability is one of Java technology’s strongest points.
Unfortunately, ensuring J2ME application portability in practice is
quite difficult. Portability problems arise mostly because the
capabilities of various J2ME devices differ significantly. For
instance, there are different screen sizes (24 among existing J2ME
devices), both black-and-white and color screens with various
color depths, fundamentally different audio features, and so forth.
Therefore, J2ME applications developers must plan for portability
beforehand. “Write once—run anywhere” does not work for a
J2ME platform. You might argue that the portability of J2ME
applications is more similar to the portability of C++ programs
than that of mainstream Java programs: developers must take
special care to ensure that their programs work on more than one
J2ME device.
We encountered the portability problem while writing the games
described earlier. We managed to resolve it by reducing everything
to the basic setup.
For example, we adapted all images to the smallest existing screen
size. As another example, torpedoes are always launched from the
edge of the screen in the Submarine game, independent of the
screen size—see the following code snippet:
protected void paint(Graphics g) {
Rectangle clip = new Rectangle(
g.getClipX(), g.getClipY(), g.getClipWidth(), g.getClipHeight());
<...>
}
Sumi Helal, Chapter 2 57
Standards, Tools, & Best Practices
Figure 2.11. (a) The original version of a program’s code and (b)
the optimized version.
This design decision has a side effect: a player using a device with
a bigger screen has more time to avoid a coming torpedo. Of
course, we could compensate for this by moving the torpedo
proportionately to the screen size at every tick.
Sumi Helal, Chapter 2
public class PilotMidlet extends MIDlet { private PilotDisp displayable; public Display display; /** Constructor */ public PilotMidlet() { displayable = new PilotDisp(); } /** Main method */ public void startApp() { display = Display.getDisplay(this); display.setCurrent(displayable); }<...> public static void quitApp() { destroyApp(true); notifyDestroyed(); }}public class PilotDisp extends Form implements CommandListener { public string content; private TextBox tb; private PilotMidlet pilotMidlet; private Command exitCommand = new Command("Exit", Command.EXIT, 1); private Command editCommand = new Command("Edit", Command.ITEM,2); private Command okCommand = new Command("OK", Command.OK,1); public PilotDisp(PilotMidlet _pilotMidlet) { super("Compression Demo"); pilotMidlet=_pilotMidlet; content = "LANIT-TERCOM"; tb = new TextBox("Edit", content, 50, TextField.ANY); tb.addCommand(okCommand); append(content); jbInit();}/**Component initialization*/ private void jbInit() { setCommandListener(this); addCommand(exitCommand); addCommand(editCommand);}
(a) (b)
public class PilotMidlet extends MIDlet implements CommandListener { public string content="LANIT-TERCOM"; private TextBox tb = new TextBox("Edit", content, 50, TextField.ANY);; private Command exitCommand = new Command("Exit", Command.EXIT, 1); private Command editCommand = new Command("Edit", Command.ITEM, 2); private Command okCommand = new Command("OK", Command.OK, 1); private Form displayable = new Form("Compression Demo"); public Display display;
/** Constructor */ public PilotMidlet() { displayable.append(content); addCommand(exitCommand); addCommand(editCommand); tb.addCommand(okCommand) setCommandListener(this);}
/** Main method */ public void startApp() { display = Display.getDisplay(this); display.setCurrent(displayable); }
<...>
/** Quit the MIDlet */ public void quitApp() { destroyApp(true); notifyDestroyed(); }
58
Standards, Tools, & Best Practices
The screen size is more important for the balloon game, because
the complexity of its graphics exceeds the display capacity for
typical screen sizes. We solved this problem by fixing the image
width at exactly 100 pixels (the width of the smallest screen for
J2ME devices) and by implementing vertical scrolling to support
devices with either a small or large vertical screen size. We also
decided to use only black with a transparent background for
images. All these measures highly improved the game’s general
portability.
Later, we carried out compatibility testing of our games on several
J2ME devices. The tests confirmed that the programs perform well
on different Siemens, Nokia, and Samsung phones. However, this
is not because of J2ME’s universal portability but because of
deliberate advanced planning of all features. Clearly, we can solve
J2ME portability problems only through strict standardization of
the platform’s numerous parameters.
2.14 NETWORK APPLICATIONS
FOR THE J2ME PLATFORM
Standalone one-user games for Java-enabled phones is an
interesting and fast-growing application area, but the J2ME
platform can support more sophisticated applications. The J2ME
platform’s eventual success will depend on the sufficient quantity
of network applications taking advantage of location awareness.
These applications include, for example, systems for ticket
reservations, data backup and restoration, customer relationship
management, supply chain management, city navigation, and so
forth. Even the games we’ve mentioned could benefit from
supporting multi-user modes.
Sumi Helal, Chapter 2 59
Standards, Tools, & Best Practices
However, various difficulties, some typical for distributed
information systems and some J2ME-device specific, hamper the
development of network applications for the J2ME platform.
2.14.1 Distributing information between the client
and server
One of the first issues of information system design is optimizing
the distribution of information between the client and server for
speed and convenience. Consider a corporate information system
for a typical insurance company, which usually includes one or
more corporate servers and numerous salespeople equipped with
notebooks, PDA-size devices, and mobile phones. One of the most
difficult problems is supporting data sharing in a mobile
computing environment with a less than ideal (and perhaps
expensive) connection. Requirements for the architecture of such
systems have been enumerated elsewhere.2.13 In our case, they
translate into the following guidelines.
First, to reduce client idle time and ensure that the user can work in
a standalone mode (even in case of temporary loss of network
connection), implement data caching. However, mobile devices are
constrained in resources, so you should apply efficient cache
management techniques, such as semantic caching,2.14 to minimize
network traffic.
Second, to improve the server’s availability, use data replication.
The network’s intermittent nature hampers this process, but you
can overcome it using “epidemic” algorithms for update
propagation (such as an “anti-entropy” protocol5).
Third, to ensure data consistency and resolve various types of
conflicts, the application server keeps track of all data changes
Sumi Helal, Chapter 260
Standards, Tools, & Best Practices
during synchronization. Typically, a transactional model is not
well suited for mobile applications owing to the frequent
disconnection of the devices, which leads to numerous transaction
aborts. One way to resolve this problem is to use optimistic locking
techniques, although it decreases the application’s efficiency and is
not suitable for most tasks. Alan Demers and his colleagues have
proposed another technique based on the so-called merge proc
procedure for conflict resolution on both sides during
synchronization. The developers should implement this procedure
for the task at hand.2.13
However, a more feasible approach would be simply to reduce the
transaction length by committing the data as often as possible (or
as is practical).
Finally, using direct access to the database resolves most conflicts
on the application side. This improves the application’s flexibility
but reduces efficiency.
2.14.2 Sending information between the client and
server
Some data shuttling between the client and server is inevitable,
regardless of decisions on data distribution. Consequently, we must
answer the following questions related to implementing the
fundamental approaches described earlier:
How can we optimize dataflow and increase the efficiency of
data delivery through the network?
What data format is more applicable for data sending and
representation? (This is especially important for structured
data, such as database records, email messages, and news.)
Sumi Helal, Chapter 2 61
Standards, Tools, & Best Practices
How can we ensure data synchronization—for example, update
propagation—among different devices in practice?
The resulting algorithm would require sending the same
information over and over again until we receive confirmation or
we time-out (in which case the network is unstable, so we must
work locally). However, this algorithm is too costly if the network
connection is stable.
The first of these limitations questions should not present any
serious problems, because data transfer rates in 2.5G networks
with General Packet Radio Services (GPRS) support can
theoretically be as high as 170 Kbits/s. Although in practice this
value is rarely reached, the typical transfer rates, which are from
30 to 60 Kbit/s, should suffice for transferring even quite large
amounts of information.
For simple tasks, such as transmitting the user’s choice or simple
commands, we can use symbolic abbreviations. For example, in
multi-user dungeons, we could easily transform the user navigation
commands into sequences such as ($c*3$b*2$). On reception,
these sequences are easily restored to the original form or
converted to some other structured format on the server side.
Still, for purely structural data, such as news, contact information,
or appointments, the most convenient medium is a structures
description language. The most widespread and proven standard
for structured data representation is XML, but unfortunately the
standard classes of CLDC/MIDP do not support it. We could
attribute this to the fact that the first good implementations of
XML for mobile devices appeared only after J2ME’s initial
release. Nevertheless, plenty of useful libraries exist for this
Sumi Helal, Chapter 262
Standards, Tools, & Best Practices
purpose. For example, kXML (http://kxml.enhydra.org) is free and
provides a transparent solution for compression and transfer of
XML files. NanoXML/Lite (http://nanoxml. n3.net) doesn’t
support mixed content or DTD but is extremely small and efficient.
In recent years, SyncML has become a defacto standard for the
technical implementation of data synchronization among various
devices (see www.syncml. org). This standard intends to provide
for every eventuality; for instance, it includes a language for
describing new devices (SyncML Device Information DTD). Still,
using this standard is sometimes difficult in practice owing to the
target device’s low processing power and memory shortage.
2.14.3 Protecting sensitive information on mobile
devices
Modern information systems demand high levels of security and
data protection. In practice, this means that we must spell out
policies for handling a customer’s private information. For
instance, health care applications in the US must adhere to certain
information policies (most notably, the Health Insurance
Portability and Accountability Act of 1996), so we must take
special measures to guarantee the security and privacy of health
information in these applications. At the least, cached information
should be flushed on exit from the application— we could achieve
this in J2ME by performing an explicit call to the System.gc()
method.
Another consideration for protecting sensitive information is that
the data transferred over the network must be cryptographically
protected. Consider the following scenarios from the data
protection viewpoint. First, an adversary can eavesdrop on the
Sumi Helal, Chapter 2 63
Standards, Tools, & Best Practices
information transferred over the network. To protect from this
attack, we can use Secure HTTP protocol, which is based on a
secure sockets layer and is supported by most mobile network
providers.
Second, a mobile-device user might need strong cryptographic
algorithms or protocols to fulfill certain everyday tasks. For
instance, strong cryptography is required for authentification, key
exchange, or protection from adversaries getting hold of the mobile
device. Usually, the main problem in this case is the lack of
resources necessary to implement cryptographic algorithms and the
network connection’s low bandwidth—for example, today’s
typical mobile device doesn’t have enough processing power to
generate a 1,024bit RSA key in a reasonable time. So, a pressing
need clearly exists for new algorithms or efficient implementations
of the existing cryptographic schemes.
Researchers have already taken some steps in this direction. For
example, the BouncyCastle library (www.BouncyCastle.org)
implements several block and stream encryption algorithms (the
Data Encryption Standard, Blowfish, Rijndael, and RC4), as well
as algorithms for digital signatures and key exchange (Pretty Good
Privacy, IDEA, RSA). Research in the area of distributed
cryptographic algorithms has also yielded promising results. For
instance, Dan Boneh, Nagendra Modadugu, and Mike Kim
describe a new method for generating unbalanced 1024-bit RSA
keys, where the server carries out the biggest part of the
calculations and exchanges data through an open channel, but
neither the adversary nor the server can access information about
the generated key.2.16 The keys that this algorithm generates are
good enough for practical use, even though one of the multipliers
is a large random number rather than a prime.
Sumi Helal, Chapter 264
Standards, Tools, & Best Practices
2.14.4 User interface issues
System designers should also consider the user interface. Java-
enabled phone interface design is very different from the design
used for PC or Wireless Application Protocol interfaces. The J2ME
platform is somewhere in between these two platforms: it has
richer interface capabilities than WAP but a smaller screen size
and less processing power than a PC. To improve the usability of
J2ME applications, we must introduce quick search, automatic text
completion features, interface tuning options, and so forth. For this
reason, the client side of J2MEapplications is never thin; in fact,
the client side is always as fat as phone resources and other
applications permit. Problems of a similar nature occur with WAP
interfaces.2.17
Another consideration is that mobile applications must avoid a
situation in which the user must stare for several minutes at a
“Please wait …” message on his or her phone’s screen. This is
difficult, especially given the mobile network connection’s
intermittent nature: with a weak or bad signal transmitting, even a
small amount of information transfer can take from several
seconds to several minutes. Of course, from the user’s viewpoint,
this is one of the worst things that could happen, because the
mobile phone is usually not responding when sending or receiving
information. One way to solve this problem is to implement the
user interface actions in the main thread and the rest of the work
(for instance, code for establishing an HTTP connection) in a
background thread.
Keep this problem in mind for the whole network application’s
design, because even the smallest amount of information can be
delayed. For instance, if dozens of mobile phones interact with one
Sumi Helal, Chapter 2 65
Standards, Tools, & Best Practices
another through a single Web service, the whole system might
become clogged when the recovery time becomes greater than the
average transaction time. No single solution for this exists, because
the situation depends on many parameters, including the phone’s
physical characteristics and the mobile network’s capacity.
2.15 J2ME NETWORK
APPLICATION CONSTRAINTS
Arguably, the biggest question about J2ME is whether we can
build a sizable system on this platform. Here, we conservatively
estimate the maximum size of an information system that could be
implemented with J2ME.
We assume that we’re building a typical N-tier information system,
divided into several layers: the interface level, business logic layer,
and data representation layer. Clearly, as much computation as
possible should be off-loaded from the phone to the server. This
client will interact with business logic through an intermediate
Web application and will use the server computer’s computational
resources.
Apart from the data transfer rate, only one substantial limitation
exists for implementing this architecture—the size of the mobile
application on the phone. So, we must estimate the maximum size.
We assume that we’re going to use the libraries mentioned earlier
to transfer and protect structured data. We’ll also need the
following components:
A kXML 1.0 library (approximately 14 Kbytes)
DES64 cryptography from BouncyCastle.org (approximately
11 Kbytes)
Sumi Helal, Chapter 266
Standards, Tools, & Best Practices
A user interface (approximately 5 Kbytes)
Network data transfer (approximately 3 Kbytes)
Thus, the mandatory part of the application is 33 Kbytes. If we add
approximately 30 percent of this for business logics, we have a 44
Kbytes application. The maximum heap size for a mobile phone is
approximately 128 Kbytes. Naturally, optional applications should
occupy less space to allow for normal phone operation, so we
accept the stricter 100 Kbytes limit. Considering that the average
screen form with event handling and data validation fits into 1.5
Kbytes, we can implement approximately 45 moderately
complicated forms with data validation. This should be enough for
a medium-sized application.
Note that a mobile phone’s permanent memory could be higher
than 128 Kbytes—for instance, it is possible to plug a flash
multimedia card into the mobile device, adding over 256 Mbytes
of storage. However, this is practically useless for applications
because it wouldn’t increase the heap size. Nevertheless, we can
devise more complicated uses for this excessive storage— for
example, it could store a bigger replica of the remote database.
Some problems we’ve described occur because of deficiencies in
available development tools. The more deep-rooted problems
relate to the platform’s physical limitations, but these are also
likely to get easier over time. In general, we found that the J2ME
platform is mature enough to support serious applications.
However, unsolved technical problems will likely appear as well
on other mobile platforms such as i-Mode or Brew. We need
additional research on mobile applications development. Until
then, we hope this article helps programmers deal with some of
Sumi Helal, Chapter 2 67
Standards, Tools, & Best Practices
these development problems and provides ideas for better
development tools.
Sumi Helal, Chapter 268
Standards, Tools, & Best Practices
References
[2.1] D.P. Agrawal and Q.-A. Zeng, Introduction to Wireless
and Mobile Systems, Brooks/Cole Publishing, Pacific
Grove, Calif., 2003.
[2.2] Wireless Application Protocol (WAP), Int’l Eng.
Consortium, www.iec.org/tutorials/ acrobat/wap.pdf.
[2.3] WAP: An Introduction to the Wireless Application
Protocol, Mobile Lifestreams, 1999,
www.totaltele.com/whitepaper/docs/Moblifstrms_WAP.p
df.
[2.4] Wireless Application Protocol: The Corporate
Perspective, white paper, Nokia, 1999,
www.nokia.com/corporate/wap/files/whitepaper.pdf.
[2.5] Success 4 WAP, white paper, Cisco Systems, 2001,
www.mobilewhitepapers.com/pdf/wap.pdf.
[2.6] Yi-Bing Lin and Imrich Chlamtac, Wireless and Mobile
Network Architectures, John Wiley & Sons, New York,
2001.
[2.7] WAP White Paper, Mobileinfo.com,
www.mobileinfo.com/WAP/model.htm.
[2.8] D. Hougland and K. Zafar, Essential WAP for Web
Professionals, Prentice Hall, Upper Saddle River, N.J.,
2001.
[2.9] D. Flanagan, JavaScript: The Definitive Guide, 3rd ed.,
O’Reilly & Associates, Sebastopol, Calif., 2001.
Sumi Helal, Chapter 2 69
Standards, Tools, & Best Practices
[2.10] P. Lowber, “Thin Client vs. Fat Client TCO,” research
note, Gartner, 2001,
www.compaq.co.uk/lifecycle/reports/docs/thinclient.pdf.
[2.11] G. Lawton, “Moving Java into Mobile Phones,”
Computer, vol. 35, no. 6, June 2002, pp. 17–20.
[2.12] M. Fowler, Refactoring: Improving the Design of
Existing Code, Addison-Wesley, 2000, pp. 154–156.
[2.13] A.J. Demers et al., “The Bayou Architecture: Support for
Data Sharing among Mobile Users,” Proc. IEEE
Workshop Mobile Computing Systems & Applications,
IEEE CS Press, 1994, pp. 2–7.
[2.14] S. Dar et al., “Semantic Data Caching and Replacement,”
Proc. Very Large Database Conf., Morgan Kaufmann,
1996, pp. 330–341.
[2.15] A.J. Demers et al., “Epidemic Algorithms for Replicated
Database Maintenance,” Proc. 6th Symp. Principles of
Distributed Computing, ACM Press, 1987, pp. 1–12.
[2.16] D. Boneh, N. Modadugu, and M. Kim, “Generating RSA
Keys on a Handheld Using an Untrusted Server,” Proc.
1st Int’l Conf. Cryptology (INDOCRYPT 2000), LNCS
1977, Springer Verlag, 2000, pp. 271–282.
[2.17] D. Billsus et al., “Adaptive Interfaces for Ubiquitous Web
Access,” Comm. ACM, vol. 45, no. 5, May 2002, pp. 34–
38.
Sumi Helal, Chapter 270