Parsing XML in J2ME

Java Solaris Communities My SDN Account Join

SDN

» search tips

APIs Downloads Technologies Products Support Training Sun.com

Developers Home > Technical Topics > Mobility > MIDP > Reference > Technical Articles and Tips >

by Jonathan Knudsen

March 7, 2002

Download:

The convergence of J2ME and XML is currently a handful of open source parsers. In this article you'll

learn how to parse XML in a MIDP client application. I'll begin by talking about system architecture and

the motivation for using XML as a data transport. Then I'll describe the available XML parsers, discuss

The current world is web-centric, so systems are often designed with HTML browsers as the clients. The

client performs very little of the application processing and functions as a fancy kind of terminal. The bulk

of the application runs on server which uses a database for persistent storage.

As the wireless world began expanding, server vendors found that they could conveniently support

wireless devices by adding support for WAP browsers. The underlying paradigm of the browser as front

objects, or implement a customized protocol. The chief advantage of having a standalone client in place

of a browser is the chance to provide a richer user interface. The main disadvantage is the difficulty of

client installation and maintenance.

Where do MIDP clients fit in this picture? Keep in mind that with MIDP devices, everything is small, and

this affects their utility as application clients.

Because of these constraints, MIDP client applications should be designed to be as small as possible. At

The following figure shows one possible implementation of a multi-tier system that supports HTML

browsers, WAP browsers, standalone clients, and MIDP clients.

A multi-tier architecture with XML

The figure shows one way of supporting multiple client types. Instead of creating custom server-side

code for each client type, you write generic code that returns data as XML documents. Then you create

transformations (using XSLT) that change the basic XML documents into whatever is required for the

client device. Once set of transformations produces HTML for desktop browsers, while another set might

produce the WML to support WAP browsers.

But what kind of data do you send to the MIDP client? You send whatever you want, of course, anything

time you try running the application on a real MIDP device, you'll be pretty sure that the data it's getting

is good.

every byte counts. If you are considering XML as a data exchange format, do some testing with real

devices first to familiarize yourself with the delays involved. On today's wireless networks, latency is

versus a binary format.

For another discussion of the use of XML in enterprise applications, see the Designing Wireless

Enterprise Applications Using JavaTM Technology white paper.

Parser Roundup

If there's a slogan for XML parsers in the MIDP world, it might be "Don't Supersize Me." Parsers are

traditionally bulky, featuring lots of code and hefty runtime memory requirements. In MIDP devices, the

memory available for code is usually small and individual applications may have a maximum code size.

The Motorola iDEN phones, for example, have an upper limit of 50 kB on the size of a MIDlet suite JAR

file. Aside from code size, the amount of memory available at runtime is also small. What you need is a

parser that's designed to be small and light.

notifies a listener object. (This is how the popular SAX API operates.)

document by repeatedly requesting the next piece.

The following table summarizes the current offering of small XML parsers that are appropriate for MIDP.

Name License Size MIDP Type

ASXMLP 020308 Modified BSD 6 kB yes push, model

kXML 2.0 alpha EPL

9 kB yes pull

kXML 1.2 EPL 16 kB yes pull

The Name and License columns contain links to the corresponding web pages and licenses. The Size

column indicates the size of the class files for the parser as contained in a JAR, which is an

approximation of how much size the parser will add to your MIDlet suite JAR. The MIDP column

indicates whether the parser will compile without modifications in a MIDP environment. Finally, the Type

column indicates the type of the parser, as discussed above.

Two parsers that did not make the list are NanoXML 2.2 Lite and XMLtp 1.7. Although both of these

parsers are small, they rely heavily on J2SE APIs and would require significant effort to port to MIDP.