In tough economic times such as these, most organizations are quickly cutting through the "fluff" in their budgets and evaluating every purchase based on its impact on the bottom line.
Many technology companies are especially subject to these hard decisions, particularly those who have a difficult time quantifying the return on investment from a purchase of their product.
For instance, a WAP application that keeps management up-to-date on announcements, meetings, and other internal events is certainly a "nice-to-have" depending on the cost of the application and the administration overhead. On the other hand, a mobile app used by a company's 2,000 field service workers that eliminates paperwork and improves productivity by 50% can have an immediate effect on customer service and retention, staffing, and work backlogs. Any application that can deliver such promising results quickly achieves mission-critical status in a large organization.
Because of this impact, it is an absolute requirement that the application remain available and functioning in any environment. This may seem like a given, in a perfect wireless world, but unfortunately that is a world none of us live in (particularly in the U.S.). The reality is that many mobile applications, particularly those used by field service, delivery, and public safety workers must continue to function in a reliable fashion in tough environments with little or no wireless communications connectivity. What does this mean, from a technical point of view?
Disconnected application requirements
It has been said that the best wireless applications operate well without a wireless connection. To pull this off, an application architecture has to be completely rethought. During the great rush to support client/server, n-tier, and Web architectures over the past decade, it may come as somewhat of a shock to the system to think of working without a net, to coin a phrase.
While talk of 2.5G (and beyond) networks gets us all excited, it doesn't provide a solution to today's problems. A mobile application may be required to work disconnected due to a variety of circumstances. These include poor coverage, insufficient bandwidth, intermittent connections to reduce usage fees, and inhospitable working conditions. Working environments unfriendly to wireless communications include elevator shafts, tunnels, and rural settings.
Handling the mobile database
Applications that make the best candidates for disconnected and connected operation are, in general, forms-based, transactional database apps. These applications allow mobile workers to retrieve data (customer info, a work order, etc.), view or modify the data as seen fit, then save the database back to the local device. This requires the use of a database located on the device to store and manage the application data.
While something as simple as Microsoft Access could handle the smallest of jobs, most mobile apps must interact with an enterprise data store at some point to push data back "upstream." This requires a synchronization process that efficiently moves data from the server up to the client as well as data from the client back to the server.
While it is certainly possible to write your own synchronization process, most developers opt for a commercial database sync solution. These include Aether Software's ScoutSync and Pumatech's IntelliSync products. More powerful development toolkits that integrate the database with a synchronization solution include products such as Oracle's Oracle Lite, PointBase (with UniSync), and Sybase SQL Anywhere (with Mobilink). All of these products combine the power of a SQL relational database on the client with bi-directional synchronization to one or back-end data sources.
Once you've settled on a database for your mobile client, a host of new issues arise due to the fact that your mobile workers may be working disconnected from the server for long stretches of time.
The most important issue to be addresses is the minimization of data to be sent over the air to your mobile workers. Each time a worker syncs his device or laptop, only data that was added or updated since the last sync should be sent over the air. This will result in quicker response times as well as a lighter load on the public or private radio network you're using.
The anatomy of synchronization
The sync products mentioned above handle this in a variety of ways but the most common is simply to add new/updated date fields to each database table being synced for tracking purposes. Eliminating all but the mandatory fields from the client-side schemas as well as populating clients with all necessary lookup data during installation can also further minimize data.
Because the database is separated from the server, unique key generation must also be handled on the client before the data is physically inserted on the server during a sync. In other words, if 500 different clients all add one or more records to a table on the client then perform a sync, how do you differentiate between the primary keys in each client-side table.
One common approach is to perform "key pooling", in which a unique key pool table is maintained on the server and synced out to each client with all other data. As the user uses keys out of the pool, they are removed. During the next synchronization, the key pool is refilled with new primary keys. Because this pool is actually maintained on the server, a client can be sure that they'll never generate the same unique key as another client.
Yet another option is to offload all logic and processing from the client, leaving it completely up to the server to replace all new client records with system primary key data. This option simplifies the client at the expense of additional loading and complexity on the server.
Application deployment is another thorny issue that must be handled by the mobile application developer. With hundreds, or even thousands, of mobile clients moving around a city, state, or country at any one time, it becomes increasingly difficult to update the mobile client with new versions of an application or database.
An ideal solution would seamlessly update the client application as the client data is being modified during synchronization. A number of commercial deployment solutions are available, including Sitraka's Deploy Director and Aether's ScoutIT products. Java remains the preferred solution in this scenario, as its granularity allows individual Java classes to be updated without a complete application reinstall.
Commercial applications also need to plan on operating on a wide variety of wireless networks. While many popular data networks (such as CDPD) support IP packet networking, many other networks do not.
One solution to this is either a painful recoding of an application's communication layer on a network-by-network basis (using proprietary APIs and messaging techniques). This type of "one-off" solution has been largely replaced by the use of software middleware designed to shield your application from intricacies of wireless networks.
Leading products in this category include Aether Systems AIM and Broadbeam's SmartIP. Typically, middleware products also provide added compression, encryption, and improved bandwidth utilization, making them invaluable tools for wireless development projects.
Markup language-based applications - using languages such as WML, XHTML, and HTML - offer a number of powerful advantages, including instant application distribution, thin clients, lower costs, and device independence. However, these applications require constant connections and a network capable of handling the workload.
Keeping the road-less-traveled in mind - that of the disconnected mobile app - might make your customers happiest in the long run with the realization that their mission critical applications are always available no matter the conditions.
Bryan Morgan was the founder of WirelessDevNet.com (The Wireless Developer Network) and is currently an independent writer and software developer. He is a columnist for Wireless Internet magazine and is also a regular contributor to WirelessWeek.com and InformIT.com.