Local storage and offline working a cut above the rest

Having posted a blog about our new HTML5 app at the beginning of March I’ve been asked on a few occasions about the local storage functionality, which I mentioned in my blog piece, as well as how we tested this new feature of our service management software.

We used HTML5 to build our new mobile app and this comes with local storage as a standard feature. Think of local storage as an advanced version of a “cookie” – these are used by web browsers to capture and store the application data. Our application Java script code accesses local storage to get and receive data required to support offline working.

As part of the development of our mobile app we researched other local storage options such as Indexed DB and WebSQL, but found that there is currently patchy support across browsers. So we opted for HTML5 local storage as it was supported by any browser that supports HTML5.

How local storage works within Oneserve

How it works within Oneserve is that it our mobile app stores appointment information (such as job details, work history etc) so that when someone is working in an area with little or no connectivity they are able to continue working on the Oneserve app (updating appointments, recording time, capturing signatures etc.), but offline. The example I gave in my original blog is that of someone working in a tunnel.

So local storage enables offline working by storing data on the mobile device but it also allows us to handle sending information back to the server by storing updates in a “queue”. Basically any updates that are made to appointment information when the person is working offline go into a queue (which is stored locally). When connectivity is regained, items in the queue are sent to the server, using our Restful APIs, and so information is updated on the central system.

That’s the theory anyway. And it does work! But having tested in areas with good Wi-Fi and 3G connectivity, we made a conscious decision to intensively beta-test the functionality further in an area with known poor connection availability.

Beta-testing

The objective was to trigger situations that might occur when connectivity is poor. Through a process of tests, feedback and iterative changes we re-factored the software to overcome issues such as information not refreshing and data not queuing and updating when connectivity is regained.

As part of our beta-testing we also looked at HTML5 offline queuing frameworks, none of which were compatible.

I am pleased to say that local storage is now working robustly and seamlessly, even in areas with poor connectivity. Our software’s offline working capabilities and data queuing is now a cut above what you’d expect from your average field service management software.

by Rob Lucas

Rob leads the technical effort within Oneserve and has been involved in designing and developing the product from its inception. With years of experience developing web-based business applications and leading teams, we're confident we have the best technical guy there is to provide what our customers need. And when he's not busy at work, Rob can be found spending time with his young family.