 | |
Wireless Java technology is crossing the threshold to a new world. MIDP 1.0, already deployed on millions of phones around the globe, provides a robust application environment that enables developers and carriers alike to provide choice, value, and power to consumers. A new generation of devices will offer the advantages of MIDP 2.0's advanced networking, security, gaming, and media features. MIDP 2.0 is just one piece in a larger story. A lesser known specification, Java Technology for the Wireless Industry (JTWI) (JSR 185), uses MIDP 2.0 as the centerpiece of a rock-solid wireless Java application environment. New devices will not be merely MIDP 2.0 devices; instead, they will be JTWI devices. This article explains why JSR 185 is crucial to the future of wireless Java technology and discusses the technical details of the specification. This article is a technical overview, not a substitute for the specification. To make sure you get all the details right, also read the JSR 185 specification. Recent History Although MIDP 1.0 has been wildly successful since its release in September 2000, it leaves room for improvement. As a new technology seeking adoption by device manufacturers and wireless carriers, MIDP 1.0 offered a capable but rather basic application environment for general application development. Many manufacturers offered their own proprietary APIs to offer expanded functionality, like the ability to play sounds, manipulate images, or flash the phone's backlight. Nokia and Motorola, for example, both include their own APIs on the devices they manufacture. Sprint, a carrier, provides its own APIs on its devices, which come from various manufacturers. Concurrent with the first generation of MIDP 1.0 devices, many optional APIs are being designed using the Java Community Process. These form a broad range of functionality, from media APIs through location APIs. Optional APIs may be packaged alongside MIDP on a device. The resulting jumble of vendor-specific and optional APIs is called fragmentation. As a MIDP developer, you want to know what APIs will be available on your target devices. Which manufacturer or carrier APIs will be on devices that you sell to? What optional APIs will be available on these devices? It is possible to discover the presence of APIs at runtime, but this technique adds complexity to your code. Instead, you may be tempted to distribute multiple versions of your application, which is also undesirable.
Aside from fragmentation, the other big fly in MIDP 1.0's soup is
portability. One of the tenets of MIDP is the idea that
you can write one application that runs on many different types of
devices. API fragmentation impairs portability, of course, but
there are other portability problems. Some are as simple as
different device manufacturers or wireless carriers imposing limits on
the size of applications. If you develop a MIDP 1.0 application,
sticking strictly to the specification, it still may fail to install on
some devices, depending on its size. Other problems
are trickier. For
example, the MIDP 1.0 specification includes the
JSR 185 to the Rescue JSR 185 provides a wireless Java applation environment that trounces fragmentation and improves portability. Fragmentation is addressed by providing many crucial capabilities in one standard application environment. Interoperability is addressed by clarifications to existing specifications and an exhaustive suite of compliance tests. JSR 185 addresses API fragmentation by providing a comprehensive collection of functionality. The JSR 185 application environment is based on the following specifications:
JSR 185 ameliorates the need for vendor-specific APIs by providing a comprehensive set of functionality in a standard application environment. Developers now have a full-featured, stable, standard application environment for which they can develop. JSR 185 improves portability by clarifying existing specifications and nailing down some implementation details. The rest of this article explains the clarifications. Size Matters One of the problems developers have in writing MIDP 1.0 applications is that it's hard to guess how much space is available on the device. MIDlet suite JAR size is one measure of an application's size, but applications also use runtime heap memory and persistent storage. While the MIDP specification supplies some minimum requirements for MIDP implementations, it's mostly silent on issues of heap and MIDlet suite JAR size. As a result, different manufacturers and carriers have imposed different limits on MIDlet suite JAR size. The first generation of i-mode phones in Japan (not MIDP, but similar) had a limit of only 10 KB. Some Nokia devices will refuse JARs over 30 KB, while the very first Motorola phones had a documented limit of 50 KB (even though it was possible to install larger JARs). JSR 185 fills the void by defining a standard-size application. Devices that implement JSR 185 should allow MIDlet JARs up to 64 KB, with application descriptors (JADs) up to 5 KB. Further, each MIDlet suite should be allowed to use up to 30 KB of persistent storage. Correctly formed MIDlet suites should include an indication of the minimum amount of persistent storage needed to function. The specification supplies 30 KB as the standard maximum amount of persistent storage that a MIDlet suite will use. The idea of a standard-size application serves as a baseline for what developers should expect from devices. Manufacturers are likely to create devices that can accept larger applications and can provide more persistent storage. Application developers can use the additional space if it's available, but should not expect more from a device than what is suggested by JSR 185. In the future, capacities of devices and needs of applications may well be described in terms of standard-size applications; for instance, a device might have space for ten standard-size applications, or a developer's software might be counted as two standard-size applications. One crucial measure of a device is the size of its heap, the amount of memory that is available to a running application. MIDP 2.0 requires a minimum of 128 KB, but JSR 185 recommends a more comfortable 256 KB. Ticklers
One of the most useful things a machine can do for you is remind you
when you're supposed to do something. I'd probably miss half my life if
my venerable Palm V didn't beep at me five minutes before my meetings.
MIDP 2.0 includes a facility for waking MIDlets up at specific times
(the JSR 185 lays down the law and requires support for this feature. On a JSR 185 device, then, you can be sure your calendar-style application will work correctly. User Interface and Media The MIDP 2.0 specification follows the MIDP 1.0 specification and mandates a minimum screen size of 96 x 54 pixels with one-bit color depth. This is a pretty small screen compared to today's phones, so JSR 185 suggests (but does not require) a screen size of 125 x 125 pixels with 12 bits of color depth. JSR 185 requires that JPEG images be supported for images. This is in addition to MIDP's required support for PNG images. Finally, JSR 185 requires that any media content type supported by the device must be accessible using the HTTP 1.1 protocol. Manufacturers or carriers are free to support whatever other protocols they wish, but HTTP 1.1 is required for all supported content types. Text Messaging JSR 185 supports text messaging applications with several requirements. First, of course, JSR 185 requires devices to implement the Wireless Messaging API (WMA), JSR 120, and thus assures developers writing for JSR 185 devices that the APIs they need for text messaging are available. Second, JSR 185 mandates that devices on GSM/UMTS networks make Short Message Service (SMS) text messaging available via WMA. Furthermore, devices must support SMS push, the ability of the device to launch a MIDlet in response to an incoming SMS message.
On GSM/UMTS networks, MIDlets on JSR 185 devices will be able to send
and receive SMS messages. JSR 185 goes one step further by requiring
that the
This requirement makes a lot of sense. Suppose you write an SMS MIDlet.
When the user wants to compose a new message, you'll provide a
If You're Going to Do Multimedia, Do It Right MMAPI is a powerful and flexible package for the playback and recording of audio and video data. MMAPI is an optional part of the JSR 185 stack, but JSR 185 does nail down some of the optional parts of the MMAPI specification, so developers will have a stable base upon which to build applications for devices that do support MMAPI. First, JSR 185 dictates that MIDI content and tone-sequence content must both be supported. MIDI support makes powerful and rich audio capabilities available to developers, using relatively small files. JSR 185 further requires that all supported content types be available via HTTP, just like the requirement for MIDP 2.0 content types. One of MMAPI's exciting features is its ability to support recording (called capture) of audio data with a microphone or images with a camera. Not all devices have capture capabilities. On the ones that do, though, MMAPI is deliberately vague about what content types will be used for capture. JSR 185 eliminates this uncertainty too: Devices must support 8-bit 8 kHz mono PCM WAV for audio capture, and JPEG format for images (called video snapshots in the specification). Devices are free to support other formats as appropriate, but the required formats give developers a baseline of expected behavior. Standard Policies for Untrusted Software MIDP 2.0 includes a powerful security model designed to protect users and carriers from rogue software. The specification, however, is deliberately vague about what protection domains will be defined and what their policies will be. JSR 185 solidifies the security model a little bit by specifying the behavior of GSM/UMTS devices when running untrusted code, which is code whose contents and origin cannot be verified. JSR 185 goes into great detail on this subject; if you're interested, go take a look. In brief, JSR 185 says that a device should ask the user whenever untrusted code tries to do something that might pose a security risk, or might cost the user money (by using the network). Summary JSR 185 provides a firm foundation for the next generation of wireless Java technology. It adds clarifications and detailed requirements for JSR 185 implementations. JSR 185 reduces fragmentation in the MIDP world while improving application portability. JSR 185 encompasses the features of MIDP 2.0, WMA 1.1, and MMAPI 1.1, and rolls them into a solid application environment for developers and users. Further Reading Specifications:
Articles:
Back To Top | |||||||||||||||||||||||||||
| | ||||||||||||||||||||||||||
| ||||||||||||
Print-friendly Version
