|
Introduction to MIPD 2.0 The Mobile Information Device Profile (MIDP) 1.0 specification was released in December 2000. This J2ME specification describes a mobile device's basic hardware, its interfaces, and the execution environment in which Java applications start, run, and terminate. It also describes the application programming interfaces (APIs) and classes that provide abstract access to the device's hardware, such as drawing to a screen or establishing a network connection. Since then, MIDP 1.0 has been implemented across a huge number of portable devices from many vendors, including Sony Ericsson. In November 2002, the Java Community Process (JCP) organization released the MIDP 2.0 specification. This revision adds critical features and enhancements that the MIDP 1.0 specification lacked. Among the new features found in the MIDP 2.0 are:
- A consistent mechanism for playing sounds. The specification describes a collection of APIs that allow the playback and control of sounds, independent of the underlying hardware or the format of the audio media.
- APIs to enhance security. The specification requires the implementation of secure HTTP (HTTPS) connections. It also describes a trusted code mechanism for use with signed Java applications. Untrusted applications can only execute within the secure sandbox model described by MIDP 1.0, without access to low-level hardware or system APIs. Trusted code can be assigned permissions that allow it to access protected APIs or functions.
- Formal support for Over The Air (OTA) user-initiated provisioning. A user can discover, download, and execute MIDlets from a MIDP 2.0-compliant device.
- Low-level support for games. A new Gaming API implements double-buffering, direct control of screen updates, and a low-overhead mechanism for scanning the navigation button and keypad. New classes simplify the rendering of layers, game field grids, and animated sprites. Support for collision detection between layer objects and sprites is provided.
In addition to these new features, MIDP 2.0 enhances the capabilities of existing MIDP APIs. For example, the layout mechanism for high-level user interface (UI) widgets (items) now offers relative layout options. This improves the appearance of forms in e.g. an enterprise application that is required to execute on a variety of mobile devices. With relative layout, the application's UI elements can automatically arrange themselves to adapt to different-sized screens.
A Tale of Two Phones Two of Sony Ericsson's mobile phones now support the MIDP 2.0 specification: the P900 smartphone and the Z1010 3G phone. There are subtle differences between the implementations of MIDP 2.0 on these two handsets. This is because the P900 uses the Symbian OS V 7.0 to support the MIDP 2.0 environment, while the Z1010 MIDP 2.0 implementation is part of its kernel. However, it is important to note that both versions implement all of the mandatory portions of the MIDP 2.0 specification (features labeled as MUST in the overview section of the specification's JavaDocs). Any MIDP 2.0-compliant application that uses only the mandatory APIs and classes should execute on these handsets with little to no modification.
The difference in the capabilities offered by these two Sony Ericsson devices is worth noting. These are discussed below. However, for detailed implementation information, always consult the White Paper for each device as well as the Developers' Guidelines that can be found in the Docs & Tools section.
Sound For sound generation and control, the P900 uses the MIDP 2.0's Media APIs, which only manage audio media. The Z1010 instead uses the Mobile Media APIs (MMAPIs), which handle audio, graphics, and video media. Often mentioned by the Java Specification Request number, JSR-135. The MIDP 2.0 Media APIs are an exact subset of the JSR-135 APIs, so that the audio code written for either API is interchangeable.
Camera On the Z1010, the JSR-135 API enables Java applications to not only manage audio playback, but to playback stored video clips and use the handset's built-in camera to take still pictures. On the P900, a Java application can't access the camera since only the Media API is available for media control. You can use the Symbian OS's ECam APIs to take pictures and record video, but this requires writing the application in C++.
Security For security, both phones support HTTP sessions over an Secure Sockets Layer (SSL) connection, as directed by the specification. MIDP 2.0 requires the implementation of its trusted code mechanism, unless the device's security policy does not support or permit trusted applications. This is the case with the Z1010: its security policy dictates that all Java applications execute as untrusted code. The P900 does support protection domains that allow properly signed applications to execute as trusted code. For more information on the proper use of this capability, consult the P900 developer's document.
Full screen modes On the Z1010, calling the MIDP 2.0 Canvas method setFullScreenMode() allows an application to commandeer the phone's entire 176 by 220 pixel screen. To get access to menu commands, you press on a softkey. On the P900, the J2ME application never takes control of the entire 208 by 320 pixel screen (this is reserved for C++ applications). The amount of screen real estate that the application's Canvas can use varies, as determined by the device, if the user has chosen to discard the J2ME virtual keypad or not. With the virtual keypad present, a call to setFullScreenMode() lets you draw on a Canvas that's 208 by 172 pixels in size. If the virtual keyboard is absent, the dimensions of the Canvas becomes 208 by 253 pixels. In this mode, you can use the P900's touchscreen and jog dial to interact with the application.
Vibrate and Backlight The Z1010 supports control of vibration and backlight through the MIDP 2.0's flashBackLight() and vibrate() methods. The P900 does not.
Optional API support Both the Z1010 and P900 implement the Wireless Messaging API (WMA), also known as JSR-120. Besides adding valuable messaging capabilities to these devices, the WMA can also leverage an important feature in the MIDP 2.0: the PushRegistry. This feature allows an incoming message to launch a specific MIDlet, perhaps to notify the user of the receipt of a message or other important activity.
The P900 also supports the Java APIs for Bluetooth (JSR-82). This short-range wireless technology can be used in concert with MIDP 2.0's features to write multiple-player games, short-range chat services, or other novel Java applications.
Benefits The MIDP 2.0 specification vastly improves the J2ME platform by adding valuable new capabilities to a mobile device. Game development is made considerably easier through the Gaming API support. Corporate developers will be able to adjust the UIs of their enterprise application so that they reproduce correctly on a wide range of mobile devices. The MIDP 2.0 security features enable the P900 and Z1010 to serve as secure terminals for all sorts of mission-critical transactions. The PushRegistry feature, along with the JSR-120, allows the possibility of notification of completed transactions or to send instant messages to workers in the field. Although the P900 and Z1010 have minor differences in their MIDP 2.0 implementation, they both offer the full use of this specification and its rich feature set.
For more information:
|