|
An Object Database for Quartz
Reverse-engineer and modify an address book application to take advantage of a powerful object database library for mobile devices.
by Rick Grehan
April 17, 2006
Symbian's UIQ platform, also known as Quartz, is an environment tailored for handheld phones equipped with pen input and a quarter-sized VGA (though sometimes smaller) display. Although the primary development language for UIQ devices is C++, the Quartz operating system supports two Java environments: PersonalJava and Mobile Information Device Profile (MIDP).
In keeping with a fine tradition that began with its Epoc operating system, Symbian provides a remarkably complete emulator that you can download from its Web site. The emulator is bundled with the UIQ SDK, and it includes documentation; supporting libraries (class files and their source); and a variety of tools useful for debugging, compressing files, and packaging applications for ultimate deployment on a real Quartz system (see Resources).
What's most useful in this bundle, though, are the Java Quartz application examples. Their accompanying source makes them ideal for the sort of learning that one only gets by reverse-engineering code that already works. Here we'll look at a particular application, the AddressBook example, and we'll not only reverse-engineer it, we'll make some modifications that demonstrate how our applications can enjoy an unexpectedly powerful object database library because UIQ supports PersonalJava. In this instance, that library is db4objects (db4o), an open source object database (see Resources).
Let's first explore the database that currently serves as the persistent storage back end for AddressBook. Once we're familiar with it, we can reroute the application's database plumbing.
A Modified AddressBook
The AddressBook application example supplied with the Quartz emulator and SDK demonstrates at least two aspects of Quartz programming. First, it illustrates basic interactions with the Quartz user interface. In particular, it shows off the QFrame class—an elaboration of the awt's Frame class—that uses the paradigm of stacked cards as the abstraction for managing multiple views. Second, it is an easy-to-follow example of using the ContactDatabase that is supplied as an implementation of the javax.pim.database interface.
As its name suggests, the ContactDatabase class describes a database that stores contact information: name, address, phone number, and so on. Individual contacts are kept in ContactCard objects, for which the ContactDatabase serves as a container. In turn, each ContactCard is composed of ItemField objects that store the data values associated with a contact.
If you're familiar with relational databases, this analogy might help: A ContactDatabase corresponds to a single-table database, a ContactCard corresponds to a single row in the table, and ItemField objects correspond to columns in the table. Of course, as with all analogies, this one goes only so far. ItemField objects can be gathered into an AggregateField object, which provides support for multivalued data fields (and for which there is no real counterpart in the relational model).
An AggregateField object works something like an ArrayList. You can add an ItemField object to an AggregateField (either by appending it to the end or by inserting it at a particular index); remove ItemField members; or update ItemField members in the aggregate. The example given most often for using an AggregateField is storing a contact's name (which is really a composition of parts). A name's AggregateField might consist of LastName, FirstName, MiddleName, and Salutation ItemField objects. Consequently, the name AggregateField can be manipulated as a single item, while retaining the distinctions of the different ItemField components.
In addition, you can also use the getField() method, which you use to fetch an item from the ContactDatabase, to fetch an AggregateField. Then the AggregateField class also defines a getField() method that you can use to peel apart the AggregateField's component ItemField objects.
The ContactDatabase predefines a number of constant (static final) strings that specify particular ItemField and AggregateField members. For example, the ContactDatabase.TEL string identifies an AggregateField that includes ItemField members corresponding to a work phone number, home phone number, fax number, cell number, and more. ContactDatabase also provides string values of various parameters that can be used for identifying ItemField entries within an AggregateField. For example, you can use HOME to identify the home phone number within the TEL AggregateField.
Back to top
|