Offline Techniques & Sencha Touch

Offline Techniques and Sencha TouchOffline support was never particularly in demand in the world of desktops, but with the rise of the mobile web and edge connections, support for offline capability has exploded. Everything from offline data storage to the actual application startup is already available and supported on a wide range of mobile platforms. Read on to find out what tools you have at your disposal and how you can leverage Sencha Touch to use those tools with ease.

Available Tools

Let’s start out by examining our toolset with no relation to Sencha Touch or the mobile vs. desktop world. While all of these tools are applicable to both the mobile and desktop worlds, in the world of desktops you generally have a lower rate of adoption, due to (still) large IE population. However, any mobile device released in the last 2–3 years will support most of these specs, if not all.

  • Widely Adopted
  • Cookies
  • Native browser caching
  • HTML5 WebStorage
    • localStorage
    • sessionStorage
  • Limited Support
  • HTML5 Cache Manifest
  • HTML5 FileSystem
  • IndexedDB
  • Online/offline flags & events
  • Native packager APIs
  • Browser plugins

Please do research all of the above tools as there are valuable use cases for all of them. What follows is a description of the out-of-the-box Sencha Touch support for many of these tools.

Offline Application Startup

A vital part of offline support is being able to launch your application when no network connection is available. There are two ways you can go about this and both have Sencha utilities to make your life easier. Also, both approaches give you significant performance improvements during load time.

Offline Startup: Packaged Apps

Using Sencha Command, you can package a Sencha Touch app and deploy it to app stores (i.e. Google Play or iTunes). Please consult the guide, but after some minimal config the actual command to run is:

sencha app package config.json

…to get your .app or .apk file. This is further trivialized by GUI support in Sencha Architect, where all you need to do is hit a button:

Once you have deployed a packaged app on a mobile device, the offline startup portion is taken care of — think of starting up an installed application on a desktop.

Offline Startup: Web Apps

You don’t need to package a Sencha Touch app to get the look and feel of a native app. Same goes for being able to launch it offline, in this case you can use HTML5 Cache Manifest. There’s one caveat though: a user must have previously accessed the application with a network connection in order to have cached the application. “Caveat” may not be the right word, as this is technically an easier step than having to download the application from an app store.

So, how does Sencha Touch make your life easier in this case? Well, if you used Sencha Command to generate the app, you would find an app.json file in your application folder, containing the following section:

"appCache": {
        /** List of items in the CACHE MANIFEST section */
        "cache": [],
        /** List of items in the NETWORK section */
        "network": ["*"],
        /** List of items in the FALLBACK section */
        "fallback": []

Note how similar this section is to the actual HTML5 Cache Manifest spec. All you have to do is fill in the resources you want included in your generated cache.appcache, and whenever you use Sencha Command to build a production version of the app, the manifest references will be included in your index.html (which means you don’t have to worry about Cache Manifest woes during development).

Offline Data Access

So you’ve got your app launching offline, but what good is that if it still needs to access your server to display any data? This brings us to the three most useful HTML5 storage mediums: localStorage, sessionStorage, and WebDB. Luckily, the Sencha Touch data package offers awesome wrappers around all three.

Let’s consider a fictitious application where you have a list of contacts with various details for each contact and it’s mission critical that this data is accessible offline. The actual list (or data view) contains a store configuration which defines where the data comes from. Let’s examine the potential Sencha Touch stores we could use that would work regardless of the network connection status.


sessionStorage is not a persistent storage, meaning it gets wiped whenever the user leaves the page or closes the application. However, in case of one-page web apps where you stay on the same page the entire time, sessionStorage can be a perfect candidate for offline data access, especially in data-sensitive scenarios where you don’t want the data persisted on the device after the user is done using the app. sessionStorage is generally limited to 5MB in size and when that is exceeded, depending on the platform, either a JavaScript error might be thrown, or a popup is presented to the user asking for permission to increase the available storage. So, how does one configure sessionStorage for use with a list in Sencha Touch?

        proxy: {
                type: 'sessionstorage',
                id  : 'myProxyKey'

That’s all, folks! Amazingly simple, isn’t it? Now you can store and retrieve data from the store as you would with any other app.


localStorage is essentially the same thing as sessionStorage, except it is persistent. In other words, if you close the app and return, the data will still be there. localStorage is more suited for data that you want to be available when used in combination with the offline startup techniques discussed earlier. Sencha Touch configuration for localStorage looks almost identical to that of sessionStorage:

        proxy: {
                type: 'localstorage',
                id  : 'myProxyKey'


WebDB, also known as WebSQL, though deprecated almost three years ago, is still supported by almost every browser except Internet Explorer and Firefox. Though specs call for 5 MB limit per origin, iOS has been known to allow up to 50 MB after multiple user prompts. Behind the scenes it’s an SQL database with a query-based language that many of us know and love. When it comes to configuring it in Sencha Touch, it is just as easy as with the other storage mediums:

Ext.create("", {
        model: "User",
        proxy: {
                type: "sql"

…note that I did not omit the “model” configuration in this case, as it is used to name the underlying WebSQL table.

Synchronizing to the Backend

Being able to work with local data offline is only one piece of the puzzle. Being able to synchronize the offline data with a server as users come online and go offline, and being able to synchronize that data across multiple devices, is a much bigger topic beyond the scope of this blog post. However, there are already a number of frameworks in existence targeted at addressing this very task; I invite you to do further research on:


Using HTML5 offline storage mediums not only gives your applications offline capability, it also boosts your application’s performance. While many web apps do not require offline support, consider it as a benefit to the user. Faster and more accessible apps means happier users. Leveraging Sencha Touch and Sencha Command means it takes almost no effort to make use of these great and widely adopted HTML5 features.


  1. Kyle Brost says

    Although this article is a good overview. I was really hoping that there would be a good example of using offline and online Data Stores with Sencha Touch. It’s like the article introduction paragraphs was written and then… Doing anything useful is outside the scope of this article. Would be nice to see practical examples

  2. Joeri Sebrechts says

    I’ve built an offline mobile app with sencha touch and appcache in the past. I don’t necessarily agree that it has limited support, as it seems the vast majority of mobile devices have a consistent implementation of it, and those devices that don’t gracefully degrade into online operation. It is just very tricky to work with due to a lack of a body of knowledge on what approach to take with it. I’ve found that for me the biggest difference was to have the right mental model. You have to pretend like you’re installing an app from an app store, where the appcache manifest describes all the resources from the app, and their version. The installation happens on the first visit to the URL. Updates happen asynchronously by successive visits, just like with native apps, so when you launch the app you get the previous version and not the current version and have to build your code around this assumption (assume that your app and its web services have different versions). By having this mental model that it is a locally installed app where updates happen asynchronously to the running of the app, I’ve found that you can get a reliable performance out of appcache.

Leave a Reply

Your email address will not be published. Required fields are marked *