Introducing Nokia Developer Platforms

This chapter is from the book

Developing Scalable Series 40 Applications: A Guide for Java Developers

Learn More Buy

This chapter is from the book

This chapter is from the book 

Developing Scalable Series 40 Applications: A Guide for Java Developers

Learn More Buy

Managed Smart-Client Technology: J2ME

J2ME brings rich and high-availability applications to occasionally connected mobile devices. It is universally supported by all versions of Nokia Developer Platforms as well as all other major mobile handset manufacturers. In this introductory chapter, we have a high-level overview of J2ME.

A Brief History of Java

The Java technology is emerging as one of the most important enablers for mobile applications. In 2007, Java handset shipments will reach more than 450 million, constituting 74 percent of all handset shipments. Java mobile devices will soon surpass Wintel PCs and become the dominant information access clients. Nokia is a major player in the Java landscape. The technical benefits of Java include:

• Crossplatform: This is very important in the diverse mobile device market. For example, the same J2ME MIDP application runs on all Nokia Developer Platform devices with relatively small amount of modification, representing huge cost savings for developers.
• Robust: Since Java applications run in a managed environment, the bytecode is verified before execution, and unused objects are reclaimed by garbage collectors (see the tip). Even if a Java application does crash, it is contained within the virtual machine. It will not affect other applications on the device.
• Secure: The Java runtime provides advanced security features through a domain-based security manager and standard security APIs.
• Object oriented: The Java language is a well-designed, object-oriented language with vast library support. There is a vast pool of existing Java developers.
• Wide adoption at the backend: It is relatively easy to make Java clients work with Java application servers and messaging servers. Due to the wide adoption of Java 2 Enterprise Edition (J2EE) on the server side, J2ME is the leading candidate for end-to-end mobile applications.

From WORA to Java Everywhere

For early Java, the term crossplatform has a strict meaning: the same bytecode application should run without modification on any computer that has a Java runtime. The original vision is that Java-based software agents could roam over the network automatically. That not only requires bytecode compatibility but also runtime library compatibility. But as Java evolves, it is used in many different application scenarios. The single class library approach no longer fits the needs.

Recognizing that one size does not fit all, the Java 2 Platform is divided into three editions. The Java 2 Standard Edition contains the basic JVM and core class libraries; the Java 2 Enterprise Edition provides additional class libraries and tools for enterprise server applications; the Java 2 Micro Edition consists of stripped-down virtual machines (called KVMs&8212;Kilobyte Virtual Machines) that can run on devices with kilobytes of memory. For mobile devices, a subset of the standard edition class library and new libraries for mobile-specific tasks. It is clear that a Java bytecode application written for an enterprise server will not run crossplatform on a PDA device without modification.

In June 2003, during the eighth JavaOne conference in San Francisco, Sun Microsystems brought up a new slogan for Java: "Java Everywhere." The emphasis is no longer on direct portability of bytecode applications. The focus now is to provide the same language, consistent architectures, and similar APIs across all computing platforms. Java Everywhere allows developers to port their skills to new application arenas.

The J2ME Architecture

The separation of J2EE, J2SE, and J2ME is a step in the right direction. However, a single monolithic J2ME is still too inflexible for mobile devices. There is a huge variety of mobile devices, designed for different purposes and with different features. For example, applications on an automobile-mounted system are much more complex than those on a cell phone. Even among similar devices, such as high-end and low-end cell phones, portability can cause underutilization of resources on one device and strain on another. Device manufacturers and developers need fine-grained API differentiation among devices, not the "lowest common denominator."

To balance portability with performance and feasibility in the real world, J2ME contains several components known as configurations, profiles, and optional packages (Figure 2-15). Each valid combination of a configuration and a profile targets a specific kind of device. The configurations provide the most basic and generic language functionalities. The profiles sit on top of configurations and support more advanced APIs, such as a graphical user interface (GUI), persistent storage, security, and network connectivity. The optional packages can be bundled with standard profiles to support specific application needs.

Figure 2-15 The J2ME architecture.

The two most important J2ME configurations are as follows.

• The Connected Limited Device Configuration (CLDC) is for the smallest wireless devices with 160KB or more memory and slow 16/32-bit processors. The CLDC has limited math, string, and I/O functionalities, and lacks features such as the Java Native Interface (JNI) and custom class loaders. Only a small subset of J2SE core libraries is supported by the CLDC virtual machines (KVMs). The most recent version of the CLDC is version 1.1. It was developed by the JSR 139 and released in March 2003.
• The Connected Device Configuration (CDC) is for more capable wireless devices with at least 2MB of memory and 32-bit processors. Unlike the CLDC, the CDC supports a fully featured Java 2 virtual machine and therefore can take advantage of most J2SE libraries. The CDC 1.0 was developed by the JSR 36, and it became available in March 2001. The new CDC 1.1 is currently being developed by the JSR 218 and is expected before the end of year 2004.

Important J2ME profiles include the following. The Mobile Information Device Profile (MIDP) is built on top of the CLDC to provide support for smart phones; the Foundation Profile is built on top of CDC to provide support for networked embedded devices; the Personal Basis Profile (PBP) and Personal Profile (PP) are built on top of the CDC and the Foundation Profile to provide support for GUI-based powerful mobile devices such as high-end PDA devices. The standard UI library in the current PBP and PP editions is the Java AWT (Abstract Widget Toolkit).

On the CDC and Personal Profile stack, important optional packages include the following: the RMI (Remote Method Invocation) Optional Package (JSR 66) supports remote object sharing between Java applications; the JDBC (Java DataBase Connectivity) Optional Package (JSR 169) provides a uniform interface to access structured query language (SQL) databases from Java applications; the Advanced Graphics Optional Package (JSR 209) aims to add Swing and Java 2D API libraries into the CDC/PP stack.

Although CDC and PP have their places in the mobile market, they are not nearly as popular as the MIDP. All major mobile device manufacturers, including Nokia, are committed to support MIDP. In the next section, we take a deeper look at MIDP and its optional packages.

MIDP and Its Optional Packages

The most important and successful J2ME profile is the CLDC-based MIDP. The MIDP targets the smallest devices, such as smart phones. It is already deployed on millions of handsets, including all Nokia Series 40 and 60 devices. Hence, the MIDP is a key technology that all Nokia developers need to learn.

An MIDP application consists of a suite of MIDlets. Each MIDlet can be independently installed, started, paused, and stopped by the application management software (AMS) on the device. The AMS can be controlled by the user, using the phone keypad. The MIDlet API specification provides a set of abstract life-cycle methods that hook into the AMS. Developers must implement these methods to specify the runtime behavior of each MIDlet. The code for a minimal MIDlet that displays a Hello World string on the screen is as follows. The details of the code are explained in Chapter 3, "Getting Started."

package com.buzzphone.hello;

import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;

public class HelloMidlet extends MIDlet {

  Form form;

  // Called by the AMS when the MIDlet is instantiated
  public HelloMidlet () {
    form = new Form ("Hello");
  }

  // Called by the AMS when it starts the MIDlet
  protected void startApp() {
    form.append ("Hello World");
  }

  // Called by the AMS when it stops the MIDlet
  protected void destroyApp(boolean unconditional) {
    destroyApp(false);
    notifyDestroyed();
  }

  // Called by the AMS when it pauses the MIDlet
  protected void pauseApp() {
  }
}

As of late 2003, most mobile phones in the market support the MIDP 1.0 specification. However, the MIDP 1.0 lacks some important features, such as security and advanced UI controls. As a result, device vendors often supply their own MIDP extensions to provide advanced custom features. Vendor-specific extensions undermine the portability of J2ME applications. Many problems with the MIDP 1.0 have been fixed in the MIDP 2.0, which came out of JCP in August 2002. The Nokia Developer Platforms 2.0 for Series 40 and 60 mandate MIDP 2.0 and optional packages on new Nokia phones.

Table 2-1 lists MIDP-compatible optional packages. Most of the MIDP optional packages run on CDC profiles as well. Nokia supports the optional packages at different levels:

• Device available: The optional package is already factory-installed on some Nokia devices.
• Coming soon: Device implementation of the optional package is currently being developed by Nokia engineers. It will be available on new devices soon.
• Specification: The optional package specification is still being developed by the JCP. Nokia supports that specification by contributing to the expert group.
• No plan: Nokia currently has no plan to support this optional package on its devices.

Table 2-1. MIDP Optional Packages

The Smart-Client Paradigm

Microbrowser-based thin-client technologies were instrumental in bringing mobile Internet to masses in the early days of mobile commerce. But WAP-based mobile commerce has never taken off due to the poor usability on the client side. The new generation of smart-client and mobile middleware technology (e.g., J2ME and Microsoft's .NET Compact Framework) promises to bring feature-rich clients to mobile applications. The benefits of smart clients over thin clients include the following:

• Smart clients have richer and more pervasive user interfaces. In particular, the judicial use of threads can drastically improve user perception of the application performance.
• Smart clients can be more easily personalized. Extreme personalization is one of the most touted benefits of the freedom (mobile) economy.
• On-device data storage reduces network traffic, especially unnecessary round trips. It enables transactions; supports the "offline" mode when the network is temporarily unavailable; and hence improves overall performance, reliability, and availability of mobile applications.
• Smart clients can leverage device extensions. For example, a smart-client program can talk with the device's built-in (or attached) GPS module and barcode scanners. A smart client can also integrate with device-specific software (e.g., email and messaging clients) to improve the user's workflow.
• Smart clients support more powerful and flexible security schemes. They enable content-based security and distributed single sign-on.
• Smart clients support advanced integration technologies. They are easy to plug into existing corporate infrastructure. Supports for asynchronous messaging and XML Web Services are crucial for reliable and maintainable mobile solutions.