he combination of a database, Web server, browser, and scripting language is a powerful one when it comes to application development. Increasingly, this can be done without code; unfortunately, to date these types of tools have been challenged when reaching pervasive mobile devices because they lack continuous network coverage. IBM alphaWorks’ IBM Forms for Mobile Devices brings the same power to mobile devices with intermittent network access by replacing the browser with a Java MIDP application that reads forms defined using the XForms standard, and enables you to create custom applications without writing any code.
The IBM Forms for Mobile Devices solution is a preview technology from IBM alphaWorks. It permits mobile Java-enabled devices, such as the Palm Computing Tungsten series, to access forms provided by a remote server via a local cache. It stores the results entered into the forms until they regain access to the network. The forms themselves are developed using a set of wizards in Eclipse. These forms are represented as XForms documents presented to the mobile devices, bringing the power of an open standard to bear on the problem of disseminating mobile forms. The overall architecture leverages the model-view-controller pattern, using XForms and the notion of a form instance as the form’s model.
|Author’s Note: Click here for a review of the MVC architecture, or see my previous article “Build Better Mobile UIs with a New BREW Framework.”|
This alphaWorks offering is just as exciting for what it offers?an easy route to mobile data collection with little or no custom code for WebSphere users?as what it demonstrates. The level of integration and convenience achieved by alphaWorks’ researchers comes through their application of well-understood, public concepts like the MVC and XForms. This trend parallels the existing trend in Web application development and promises to relieve many mobile developers of the burden to generate tedious custom applications for data collection.
Installation is straightforward, although the requirements can be daunting at first. On the server side, IBM Forms requires running an IBM WebSphere application server, along with a back-end IBM DB2 database to store the forms. The handheld client must be running a JVM; IBM suggests their WebSphere Micro Environment, a CLDC 1.1/MIDP 2.0 compliant implementation which runs on devices such as the Palm Tungsten C. Trials of all of these are available from alphaWorks.
Developing forms past the sample application requires the Eclipse SDK, a Java-based IDE. The IBM Forms for Mobile devices includes a set of wizards that integrate with Eclipse, making it easy to create your own forms.
Once you configure the IBM Forms for Mobile Devices per the instructions that accompany the release, it’s time to develop some forms. To do this, you must first create a project to contain the form instance, and then create one or more forms. In the process of creating the instance, you specify the back-end database to which your data will be saved (at present, only DB2 databases are supported, although you can create your own interfaces to legacy applications, called connectors, which is covered more throroughly later). This instance encapsulates the metadata about the database in XML, including access information as well as the schema (called a table space in DB2 lingo), and provides the data model for the forms application.
The IBM Forms Template Wizard creates individual forms based on the instance. The wizard gives you two choices: use the information in the instance document you created to create the forms template, or create forms templates based on a hand-crafted XForms instance document. XForms is a robust XML application for describing electronic-based forms being set out by the W3C, it’s instructive to look at a simple example such as the one provided with the release, because it points to the capabilities and limitations of both IBM Forms for Mobile Devices and XForms as a whole. Listing 1 contains ExpenseAccount.xml, an XForms document that describes a simple expense account.
A cursory examination of Listing 1 shows that an XForms document is divided into two sections: the model, contained in the heading of the document and the view, contained within the body of the document itself. The model is aptly placed within the
Most of the time, you can be content working directly with the instance document you created, configuring the characteristics of each element using the Set Elements Properties of the template wizard. Using this facet of the wizard, you can indicate which fields of the database table should be on the form.
Once you create the forms template, you must export it to the server as a Mobile Forms Archive. This article’s download contains the instance data and form template files. It’s created by the Export Wizard and placed on the file system or the remote WebSphere server for you when you provide the server’s IP address and port number.
Managing Forms on the Handheld
On the handheld device, the IBM Forms for Mobile Devices application provides an in box/out box metaphor. To begin, synchronize the application with the server, which transfers the forms you created into your handheld application in box. These are empty form templates, stationery from which you can draw one or many instances of the same form to provide additional data. As you complete instances of forms, they go into your out box, where they’ll be sent to the server the next time you synchronize(think of each form as a record in your database’s table).
The client application maintains a cache of empty and completed forms, letting you collect data unfettered from the network for as long as you wish. While forms are in your outbox, you can continue to work with them, so it’s possible to edit changes to a form you’ve started and already marked as complete. This makes it easy to correct errors on the handheld without server-side intervention.
Intercepting Form Data on the Server
The IBM Forms for Mobile Devices application provides two means of sharing form data with the server:
- A generic JDBC connection: The client application uses JDBC to communicate with the WebSphere server.
- Email: Mails form data to a remote address via the WebSphere server. This is accomplished through the two application connectors provided by the software itself.
Many forms applications require integration with legacy applications via HTTP or other protocols, and you can perform this integration by providing your own subclass of IBM’s com.idb.forms.appconnector.ApplicationConnector class. This class provides the semantics of sharing data between the client application and server, and consists of a constructor and a submit method (see Listing 2).
Writing a custom application connector isn’t hard, because the submit method takes a FormInstance (the model for a completed form) and you can either toss the completed XForms documents back to the legacy server for processing, or parse them directly in your application connector and return the data in a format suitable for the legacy application. For example, you could use the J2SE XML parser to parse the XForms document, obtain the variable values, and convert them to a comma-delimited list to import into a legacy database or append to a log file.
A New Path to Integration
The technology release of IBM Forms for Mobile Devices is interesting for two reasons: if you’re one of the many users of IBM’s WebSphere Application Studio and DB2 database, the technology release provides a turnkey way to integrate handheld devices within your enterprise. Perhaps more importantly, however, the work done at alphaWorks proves the basic concept that the XForms working group is espousing: the use of XML to encapsulate form and form data transmission between client and server. The overall architecture of the IBM Forms for Mobile Devices application is sound for any kind of distributed client/server system with intermittent network access, and I imagine it’s only the first of many open- and closed- systems based on the XForms standard in the future.