Persistent offline data storage without html5 webdb

In a good old-fashioned rant, Sam Johnston, an Australian cloud computing specialist and technology lobbyist, took offense with Mozilla’s stand against webdb in the W3C html5 webapp spec working group. On Twitter he was even more candid, writing “The anti-SQL nazis are apparently causing some real problems for offline-enabled webapps”. Although there is a lot more to Mozilla’s objections then just “developers don’t want to do SQL”, he off course is right that the decision to freeze standardization-work on webdb and to look into an alternative (web simple db) is a serious slowdown.
That’s the bad news, but let me share some good news with you as well; you can do cross-browser persistent data storage right here, right now! All you need to build a html5 webdb-alternative is old-fashioned javascript arrays and objects and related functions, some json and last but not least Paul Duncan’s persistjs (don’t download it there though, use the more recent version in the repository instead), a little javascript library that goes a long way to provide precious cross-browser persistent storage.
Simplified, your offline-enabled webapp would have to;

  1. store data in an array (or in objects in an array)
  2. do CRUD using your standard javascript functions (you could turn to something like jlinq to do more advanced things)
  3. use JSON.stringify (native or from json2.js) to turn the ‘repository’ into a string
  4. store the resulting JSON-string with persistjs’s store.set
  5. close tab or browser
  6. retrieve JSON-string when user returns with store.get
  7. use JSON.parse to turn the string into an array
  8. go back to step (2)

As code is better then a numbered list, I’ve created TrappistDB, a -very simple- demo that can do CRUD on a small persistent dataset of beer Trappist-related information.
So there you have it, basic cross-browser (*) persistent data storage without html5 webdb. Just sprinkle some appcache-magic (adding Google Gears LocalServer-support is trivial) on top to store html, js, css, … in your browser and you have a fully offline-enabled webapp.
(*) tested successfully in Firefox 3.6b5, Safari 4.0.3, Chrome 3.0.195.38, IE8 and MSIE6 (with and without Gears), IE7, the Android 1.5 browser on my HTC Hero and in iPhone’s Mobile Safari. I’ve got some weird bug in Opera 10.10 that I can’t seem to iron out though, but feel free to tell me what stupid mistake I made.

15 thoughts on “Persistent offline data storage without html5 webdb”

  1. Looks cool, I only get an ugly error in IE 8 (no gears installed): “[object Error]”.
    So maybe a small detection script before rendering the page can be useful?

    Reply
  2. This is a very intereting example. My company is working on a web application that will need to be able to let users enter data in places where there is no internet (e.g. in remotre places of developing countries), and periodically upload when internet is available. One goal is to use only the software (e.g. browser) on machine but nothing else. I’ve tried on FF4, Safari 5, and Chrome – seems very promising. Can’t get it to work on IE 8. I get a script error on line 46 cahracter 106 – it’s almost as if the code just ends after “if(” – so no Persist object is created, etc:
    me={set:function(key,val){var opt=(arguments.length>2)?arguments[2]:{},now=get_now(),expire_at,cfg={};if(
    Any ideas on what might be going on? Thanks very much. This looks promising.

    Reply
    • that’ll be hard to tackle, exp. without the app to look at what’s going on. do you see that error while on my “trappistdb” or on your own prototype? did you try contacting the author (pabs at pablotron dot org) to see if he can shed some light on this particular problem?

      Reply
      • I see the error under IE 8 on your trappistdb demo.
        I have not tried contacting pabs at pablotron – I will do that (can you tell if run under IE 8 whether line 46 is in his code?)
        Thanks for the reply.

        Reply
    • no; off the top of my head: flash is only the fallback storage engine, iOS supports multiple of the other (more default) “storage engines” (such as e.g. localstorage). hope this helps.

      Reply
  3. Thanks for the post! Unfortunately, it appears that the data which is stored in your demo is deleted when I restart my browser (possibly due to privacy settings). I’m working on an application that needs to be a little more fool-proof so that user’s can’t accidentally loose data that they entered if they botch their privacy settings and restart their browser. Do you know of any other solutions that might be more robust?
    Thanks again!

    Reply
    • afraid not dylan. what’s more, there’s not only privacy settings to take into account, but (depending on the browser) it is pretty easy to remove localstorage, appcache and webdb/ indexeddb entries by either clearing history or cache. so if you want to avoid these scenario’s, you would have to store data on a server and have the client fetch for that if localstorage, appcache, and webdb/indexeddb are empty?

      Reply
  4. This seems to be the solution for project I am working at but still I will have to confirm after I get the answer to this question. Users have to take devices to the fields where there is no internet and not just devices but the data should be already preloaded in the devices, that data includes individual information like their names, DOB, marital status, location status etc. Therefore device user will only be going to the fields to update the individual information and come back to the server to upload new status, is this possible?

    Reply
    • this should indeed be possible, but keep in mind this localstorage-based solution is sub-optimal in many ways, including performance when large amounts of data are used. a better (but less cross-browser) solution would be to implement indexedDB (firefox, chrome & IE10) and/or websql (safari, chrome, opera).

      Reply
      • Thank you, I will try that, I don’t need cross-browser because I will limit users to use or install compatible browser

        Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.