Local browser storage - how to fight short term memory loss
ChrisLaffra 060000KCEQ Comment (1) Visits (4025)
Browser applications are getting richer and richer, downloading more and more data, and allowing users to interact with that data from within the browser. When a given application is accessed repeatedly, applications end up downloading the same data over and over again. One could say they suffer from short term memory loss.
A prototypical example of such an application is gmail. For years, gmail was a true web application. Your inbox, sent messages, contacts, and all other data was download each time you accessed gmail. Since a short time, gmail is now using browser-side storage. Today, if you search your inbox, for instance, all searching is done in the browser on data that is stored in a local database.
A major argument for using browser-side storage is performance and responsiveness. By doing more in the browser, your application will start up much faster. Furthermore, you will make fewer service calls, putting less stress on the server, and reducing the amount of session state it needs to keep.
Browser-side storage can be done using various techniques (Flash, HTML5, Google Gears, etc.). In this blog entry I will show you how to easily store, update, and retrieve EGL records from browser-side storage without ever needing to make a service call to get the data.
To ease the use of the solution, I abstract out the two solution providers that I support: HTML5 local storage and Google Gears. To you, the functionality manifests itself as a library where you can simply store a record using a simple function call.
Assume we have a record type Employee:
A local storage database table for employees is created as follows:
I give the database table a name, the type of record I want to store in it, and which field denotes the key for the record.
With that in place, I can make simple operations such as:
Each of the above operations has callbacks to handle the results asynchronously. This is a requirement of the underlying browser-side storage solutions.
The attached sample puts it all together as follows:
When the application starts up, we load all employees, and add them to the grid we declared inside our UI:
That was pretty simple, not? To delete the currently selected employee, we ask the grid selector which row was selected and then delete it from the database table. Finally, we refresh the UI.
It's equally straightforward to delete a known employee, such as the employee with id == 2:
To create a new employee, we use a special utility function on the database table to compute a unique key for us. We take that unique key, add some more field, and store the record:
Local browser storage can be used for many things. One example is storage of userids and passwords to avoid them from expiring in a cookie store. Another example is caching certain data to avoid having to download thousands of records over and over.
A more advanced example is to use the support of full offline browsing when HTML5 caching in combination with local browser storage. One such example is GVButler, which is an EGL Rich UI web app that starts up on an iPhone 3GS within one second.