7.7 Embedded mobile client applications

This section is a short introduction to the embedded mobile client applications for pervasive solutions.

Embedded mobile applications run on the pervasive device itself and they are specific to the solution, unlike a multi-purpose browser.

Several technologies and platforms exist today to build and run mobile applications. J2ME is only one of them, but it is one of the most promising , and it is also in line with IBM's Java strategy. In this book, you will only find the J2ME technology documented.

Note

For the sample application, we have used the Mobile Application Builder to provide a working prototype for our scenario. Using the Mobile Application Builder, we could build a client application quickly, although the functionalities and programming capabilities of the tool are very limited.

The result is platform-dependent; in our case, it is a PalmOS native application compiled from a C source.

7.7.1 J2ME

J2ME technology is a highly optimized Java runtime environment; it specifically addresses the vast consumer space, which covers the range of extremely tiny commodities such as smart cards or a pager all the way up to the set-top box, an appliance almost as powerful as a computer.

The following is a summary of key goals for this architecture:

Provide support to a variety of devices with different capabilities. These devices often vary in the user interface, data storage, network connectivity and bandwidth, memory, power consumption, security and deployment requirements.
Provide one architecture that can be optimized for small spaces.
Focus on devices that can be highly personalized, often used by a single person.
Maximize cross-platform capabilities.
Maximize the flexibility and provide a means to support a rapidly changing market-place.
Support multiple devices.
Support device-specific functionality.
Maintain a common architecture.

Keep in mind that the network connectivity is different according to capabilities (low bandwidth, wireless, and intermittent connection to high-fidelity, high bandwidth) and services.

One of the key problems that J2ME architecture tries to resolve is how to support a wide range of devices with different constraints, capabilities, features and intended uses without introducing limitations on any specific device.

One way to do it is to create a large, monolithic architecture that includes everything any application would ever need on any given device. In this case, the architecture would be too large in terms of resources.

Another way is to identify the common denominator of functionality that applies to all devices in the J2ME space.

The J2ME decided to use the second solution and introduced two concepts: configuration and profiles.

Configuration: make up the set of low-level APIs that define the runtime characteristics of a particular J2ME environment.
Profile: address the more device-specific and usage-specific API. The profile provides characteristics such as user interface widgets, event handling and data storage.

Figure 7-10: J2ME architecture tiers

Configuration defines the contract between a profile and the Java Virtual Machine; it basically has two different realizations. These configurations are CLDC (Connected Limited Device Configuration) and CDC (Connected Device Configuration).

You can see the difference between both technologies in Table 7-1.

Table 7-1: Configuration, Java Virtual Machine and devices
Configuration	Virtual Machine	Example Device
CDC	CVM J9	Pocket PC Communicator device TV set-top boxes
CLDC	KVM J9	Cellular phones PDAs Two-way pagers

The common question is: if you have two different configurations, how is portability maintained between them? We can see the relationship between the different configurations in Figure 7-11; this gives you an idea of portability in this case.

Figure 7-11: Portability between the specifications

The profile provides an API that focuses on a single device, such as a PDA or a group of related devices such as cell phones and pagers. The devices supported by a particular profile tend to have much in common in terms of how the device is used, what the user capabilities are, how the device connects to the network, and how the device works with persistent data. Profiles are vertical and created to address different kinds of devices.

Choosing a profile is a very important decision that is made when creating applications using J2ME. The number of providers in development is increasing day by day.

Table 7-2 shows a summary of the different J2ME profiles.

Table 7-2: Profiles for J2ME
Profile	Configuration/VM	Virtual Machine	Target Device Examples
MIDP	CLDC	KVM	Cellular phones and two way pagers
PDAP	CLDC	KVM	PDA
Foundation	CDC	CVM	foundation for personal profile
Personal	CDC	CVM	Pocket PC, tablets, communicator and device
RMI	CDC	CVM	Any
Multimedia	CLDC/CDC	KVM/CVM	Any
Gaming	CLDC/CDC	KVM/CVM	Any
Telephony	CLDC/CDC	KVM/CVM	Cellular phones

The most famous profile is MIDP. This is first official profile released by Sun and originally released for cellular phones and two-way pagers. This profile now has also been implemented to run on the PalmOS platform. These devices have very constrained resources, such as a small screen for user interface, limited data entry capability and limited data storage.

The next version of MIDP will address features such as security, using HTTPS, push interface, small XML parser and sound API.

7.7.2 What has changed in J2ME for J2SE programmers

The J2ME specification had to remove some features that were available in the J2SE environment to meet the requirements in developing for pervasive devices.

Following is a list of features that have changed from J2SE:

Java Native Interface
User-defined class loaders
Java Reflection
Thread groups and daemon threads
Finalization (Garbage Collector thread)
Weak references
Floating point data type (float and double)
Some security feature and APIs
Class file verification (modified for efficiency)
Some error handling limitations (not all exceptions are included)

These features have been changed because obtaining the necessary memory or processing power is quite expensive.