Mobile Database Development Tutorial: Part 4
- The Business Case
- Synchronization Issues
- MobiLink Synchronization
In the first three articles in this series, I presented numerous ways to slice-and-dice your mobile application development project. These methods included a variety of programming languages, databases, and API options for the most popular mobile platforms in use today, using the Sybase SQL Anywhere Studio 8 toolkit. To conclude this discussion, we'll take a look at a task that is critical to the success of any enterprise mobile computing application: data synchronization.
The Business Case
For more than a decade now, relational databases have been used to store the bulk of enterprise business data, and nearly all packaged enterprise applications (CRM, ERP, and so on) require them. Mobile workers, however, have been historically cut off from live (or nearly live) data updates such as amended delivery locations, updated customer requirements, and the latest prices and inventories of sellable products. Although corporate intranets could (and do) deliver much of this information, standard web applications require a healthy communications link back to the intranet web server (14.4Kbps at a minimum).
WAP (Wireless Application Protocol) can be used to deliver small amounts of read-only information over wireless networks, but this brings up its own set of issues. Issues with WAP browsers on mobile devices, problems with data input on phones (where the vast majority of WAP browsers are currently installed), and low communications bandwidth over current wireless networks all combine to mean that WAP isn't for everyone. At the same time, I will be the first to admit that WAP can be an excellent solution for very large global workforces because it can be thought of as the "lowest common denominator" across networks, devices, and regions.
Although a "wireless web" solution may meet the needs of many, what happens if we toss in the following requirements?
Mobile users must be able to work without a wireless connection due to poor or even nonexistent connections.
Applications must provide significant interactivity.
Applications must be able to access local device/vehicle hardware, such as printers, bar code scanners, or GPS units (for mapping or Automatic Vehicle Location systems).
Bandwidth must be conserved (a common requirement on wireless networks that charge per megabyte or data transferred).
Users don't require access to truly live data, only recently modified data.
If your application meets any of those requirements, the chances are good that you will be required to build a mobile database application with synchronization. If the user can actually update the data and these updates need to be "replicated" back to the central RDBMS, bidirectional data synchronization will be required. Assuming that you're still reading (and not off designing a WAP app), I'll explain why synchronization is actually a fairly difficult problemone that is best handled by a mobile data synchronization product.