Asynchronous Key/Value Pairs

The main purpose of this asyncStorage API is to store large amount of data as string, including base64 version of images or other files.As it is, usually, values are the bottleneck, RAM consumption speaking, while keys are rarely such big problem.However, while keys are retrieved asynchronously and in a non-blocking way, but kept in memory, respective values are always retrieved asynchronously in order to do not fill the available amount of RAM for our Web Application.

Getting All Items Keys

If this is really what you need to do, bear in mind the API is the same used in the localStorage where indeed there's no way to retrieve all keys if not doing something like:

for (var keys = [], i = db.length; i--;) { keys[i] = db.key(i);}

Getting All Items

Well, the thing here is that you can store an entire object through JSON so if you need to save and get back everything, it's kinda pointless to store different keys, just use one.However, this is how I would do this task:

On Github, Of Course

You can find full API description in this repository. Please forgive me if the name was initially db.js, I believe the new one, asyncStorage.js, is much more appropriate (also another guy created a script called db.js so ... well, I have avoided conflicts with that library).

That's Pretty Much It

And I hope you'll start using this API to avoid blocking mobile and desktop browsers when you store a lot of data ;)

6 comments:

Regardless of maxNumberOfItems, perhaps this function should take a parameter, in case anything bad happens? (like, the developer didn't respect numberOfItems)

As I see the implementation, errorCallback isn't called ever by the cookie on set. Question is, are success and error worth two callbacks or it is better to make it one nodejs style?

BTW, the variable readTransaction just magically appears in WebSQL, (it's defined in indexedDB), I don't know if it's a bug which accidentally works (by having the right order in build), or it was deliberate..

Aadaam, numberOfItems is simply the equivalent of db.length, it might be useful to know if there are items stored already or none of them (e.g. very first time)

However, I find the second argument redundant so this might change soon or be removed.

If anything bad happens you can send the second callback, as it is for Web SQL Database.In the git repository you have full specs for the API, in this case would bedb.setItem(key, value, callback, errorback);where both are optional in case you just want to store something without actions after.

The cookie version is really IE less than 8 story, I need more time to test there properly after implementing failures in the test to cover all error cases too.This is in the TODO list at the end of the git repository.

readTransaction is defined the first time in asyncStorage.js, then IndexedDB borrows some variable reference/type just to make minifiers life easier having slightly better ratio over shrinking.

It looks weird, but it does the job right now and yes, the order of definition is relevant for those 3 variables (executeSql too)

Klaitos, whenever it makes sense to you to store big amount of serialized data (through JSON, as example) you can use this API without problems ... tests are green, if you find cases where it fails, well, feel free to poke me ;-)