Retail:Developers Guide/Offline Technologies
Contents |
Web POS Offline Support
The Web POS has been designed from the beginning to be operable while being offline. This means that the user can log in the application, create transactions, and execute the cash up process while there is no connection to the backend server.
This feature can be achieved by using a combination of HTML5 technologies which will be described in this document.
Offline access to the Web POS code: the Application Cache
HTML5 brings, among several very clever improvements, the ability to define an "application cache" which contains the source code resources a web application needs to work while being offline. You can find out more about this technology here.
The Web POS supports the application cache, and uses it to ensure that all the required source code and other content files (such as images and css content) are available even without connection to the backend server.
Manifest definition
The application cache requires the definition of a manifest file, which is basically a plain text file containing all resources which should be cached by the browser. This file is automatically generated by the Web POS.
In the Web POS, all javascript static resources for the main posterminal module and all extension modules are placed in a minimized .js file. This file is added to the manifest file.
However, modules may want to add other resources apart from Javascript files. To do this, they can create a POSAppCacheResourceProvider. You can read the following document to find out how to do this.
Application Cache reset
The application cache needs to be reset every time an update of the Web POS is done, or a new module which extends the Web POS is installed or updated. This process is forced automatically, by the way the manifest file is generated.
The browser automatically refreshes all the contents of the application cache if it detects that the manifest file has changed. The Web POS uses this rule to refresh the application cache whenever it needs. The way this is done is by appending a hash code generated from the versions of the Web POS module, and all modules which depend on it.
This way, whenever the Web POS is updated, or a module extending the Web POS is installed or updated, this hash code will change, so the browser will detect that the manifest has been changed, and will refresh all the application cache resources.
Application cache on development mode
When Openbravo is on development mode (that is, when any module has its "Is in development" flag set to true), the manifest file is automatically set to an empty file. This means that the application cache is disabled when the system is in development.
Therefore, the offline login and other offline capabilities of the Web POS are disabled when the system is in development mode.
Offline access to data: the WebSQL database
The WebSQL local database is another HTML5 technology the WebPOS uses for offline operation. It's basically used both to store masterdata information (such as the product list, the price list, the list of available business partners, or the list of available discounts), and also to store the documents the user generates, before they are synchronized to the backend (such as the receipt information, new customers, cash management movements, or cash up information).
You can find more information about the WebSQL database here
The WebSQL database API: models
In the WebPOS, backbone models are defined to manage the WebSQL database. You can find more information about this [Offline_and_Online_Data_Access|here]
Customizating/Extending Offline Artifacts in your module
When your module contains artifacts (like images and css files) which need to be available offline then they need to be included in the appcache. Openbravo provides an api to accomplish this.
The adviced and most simple approach which works if your artifacts are located in the standard web folder (web/[module-package]) in your module: To register your artifacts you need to extend the BaseCoreAppCacheResourceProvider class. Your extension class can be completely empty as the abstract super class already contains logic to iterate over the files in your module. An example:
package org.openbravo.retail.orderpreparation; import org.openbravo.mobile.core.BaseCoreAppCacheResourceProvider; public class OrderPreparationAppCacheProvider extends BaseCoreAppCacheResourceProvider { }
Instead of extending the BaseCoreAppCacheResourceProvider you can also implement the logic yourselve. In this case you need to create a class which implements the CoreAppCacheResourceProvider interface. The single method (getResources) in this class should return a list of resource paths which should be added to the app cache. The resource path should be made relative to the root of the webapp, example of a relative path:
../../web/org.openbravo.retail.posterminal/res/test.xml
An example of a complete implementation can be found here.
Back to Concepts