1.1.3 Profiles

1.1.3 Profiles

Whereas a configuration provides the lowest common denominator for a group of devices, the profile adds an additional layer on top of theconfiguration providing APIs for a specific class of device. This creates

the ability for each configuration to be adapted and targeted towards vertical markets. That is to say, while some devices may appear to have similar functionality, they do in fact have different requirements in terms

of the available APIs and interfaces to their own hardware. Some mobile phones, for example, offer more memory, CPU speed or I/O interfaces than others and therefore might want to offer more in terms of an nterface between the programmer and the hardware. Currently, four Java Community Process profiles exist across the two J2ME configurations, but only one of those is a CLDC profile. However, an additional profile called ’DoJa’, defined by NTT DoCoMo, operates on the J2ME CLDC APIs and is used on i-mode devices. With only one JCP profile currently defined, a developer new to J2ME might ask themselves:

why is a profile required at all? Using the example of two-way pagers as a possible type of CLDC

device, it becomes easier to understand the need for another profile. We can see there are similarities between two-way pagers and mobilephones. Both usually connect intermittently over a wireless network,  both can communicate via text type messaging and, possibly, both may store a certain level of information, such as phone numbers. They will both also have a screen of some description. However, the user interface (UI) signals the beginning of the diversity between the two types of device. The method by which data input is captured and indeed displayed will be very different. Each device should have a UI in tune with its own capabilities. While both types of device are CLDC, each will require a separate profile so that the most appropriate APIs are available to the developer.

Mobile Information Device Profile (MIDP)

This profile offers the core functionality required by mobile applications, such as the user interface, network connectivity, local data storage and, importantly, application lifecycle management. As well as the reference

implementation for mobile phones and pagers, there is a second implementation that caters for the Palm OS. It is known as MIDP for Palm OS and it provides for the different user interface on such devices.

Information Module Profile (IMP)

This profile is based upon the MIDP 1.0 profile. IMP combined with CLDC provides a Java application environment targeted at resourceconstrained and embedded networked devices. These devices do not

have rich graphical user interfaces, but their relationship to MIDP 1.0 means that developer skills can be easily transferred to IMP.

Foundation Profile

This profile is the first of three, tiered CDC profiles. It provides a networkcapable implementation without a user interface. It can be combinedwith the Personal Profile and Personal Basis Profile when devices require

a UI.

Personal Profile

This profile is aimed at devices that require full GUI or Internet applet support, such as high-end PDAs or communicator-type devices. It provides a full Abstract Window Toolkit (AWT) library and offers web fidelity. It is capable of running web-based applets designed for the desktop environment.

Personal Basis Profile

This profile is a subset of the Personal Profile and provides a networkbased environment for network-connected devices that support a limited GUI or require specialized graphical interfaces. Devices include set-top boxes and in-vehicle systems. The Personal Basis Profile and Personal Profile have replaced PersonalJava technology and provide a clear migration path for PersonalJava applications to J2ME. Although Personal Information Management and Telephony APIs are not mandatory in this profile, replacements are being specified for J2ME use. Both the Personal Basis Profile and Personal Profile

are layered on top of the CDC and Foundation Profile.