Google Gears with jQuery, JStORM, and Rails

I have a client that wants parts of their application available offline. After looking the the various approaches to this solving this problem, it’s clear (to me at least!) that Gears is the way to go. It’s cross-platform and browser and works across a variety of mobile devices.

Rather than trying to get Gears integrated into the existing application, I decided to first put together a sample application to get it all running properly. Step two will be taking what I’ve done and stitching it into the application. Isolating it this way gives you complete control and avoids any complications that existing libraries/code may cause.

I wanted to put this out there for others to see, mainly because I couldn’t find the sort of samples I needed at the time.  And without it, it’s not as easy wrap your head around the gestalt of it. To get an app running offline, you need two basic things happen.

1. You need the physical pages available offline. This is handled via Gears’ LocalServer module. In the sample, most of this is handled in the ‘Store’ js object.  And much of the code is refactored, but based on a sample provided by Google.

2. You need a facility for storing the data locally. This is handled by Gears’ Database, which is SQLite underneath. This where JStORM comes into play. JStORM is a truly awesome javascript library that makes handling the local storage easier and better that Google’s api. From the JStORM original announcement, it ‘gives you a way to declare your tables as objects and provide a nicer OO interface than the normal Google Gears api.’

The server side application is Rails. It’s a very basic CRUD sample. The sample lets you take the application offline, and work disconnected from the internets and then put it back online. The key part there is the syncing of your local data with the remote data. In the sample, when you go offline, the remote data is brought down to the gears storage facility (SQLite). When you go back online your data is pushed back to the remote database.

jQuery glues it all together and makes use of the existing forms. Based on a cookie that flags us as offline or online,  jQuery binds to form and submits to the local database rather than the remote one. It’s pretty easy to follow what’s going on, but that after looking at it for days, so maybe not.  Email me with any questions.

As a final note, I’m sure there’s plenty in here to improve upon, so please let me know what you’ve come up with. A couple things come to mind, including automating the JStORM model creation; tying it into Rails migrations, better error handling, and perhaps syncing the model validations from Ruby to js. And more generally, building an offline component for your application is kinda cool, but tedious at the same time. It would be nice if there were a way to build in offline support dynamically. I think gearsonrails had this goal in mind, along with less involvement with javascript, but I could’t get their samples to work, and it still appeared to require quite a bit of massaging anyway. At the very least, with this approach you aren’t abstracted too far from seeing what’s goin’ on under the hood.

The code on github

Tagged as: gears, jquery, jstorm, rails