If you want to create mobile applications that perform well, one thing to consider is how to store data on the client side. This is particularly important for mobile applications because they rely on slower connections and might even need to work in offline mode (not connected to a network). Another requirement is that data must be structured and stored in a way that the mobile application can handle.

In any case, having an efficient mechanism for local storage, or caching, can greatly improve the speed and capability of your application. For example, you can use it to:

• Cache data from the web to reduce response times
• Store the state of the application interface (widgets, HTML, settings)
• Store personalization data
• Track user behavior
• And so on

Most web developers are familiar with the concept of caching, and a common method in web application development is to use a cookie. However, cookies have limitations. They only allow up to 4 KB of storage, and they pose an issue for security-conscious people and organizations that turn them off.

There are a number of other options to consider for handling local storage in a mobile application, especially if you need to store more than 4-KB chunks at a time. I will describe a couple of them here.

HTML5 local storage
The HTML5 specification now contains application programming interfaces (APIs) for local storage that are supported in the latest versions of all the major browsers, including WebKit-based browsers like those used by iPhone and Android (version 2.2 or later). This article on developerWorks does a great job of explaining how to use the HTML5 local storage APIs in a mobile app:

Creating mobile Web applications with HTML 5, Part 2: Unlock local storage for mobile Web applications with HTML 5

However, one drawback of this approach is that you can only store text keys and strings, and not more complex data structures like objects. You can work around this by using JavaScript Object Notation (JSON) methods to parse and stringify an object, but an alternative approach is to just use JSON to begin with.

Using JSON
JSON is an ideal language for data interchange. It is a human-readable text format, based on JavaScript, that is easy to use while being completely language independent. It can handle more complex data structures like objects in a database. No wonder there are a number of APIs available that use JSON to answer this local storage question, with varying capabilities—some more extensive than others.

Worklight JSONStore
IBM Worklight answers this question quite beautifully in version 5.0.5 with the addition of the JSONStore API. This new feature supports offline mode, client-server synchronization and encryption. You can use it to create an application that maintains a local copy of its data (as a JSON data store) and, on request, pushes the local updates to an enterprise system, such as a database.

Worklight Studio also provides a wizard to help generate the JavaScript code needed for the client-side application to perform these functions. A sample application that demonstrates Worklight JSONStore is available to download from the Getting Started with IBM Worklight page.

The JSONStore API is currently supported for hybrid applications that run on Android and iOS devices. If you are targeting these platforms, consider using it instead of the Worklight encrypted offline cache feature (EOC). EOC is a good option for cross-platform development, but it uses HTML5 cache, which is not guaranteed to be supported in future versions of iOS. JSONStore uses the same encryption level as EOC, and it provides more advanced capabilities, as I mentioned here.

In summary, Worklight JSONStore is another great tool to have in your arsenal for creating mobile applications with a better user experience.