Today's wireless networks are notoriously unreliable. Unavailable applications destroy the core value of mobile commerce, which is the promise of accessing information anytime, anywhere. In fact, the requirement of always-on connections is one of the major reasons why Wireless Application Protocol (WAP)-based thin-client mobile commerce failed to take off. Mobile commerce requires smart, mobile clients that can handle applications locally and continue to function even when the network is temporarily unavailable (i.e., offline operations). The "occasionally connected" mobile applications require advanced mobile data storage and management tools. Such tools are readily available on J2ME (Java 2 Platform, Micro Edition).
In this article, I first discuss general concepts and specifications of mobile databases. I use an example application to illustrate important designs and key components of J2ME mobile database applications. I also provide useful advice on how to choose the right mobile database in today's diverse market.
The first requirement for offline operations is to store and manage application data on the device itself. The standard J2ME profiles provide only limited data storage and management capabilities. On low-end MIDP (Mobile Information Device Profile) phones, we have only linear record stores from the record management system (RMS); in the Foundation Profile (or PersonalJava), we have plain random files. The application developer must organize data using those generic facilities, which can prove tedious, inefficient, and error prone for large applications.
In the J2SE (Java 2 Platform, Standard Edition) and J2EE (Java 2 Platform, Enterprise Edition) worlds, the relational database represents the key technology for data management. Most Java developers are already familiar with common database access APIs such as JDBC (Java DataBase Connectivity). A lightweight relational database is therefore our natural choice for mobile data management.
In addition to supporting offline operation modes, on-device databases have other important benefits:
The standard JDBC API has always been optionally available for high-end Java mobile devices. PersonalJava runtimes are often bundled with the optional JDBC 1.x API. PersonalJava's successor, the J2ME Foundation/Personal Profile (FP/PP), does not mandate JDBC. Instead, a rich subset of the JDBC 3.x API is made available to FP/PP devices through the J2ME JDBC optional package (JDBC OP). JSR (Java Specification Request) 169 is developing this optional package's specification; the final draft was proposed in November 2002. The JDBC OP supports most commonly used JDBC features except the following: