The J2ME Mobile Information Device Profile (MIDP) specification was introduced just over two years ago to provide an open development platform for resource-constrained networked devices, such as commercial mobile phones. Since its introduction, the MIDP profile is proving to be the leading technology platform worldwide for developing this brand of mobile applications. Supporters include mobile carriers from around the world, including NTT DoCoMo, Sprint, and Vodafone, in addition to device manufacturers like Nokia, Motorola, and Research In Motion. The November 2002 release of version 2.0 of the specification introduced substantial new capabilities to the base platform that will enable developers to create more effective and powerful applications with less effort.
In this article, I will highlight these new capabilities and briefly discuss their significance to the development of next-generation mobile applications.
In developing MIDP 1.0, the specification authors were very conservative in the functionality they chose to include in the base profile. The lack of any type of standard security functions, in particular, proved to be very limiting. This forced developers to create their own security functions and include them in each application package. Besides the added file size and effort, this also impeded interoperability. Interoperability, reduced file size, and ease of development are the overriding themes to MIDP 2.0
MIDP 2.0 rectifies this issue through the introduction of WAP Certificate Profile (WAPCERT) support, based on the Internet X.509 Public Key Infrastructure (PKI) Certificate and the Certificate Revocation List (CRL) Profile. The introduction of PKI functionality is utilized by MIDP 2.0 to provide secure connections and digital signatures for "trusted" MIDP application packages (also known as MIDlets).
Trusted applications are permitted to use APIs that would otherwise be restricted by MIDP 2.0's enhanced security model. These restricted interfaces include the PKI certificate interface and connections other then HTTP and HTTPS. (HTTP and HTTPS connections are protected, but can be utilized by untrusted applications with explicit confirmation.) Trust is established with the underlying PKI capabilities using a signing and verification mechanism.
An application is considered untrusted if the origin and the integrity of the JAR file cannot be determined -- a verification failure due to improper credentials or the absence of a signature. For instance, a MIDP 1.0 application would run as untrusted since digital signatures and certificates where not present in the specification.
Untrusted applications have access to the entire graphical interface, sound, record management, and core MIDlet packages. Only HTTP and HTTPS connections are accessible to untrusted applications with explicit permission of the end user.
For more detail on the security mechanisms of MIDP 2.0, see the sections labeled "Security for MIDP Applications" and "Trusted MIDlet Suites Using X.509 PKI" in the final draft of the specification.
MIDP 1.0 provided only one core way of connecting to the outside networked world -- an HTTP connection. Version 2.0 expands the connection options available to developers with a number of new network I/O capabilities.
With the introduction of PKI functionality into the specification, MIDlets can now establish connections using the HTTPS and SSL/TLS protocols that are necessary for secure handling of sensitive information like credit card numbers or passwords. MIDP 2.0 also provides a number of optional low-level networking capabilities for TCP/IP sockets and UDP/IP datagrams, in addition to local serial port connections.
While these new connections are useful and important, the more interesting and unique capability introduced in the specification is the push registry.
By creating an entry in the application descriptor file or through the
PushRegistry class, a MIDlet can register an inbound connection listener. When the MIDlet is not running, the MIDP platform's application management software (AMS) listens for an inbound request. When a request is received, the AMS launches the associated MIDlet using the
startApp method and passes along the connection for processing.
This is significant in that a MIDlet can provide services even when it is not actively running. It is also significant because it provides developers with the means to more efficiently retrieve event-based information. For instance, a MIDlet can subscribe to a RSS news feed alert service, requesting to be notified when new headlines are published -- in addition to making an entry in the push registry. Seconds, minutes, or perhaps even days later, when that feed is updated, the service pushes a notification message to the subscribing MIDlet. The MIDlet did not have to stay active, nor did it have to continuously poll the server for updates. This is a classic example of asynchronous messaging using publish/subscribe, and is one of the ways push capabilities can be effectively utilized.
MIDP will no longer be silent. The 2.0 specification introduces basic sound support that is a forward-compatible subset of the Mobile Media API (JSR-135) specification. (The Mobile Media API was designed for more robust mobile devices requiring a richer set of controls and capabilities, such as advanced sound options and video support.) The Media API supports tone generation, tone sequences, and, if the device supports sample audio, WAV files. While sound is typically not a concern in desktop applications, ringtones and the like are quite popular with mobile phone users today.
Basic audio support is also helpful if you're developing with the newly-added gaming API. These specialized interface controls include a game canvas and sprite and tiled layer classes. They have been optimized to leverage the devices' native capabilities for better performance and thereby help reduce the effort in developing games across a range of devices. Mobile carriers and handset manufacturers are speculating that gaming support in devices will be an important to driving adoption and revenue in the future.
Imagine a vending machine full of applications for you to download and install. In many ways, over the air (OTA) provisioning is like a vending machine, one that dispenses Java applications rather than M&Ms. OTA provisioning allows a consumer to find an application, download it to their phone, and install it -- no wires, docking stations, or PCs necessary. Behind the scenes, MIDlet provisioning service providers have created repositories where developers have published their applications for download, possibly with a nominal fee attached. The provisioning service assures that the application is intended for use with a particular device and monitors status reports from the device.
The original MIDP specification did not include OTA provisioning; it was later introduced as a recommended practice in a separate document. In the MIDP 2.0 specification, OTA provisioning becomes compulsory in order to establish a concrete standard for security and interoperability between service providers and Java-enabled MIDs.
The MIDP 2.0 specifications make numerous user interface refinements to support greater extensibility and overall portability of MIDlets between devices. Some of these noteworthy enhancements include:
CustomItemclass that can be subclassed to develop GUI widgets not included in the standard API.
ItemCommandListenerclass for enhanced interactions on items and a
Spacerclass for more precise layout capabilities.
The J2ME MIDP specification has global industry support and the potential to turn hundreds of millions of next-generation mobile phones into lightweight Internet application terminals. MIDP 2.0 furthers that vision by introducing substantial new capabilities to the core platform that will allow developers to create more effective and powerful mobile applications with less effort. These new capabilities include a robust security model, expanded connection options, and push capabilities, in addition to basic audio media controls and gaming interfaces.
Don't just take my word for it, try them out for yourself. Beta 1 of the MIDP 2.0 Wireless Toolkit is now available from Sun.
Timothy Appnel has 13 years of corporate IT and Internet systems development experience and is the Principal of Appnel Internet Solutions, a technology consultancy specializing in Movable Type and TypePad systems.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.