It's well-recognized that mobile business apps need to work even when not connected to the Internet or a network. But plenty of apps that promise offline capabilities don't solve the disconnection issues. And even if they do, developing mobile applications to work when offline can be expensive and time-consuming, unless architected right. Unfortunately, without offline access, an enterprise quality mobile app will fail to effectively mobilize enterprise employees and may even fail to be used at all.
The on-device database synchronizes with the master database independently of the application. So when a replication error occurs, the on-device database knows about the error, but the application itself does not. Extra code needs to be added to the application to query the on-device database to find out if there were errors and then resolve them. Handling things this way causes many problems. The mobile application doesn't know about replication errors between the on-device database and the database on the server. In a worst-case scenario, the application won't know about replication errors or be able to resolve them, and the user running the application will get incorrect information, or the corporate database won't be updated properly -- a potential business disaster.
It uses a standard HTML5 feature to handle the problems inherent in having an application work when offline -- it caches data in local storage instead of using a replica of a subset of the master database in a local, on-device database. This lets you easily create pure a HTML5 application to operate in disconnected, offline mode. The application caches edits in local storage, but when data are synchronized with the server, the communication is done between the local application and the corporation's application server. The application server in turn communicates with the enterprise's database server, updating and synchronizing data. Gone is the direct synchronization between a local on-device database and the database server. Handling offline access this way means that you can build an application to work offline in the same way that you would build it to work online. No additional code needs to be written, saving time and money. And synchronization errors are eliminated. For a closer look at how Alpha Anywhere handles offline support, check out this video.
The Typical Offline Mobile Model
The figure below shows how many mobile application development platforms handle offline apps for business. A businesses houses a database server and an application server to handle mobile applications. The device houses the mobile application and a replica of a subset of the master corporate database. The application on the device performs its operations against this on-device database, not the master database on the server. The on-device database synchronizes with the master database independently of the application. So when a replication error occurs, the on-device database knows about the error, but the application itself does not. Extra code needs to be added to the application to query the on-device database to find out if there were errors and then resolve them. Handling things this way causes many problems. The mobile application doesn't know about replication errors between the on-device database and the database on the server. In a worst-case scenario, the application won't know about replication errors or be able to resolve them, and the user running the application will get incorrect information, or the corporate database won't be updated properly -- a potential business disaster.
The Alpha Difference: Less-Expensive, Bullet-Proof Offline Access
Alpha Anywhere used an easier, less-expensive, and more bullet-proof way to build offline access into a mobile app, shown in the figure below. It uses a standard HTML5 feature to handle the problems inherent in having an application work when offline -- it caches data in local storage instead of using a replica of a subset of the master database in a local, on-device database. This lets you easily create pure a HTML5 application to operate in disconnected, offline mode. The application caches edits in local storage, but when data are synchronized with the server, the communication is done between the local application and the corporation's application server. The application server in turn communicates with the enterprise's database server, updating and synchronizing data. Gone is the direct synchronization between a local on-device database and the database server. Handling offline access this way means that you can build an application to work offline in the same way that you would build it to work online. No additional code needs to be written, saving time and money. And synchronization errors are eliminated. For a closer look at how Alpha Anywhere handles offline support, check out this video.
Comment