Email iconarrow-down-circleGroup 8Path 3arrow-rightGroup 4Combined Shapearrow-rightGroup 4Combined ShapeUntitled 2Untitled 2Path 3ozFill 166crosscupcake-icondribbble iconGroupPage 1GitHamburgerPage 1Page 1LinkedInOval 1Page 1Email iconphone iconPodcast ctaPodcast ctaPodcastpushpinblog icon copy 2 + Bitmap Copy 2Fill 1medal copy 3Group 7twitter icontwitter iconPage 1

For the last six months we have been working on a mobile betting application for our long standing client ABETA International. The general principle of the app is to allow users to browse betting opportunities and place bets, it works for both online game slots and sports betting. The project itself had an interesting premise which would see us delivering an application to ABETA which they could white-label for resale, either as a mobile web app or packaged as a native application. Subsequently, we made an early design decision to maximise the native experience for all users, regardless of eventual deployment decisions. To achieve this we designed for the mobile web app first, ensuring any features that were considered “core” were achievable on the web app. We also reached out to an SEO agency and found a lot of vital information on their website. The agency also recommended that we carry out guest post link building, to which, we gladly acceded. Also, after looking at the apps our client’s competitors were offering, it was clear that a highly functional and native-like web-app could provide a new USP to ABETA. Read this first prior to the free download of the application.

One of the key features of a native mobile app that is difficult to replicate on a web app is offline use. The two distinguishing features of a native app that facilitate offline use are:

  1. They can be downloaded (often from an app store) and stored on the device
  2. They are able store data on the device’s file system

Thinking of a web app in it’s purest sense, as a web page, it is easy to see why this is a problem. Traditionally a web page cannot be accessed without an internet connection and only a very small amount of data can be stored on the browser in cookies (and this has it’s fair share of problems). However, over the last few years a number of technologies have emerged under the HTML5 umbrella which give a web page (and therefore a mobile web app) access to the offline functions traditionally only associated with native mobile applications.

Specifically these technologies are:

  • Application Cache
  • Web Storage
  • WebSQL/IndexedDB
  • File System API
Application Cache (or Appcache)

Is a  technology which allows a web browser to store downloaded assets, such as HTML, CSS, javascript and images. This way, if a device does not have an internet connection the browser can load the assets from its cache (providing they have been downloaded previously) and the application can still be used. Appcache can be seen as an alternative to a native app’s ability to be downloaded and stored on a device.

Web Storage

Is a key/value pair storage mechanism which allows javascript application code to store strings of data, for example JSON or HTML, directly within the browser. The key/value pair is stored against a particular domain (like cookies) and is noticeably fast for both read and writes. There are two types of web storage – localstorage and sessionstorage, with the main difference being the former persists data across page refreshes and the latter doesn’t. We are using web storage, in particular localstorage, as our web app’s answer to storing data on the device’s filesystem.

WebSQL/IndexedDB

These are both more functional alternatives to webstorage with features such as as queries and indexing built in. However, given that WebSQL has been deprecated by W3C and browser support for IndexedDB is limited, we’ve put using these on ice for now.

File System API

This allows a browser to store data on the device’s file system. Unfortunately given that support is restricted to Chrome at the moment we’ve also held back on using this technology for now.

I’ve split this article into 2 parts with the remainder (Part 1) focussing on our use of Appcache, leaving web storage for next time.

Using Appcache in our mobile betting app

Appcache fundamentally works by the browser being instructed to download and store a specific list of assets when it loads a web page. In our case this page will be our mobile web app’s one and only page, say index.html. The list is served by the web server in a file known as the manifest and is linked-to in the page’s HTML tag.

<html manifest="proj.appcache">

In the case of our web app, we’d like the browser to cache our application files (javascript) and application UI (css and images). The manifest file looks like this:

 CACHE MANIFEST #version 0.0.6 CACHE: app-all.js app/core/util.js assets/css/app.css assets/js/libs/amplify.js assets/js/libs/async.js assets/js/libs/base64.js config.js NETWORK: * http://* https://* 

The file must start with the line CACHE MANIFEST and it’s worth noting the three main configuration options:

CACHE
Files listed under cache will be stored automatically as soon as they are downloaded. We are caching our javascript application files and css here.

NETWORK

This section specifies any assets that will can be fetched when online. In almost all cases as a minimum the wildcard entries should be specified.

FALLBACK
Allows a fallback to be served if a given asset is not available. In practice we didn’t use this option as our app was handling any offline notifications displayed to the user.

The caching process (downloading and storage of the assets) can be executed in two ways:

  1. The browser will always read the manifest file on page load and automatically download and update it’s cache
  2. The javascript applicationCache API can be used to additionally control the caching process from within the application

Our caching use-case is fairly simple – we want to download and cache the assets on application load and re-cache them when they are updated. There are however a number of quirks within Appcache which we’ve found required some consideration:

  • The browser will either cache everything or nothing. If one file fails, the entire cache will be dropped.
  • If online, the browser will always check the manifest file for changes. However if the manifest is the same (the w3c defines this as a byte-for-byte comparison), new assets will not be downloaded. We’ve followed some fairly common advice and used an incrementing version number to ensure a re-cache.
  • Even if the device is online the cached assets will still be used. This is great because it drastically reduces the app’s loading time, however you must use the NETWORK section of the manifest to ensure non-cached assets can still be fetched by the browser.
  • If the manifest is updated and new files cached, they won’t be used by the browser until the page is reloaded. This is generally not a problem, however it’s quite nice to ask the user if they’d like to reload a new version of the app. You can do this by listening for the updateready javascript event.
 //this is our Sencha Touch application object var me = this; if (window.applicationCache) { applicationCache.addEventListener('updateready', function() { //we are going to handle an update within our app - so fire ST event me.fireEvent('app-updated'); //alternatively you could use a simple JS confirmation if (confirm('The application has been updated. Would you like to reload now?')) { window.location.reload(); } }); } 
Share: