Posts Tagged: client-side storage

It’s been some time since dojox/storage, and a lot of things changed since then. Most notably: Browsers now have IndexedDB, and Dojo now has the dojo/store API that widgets can directly work with.

The dojo/store API was built with IndexedDB and offline in mind, has a nice API and allows asynchronism, meaning that it can return Promises instead of values. The only thing missing was a persistence layer that would take data via that API and store it in the user’s browser, e.g. for offline availability.

And that’s what Storehouse is: A persistent object store implementing the dojo/store API.

read more »

Note: This is a tutorial about working with IDBWrapper, a wrapper for the IndexedDB client side storage. Creating indexes and running queries only works with the new version of IDBWrapper, so if already have IDBWrapper, make sure you fetch a new version from GitHub.

All examples in this tutorial follow along the “Basic Index Example”, which uses IDBWrapper to store customer data such as name and age. You can find in the examples folder, and you can (and should) also open it in your browser, as it has a “query” section that allows you to set query options by using inputs and dropdowns to immediately see the results of your settings.

While the last part of the tutorial covered the basic CRUD methods get/getAll/put/delete, this part is about the real thing: running queries against the store.

To do so, we need to get familiar with two things: Creating indexes, and creating keyRanges.

read more »

A while ago I released IDBWrapper. If you don’t know it, it’s a wrapper for IndexedDB, a current specification (in draft status) for an in-browser object store. It’s implemented in Firefox and Chrome, and somehow (as a plugin of sorts) also in IE, but, honestly, I don’t care about that too much. Update: IE10 has an IndexedDB implementation!

It is mainly meant to serve as an example implementation, so that you could have a look at the code and see how to work with IndexedDB. But I figured that people are also interested in actually using it, as it abstracts away many of the tedious internals of IndexedDB (like transactions) – and it is perfectly fine to use IDBWrapper for all non-overly-complex scenarios.

So here’s a tutorial about how to work with IDBWrapper and a little background info about IndexedDB internals every now and then, instead of writing Yet-Another-Super-Technical-IDB-Blargh. Part one will cover some info about what IndexedDB is, getting IDBWrapper to run and how to read and write data to a store. Part two is be about querying the store.

read more »

[Note: This is a cross-post. I also published this on the uxebu blog.]

As of version 1.6, dojo comes with the new Dojo Object Store API. This is an awesome thing, as it greatly simplifies the work with data stores in Dojo. Everybody who had to do with the traditional dojo.data API felt it was overly complex and hard to use – this has finally changed now. There are also wrappers from and to the old and new APIs, so that you can do stuff like using your traditional data-aware widgets with a new Object Store. And the goodness doesn’t end here; but more on this later. If you haven’t done so yet, you might want to read the excellent post on the new Dojo Object Stores by Kris Zyp where he explains all the awesomeness he created.

read more »

[Note: This is a cross-post. I also published this on the uxebu blog.]

IndexedDB is all the buzz right now, but it is pretty hard to find information about it’s implementations. In addition to that, the impls change on a weekly basis. So I figured it would be nice to summarize every now and then what has been happening around IDB in the last time.

read more »

Right now, I’m doing some research regarding client-side storage on mobile devices. But for that, I need your help!

Please grab all phones you have and navigate to http://jensarps.de/tests/storage-tests/.

There are four tiny tests there. Please do them all and report your results for each phone. If you like, include your twitter handle so I can say thank you!

Your help is greatly appreciated!! Thanks a ton!!

It’s been some time since I last updated this blog, mostly because there’s plenty going on these days. However, there’s something I’ve been wanting to publish for quite some time now: The results of the localStorage performance tests I ran several weeks ago. As I am currently working on performance tests for Mozilla’s IndexedDB implementation, which is available in latest Minefield releases, I got reminded that there are still other results to publish – so, here we go:

read more »

A couple of days ago, Nicholas Zakas wrote an article about secure client side storage. I think the scenario he mentioned (working from a cyber cafe) is not unsafe by nature, and could be well handled by an application. Nonetheless, client side storage such as localStorage still is subject to DNS spoofing attacks (which is the main security issue, I think). To handle this, one needs to encrypt the keys and values in the store.

So here you go: dojox.storage.encrypted, a Blowfish encrypted storage. It sits on top of dojox.storage, and you get all the dojo storage manager goodness, mainly the automatic selection of the best storage provider available. It exposes the complete API that dojox.storage does. If an attacker gains access to the storage area, he can still nuke the storage, but the data found within will be useless.
read more »

– or: How to persist data in the 21st century.

The common way to persist data on the client side – application state, offline data, whatever –  still is to use cookies. But times have changed, and so have browsers, and there are better ways to do it today.

But why are cookies that bad? Well, here are the top three reasons:

1. Of all client side storage mechanisms, cookies have the worst limitation in size (4k if you want to stay IE-safe)
2. Cookies are sent to the server on every requests that matches the cookie domain – inlcuding XHR calls (aka. How to slow down your AJAX app)
3. Cookies perform bad, can be easily disabled, and, oh well, they are sooo 1995…

What else to use? There are several options, let’s start with the best:
read more »

Update: The providers attached to this post are part of dojox.storage now – no need to download them, just get a copy of dojo, and everything is there.

Update II: dojox.storage won’t make it into dojo 2.0 and is not compatible with the new dojo/store API. For future-safe persistent client-side storage, see Storehouse – Client Side Object Storage for the Dojo Store API

Last year, Brian Leroux‘s Lawnchair caught my interest – it is an easy and fast way to access local persistant local storage.

Uh, persistant local storage?

Ahm, yeah, in case you don’t know, that means a client-side storage, be it in a browser, or in an Air app. It’s not very popular, but that concept has been around for a long time. So why local? There are two major reasons for it: First, we need this for apps and tools that work offline – and apps and tools that work online but need an offline backup and sync later. Kris Zyp wrote a post about the JsonRestStore and OfflineRest back in 2008, he goes a little into detail there. Secondly, we need it for apps and tools that rely on persistence for other reasons, no matter if online or offline – like it happended to me. When I ran into Lawnchair, I had the idea to build a tool that was monitoring CSS selector usage on websites and apps (you know how you sometimes lose control about CSS selectors in webapps…). To achieve this, I needed to store data locally, and persistent.
read more »