Skip to Content

I believe this would be the first obvious question of any reader..

Why J2ME?

In the second quarter 2006, for Nokia, the dominant player in the mobile phone market, the total mobile device volume achieved by Mobile Phones reached 78.4 million units. Most of these units are Java enabled. With lofty numbers announced by other mobile phone manufacturers as well, there is a flood of interest in software development revolving around J2ME (Java 2 Micro Edition). J2ME is a slimmed-down version of Java targeted at devices that have limited memory, display, and processing power.

This blog series shall focus on Mobilizing SAP using J2ME Technology.

The Basics

The figure below shows the J2ME architecture.

image

Java Virtual Machine layer: This layer is an implementation of a Java Virtual Machine that is customized for a particular device’s host operating system and supports a particular J2ME configuration. The prerequisite for the J2ME CLDC is a stripped-down JVM, called the K Virtual Machine (KVM). The KVM is designed for small-memory, resource-constrained, network-connected devices.

Configuration layer: The configuration layer defines the minimum set of Java Virtual Machine features and Java class libraries available on a particular category of devices. In a way, a configuration defines the commonality of the Java platform features and libraries that developers can assume to be available on all devices belonging to a particular category. This layer is less visible to users, but is very important to profile implementers. Configurations consist of the Connected Device Configuration (CDC) and the Connected Limited Device Configuration (CLDC).

CLDC provides a subset of the Java 2 Standard Edition (J2SE) libraries. Included are classes from:

  • java.io
  • java.lang
  • java.util

An additional set of classes is provided by the CLDC — javax.microedition.io. This library provides classes and interfaces to facilitate access to storage and network systems. Although this library lays the groundwork for accessing various systems, the implementation is provided at the Profile level.

Profile layer: The profile layer defines the minimum set of application programming interfaces (APIs) available on a particular family of devices. Profiles are implemented upon a particular configuration. Applications are written for a particular profile and are thus portable to any device that supports that profile. A device can support multiple profiles. This is the layer that is most visible to users and application providers.

MIDP layer: The Mobile Information Device Profile (MIDP) is a set of Java APIs that addresses issues such as user interface, persistence storage, and networking.

MIDlets: A Java application that is built on top of the CLDC and MIDP is known as a MIDlet. A MIDlet suite consists of one or more MIDlets packaged together as a JAR.

The relationship between the standard and micro edition Java APIs is shown in Figure below:

image

The relationship between J2EE, J2SE, and J2ME is shown in the figure below:

image

Designing the user interfaces

Although it maintains a constrained profile, the MIDP API provides a complete set of UI elements. The following are some of the most important ones:

  • An Alert acts as a screen to provide information to the user about an exceptional condition or error.
  • A Choice implements a selection from a predefined number of choices.
  • A ChoiceGroup provides a group of related choices.
  • A Form acts as a container for the other UI elements.
  • A List provides a list of choices.
  • A StringItem acts as a display-only string.
  • A TextBox is a screen that allows the user to enter and edit text.
  • A TextField allows the user to enter and edit text. Multiple TextFields can be placed in a Form.
  • A DateField is an editable component for presenting date and time information. A DateField can be placed in a Form.
  • A Ticker acts as a scrollable display of text.

Event handling in J2ME

Event handling in J2ME, in contrast to event handling on the desktop version of the Java platform, is based around a succession of screens. Each screen carries a certain small amount of data.

Commands are presented to the user on a per-screen basis. The Command object encapsulates the name and information related to the semantics of an action. It is primarily used for presenting a choice of actions to the user. The resulting command behavior is defined in a CommandListener associated with the screen.

Each Command contains three pieces of information: a label, a type, and a priority. The label is used for the visual representation of the command; the type and priority are used by the system to determine how the Command is mapped onto a concrete user interface.

Figure below shows the event handling mechanism in J2ME.

image

Managing Database of Mobile Device

The MIDP provides a set of classes and interfaces to organize and manipulate a device’s database: RecordStore, RecordComparator, and RecordFilter. A RecordStore consists of a collection of records, which remain persistent across multiple invocations of the MIDlet. Comparing records in a RecordStore or extracting sets of records from a RecordStore is functionality provided by RecordComparator and RecordFilter interfaces.

Having covered the basics of J2ME in this blog, the next blogs shall focus on the development and deployment of J2ME application.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

    1. Tanveer Shaikh Post author
      Hi Tuhin,
      I have gone through your article. Wanted to get in touch with you then. I intend to highlight all these points in step by step manner in the upcoming blogs.
      Also, I would like to talk to you on the same.
      Can you mail me your number at tanveer.shaikh@wipro.com.

      Thanks,
      Regards,
      Tanveer.

      (0) 

Leave a Reply