I am developing a mobile application using Sencha Touch. My app needs to store some data (which comes from a database, in JSON format) in the device itself, so that the app retains its previous state if it's closed and rerun.
Is HTML 5 localstorage the best possible solution?
What are its limitations/shortcomings?
If I delete the browser cookies, will I also lose the locally saved data?
What alternative do I have other than to save in web browser's cache?
LocalStorage is a viable solution, along with IndexedDB. LocalStorage is supported in more browsers, but only supports storage of strings in Name/Value pairs. Here are the support tables:
LocalStorage Support
IndexedDB Support
Another option would be SequelSphere, an HTML5 Relational Database Engine that uses LocalStorage and IndexedDB to store its data. It also has an Extension for Ext JS 4 (Sencha's big brother), and a Sencha Extension in the works. Even without an extension, it can store your data locally, provide SQL access, and put the data in a form for easy use by Sencha. As a disclaimer: I work for SequelSphere. That's how I know a Sencha extension is in the works.
When it comes to reliability, all forms of client side data storage are reliant upon the end user not clearing the data from their browser. Please note: this is usually a different option than clearing the browser's cookies.
I am currently looking to write a web app in HTML5. It is my first HTML5 web app.
The main feature of this app is its offline feature. When I mean offline, it will be something like C:\APP\index.html (for Windows ), and it will be the same thing for Mac. So with that said, I have been looking into LocalStorage, WebSQL, IndexedDB.
And I come to this conclusion that LocalStorage is not going to be good enough for the web app that I am going to write. The IndexedDB only for all the major browsers except safari. Safari (desktop & iOS) supports WebSQL not IndexedDB. And then I found out that WebSQL is not going to be supported.
So I am wondering if there is a "universal" solution to my dilemma? Or Should I have code IndexedDB and WebSQL so that it will work on all the browsers? Any suggestions are welcome.
Your app is the only thing that needs to be accessing the data it stores, right? If so, data is data is data, and as long as you include everything you need to read, write to, and understand the information your data encodes, it doesn't matter one bit (no pun intended) what format you use to store it. Whatever language you are using to create the app, it will have library functions that can manipulate stored data.
If worst comes to worst, you can always go with the lowest common denominator and use a raw binary or text file; those are the only true universal formats.
I am in the R&D phase of developing an application, with the following key requirements:
HTML5 web application - which will also have a hybrid version
Forms data will be stored locally, when no Internet connection
I cannot use web storage due to quota limitations - I am comparing SQLite and Indexed DB.
SQLite seems to be best fit, but it is deprecated
Indexed DB is a good alternative, but there's no Safari support - A hybrid application is supposed to be run on the iPad and on an Android device in the future.
I am confused in the selection of API. Is there some other alternative to SQLite or support of Indexed DB expected on Safari?
First of all, the one that has been deprecated by W3C is WebSQL not SQLite
IndexedDB -
It is incompatible with many types of mobile OS and is only compatible with certain types of versions of mobile OS
Developers cannot use SQL with IndexedDB. They can with SQLite and WebSQL
Most developers actively avoid using IndexedDB as much as they can
WebSQL -
It has been deprecated by W3C which means it is no longer maintained or developed
It requires another plugin called Polyfill to enable mobile applications to work with popular mobile OS such as Google Android and Apple iOS
SQLite -
It received an award from Google
SQLite has its official website. IndexedDB and WebSQL do not
On Google, SQLite returns 4.3 million results. WebSQL returns a bit less than 700K results and IndexedDB returns 282K results.
If you want a quick tutorial on SQLite,
Storage of SQLite database using Android and Phonegap
I think abandoning IndexedDB would be a bad idea, because it's probably the format of the future, so Safari might stop supporting WebSQL.
It appears there are various JavaScript solutions to bridge the gap between the two - saving in whichever is available on the user's browser:
JavaScript Library to Bridge IndexedDB and WebSQL
I think this is probably your best solution.
Yes, IndexedDB API is great and all browsers will support in near future.
I definitely recommend my own solution https://bitbucket.org/ytkyaw/ydn-db it is very thin wrapper for IndexedDB and fall back to Sqlite for safari.
IndexedDB is most likely the supported database of the future and it would be best to go with that instead of WebSQL. As Raymond pointed, it is best to refer to http://www.caniuse.com to see the current/future support in both desktop and mobile browsers.
Depending on the current needs of your solution, you might be fine with one of the many JavaScript libraries that are available which use the local storage and provide a query interface. One of the libraries, which has worked well for me is Lawnchair.
If you don't want to choose between IndexedDB or WebSQL you can use the Javascript library PouchDB.
I use it in an Android Webview to store offline data and it works pretty well. The data are stored on a local database (using IndexedDB or WebSQL) if there is no internet connection available and is synchronized with a remote database (CouchDB database) when there is an available connection.
PouchDB will depend on IndexedDB but fall back to WebSQL if IndexedDB is not supported. There is also the possibility to use a SQLite plugin for Cordova/PhoneGap.
I wanted to make a small edit to update this question, as google is directing to us to this question if you make a research on the subject of websql, localStorage and indexedDB. The edit was rejected, so I'm posting as a answer.
As others stated in their answers, IndexedDB lacked a bit before on support and on content on the web for it's documentation and specification.
But IndexedDB support has been vastly improved for mobile. It improved so much that the only browser who has no support or whatsoever, is Opera Mini, but it has only 0,34% of market usage.
As of 2015, I would suggest any developer to move to IndexedDB, as WebSQL has been deprecated and IE and Firefox stopped supporting it (that's more than 15% of market usage for these alone!) and SQLite is losing space rapidly to IndexedDB, which have now really good documentation sources, many. Some official as well!. Some IT companies are even motivating usage as well, like IBM.
I'm going to use it, and I have not met any problems so far. Safari has added support to it, and all major browsers as well. Go for it!
EDIT: A personnal addendum: I tried IndexedDB. I'm a Senior on my team, and IndexedDB syntax is just too messy and complex for small storage problems - I ended using localstorage to save some simple JSON data and parsing it when I need it. Way better for anyone on my team to get it (Me as well, of course!)
This may be late to the game, but you could look at: SequelSphere
It is a 100% HTML5/JavaScript Relational Database that works cross-browser and uses local storage to persist it's data. You can use SQL to query it as well. It is it's own database engine, and doesn't rely upon the built-in (WebSQL) relational databases. As such, it will work across all browsers.
While it currently only supports localStorage, the idea is to support all the standards going forward. As browsers support other types of persistence, SequelSphere would take advantage of that. The positive is that you only code against SequelSphere using standard SQL, and let it handle the persistence.
Nevertheless, be aware that it is a new product to the market, so that comes with both positives and negatives.
As other have pointed out, since this question has been asked, webSQL has been deprecated, while IndexedDB implementations now exist in all of the major browser vendors.
So to anyone who may find themselves here faced with the same decision to make, go with IndexedDB.
Others here have also implied, correctly, that a choice doesn't have to be made between the two types of databases. One can simply choose (or make) a library which utilizes whichever database is available on a client machine.
Check out BakedGoods if you're looking for such a library. It establishes a uniform interface that can be used to conduct storage operations in all native, and some non-native client storage facilities. It also maintains the flexibility and options afforded to the user by each.
With it, conducting storage operations in whichever of the database types is supported is a matter of...
... specifying the appropriate operation options and equivalent configs for both database types:
//If the operation is a set(), and the referenced structures
//don't exist, they will be created automatically.
var webSQLOptionsObj = {
databaseName: "Example_DB",
databaseDisplayName: "Example DB",
databaseVersion: "",
estimatedDatabaseSize: 1024 * 1024,
tableData: {
name: "Main",
keyColumnName: "lastName",
columnDefinitions: "(lastName TEXT PRIMARY KEY, firstName TEXT)"
},
tableIndexDataArray: [name: "First_Name_Index", columnNames: "(firstName)"]
};
var indexedDBOptionsObj = {
databaseName: "Example_DB",
databaseVersion: 1,
objectStoreData: {
name: "Main",
keyPath: lastName,
autoIncrement: false
},
objectStoreIndexDataArray: [
{name: "First_Name_Index", keyPath: "firstName", unique: false, multiEntry: false}
],
};
var optionsObj = {
conductDisjointly: false,
webSQL: webSQLOptionsObj,
indexedDB: indexedDBOptionsObj
};
... and conducting the operation:
bakedGoods.set({
data: [
{value: {lastName: "Obama", firstName: "Barack"}},
{value: {lastName: "Biden", firstName: "Joe"}}
],
storageTypes: ["indexedDB", "webSQL"],
options: optionsObj,
complete: function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});
Its simple interface and unmatched storage facility support comes at the cost of lack of support for some storage facility-specific configurations. For instance, it does not support the conduction of storage operations in WebSQL tables with multi-column primary keys.
So if you make heavy use of those types of features, you may want to look elsewhere.
Oh, and for the sake of complete transparency, BakedGoods is maintained by this guy right here :) .
I know HTML5 has offline storage capabilities. What were others doing for offline storage capabilities in the pre-HTML5 days?
For small amounts of data, cookies & response caching.
For large amounts of data, Flash (or similar plugin tech) to save files.
HTML and JS deliberately avoid having the ability to explicitly modify the client's file-system in any way, for security reasons.
You can use plug-ins like Flash, Silverlight, Google Gears to store data. You can also use cookies or browser specific features (like IE userdata). If you don't want to build your own adapter to switch between all these solutions, you can use PersistJS.
You could have built/used something like YUI's local storage library.
YUI3 - http://yuilibrary.com/gallery/show/storage-lite
YUI2 - http://developer.yahoo.com/yui/storage/
It's a combination of different ways like SWF storage, HTML5 and older browser specific APIs.
I have some questions concerning the abilities of client storage in HTML5. From what I've found so far there are three different possibilities:
WebSQLDatabase: Supports client site SQL-Tables, which are stored in a SQLite Database. This standard is discontinued. Does this mean that browsers that currently support this will drop this support in the future?
WebStorage and IndexedDB seems quite similar to me. They both offer key/value-store capabilities. Where is the difference?
WebSQLDatabase: Does this mean that browsers that currently support this will drop this support in the future?
Ans: After looking at this post, it seems like safari put this work on hold, as they have stopped comments and ping backs. Also refer to this and this, Chrome will surely put current api in deprecated status. In future versions, once IndexedDB API completely implemented, they may drop the support.
WebStorage and IndexedDB.. Where is the difference?
Ans: WebStorage has some storage mechanisms like sessionStorage, localStorage etc. each has key/value pair like storage. localStorage is of HTML5 feature which uses SQLite database, but with one table and two fields (key and value).
Whereas using IndexedDB you can create the number of databases with number of tables..
WebSQLDatabase has been dropped because of the main security issue. e.g. cross-origin attack. see