IOS8 brings indexeddb to ipads; at that point it pretty much runs everywhere, just use indexeddb.
Its a pretty decent async API which supports reasonably complex queries (better than get-by-key like this), and has a (basic but working) node implementation to run unit tests against. (see http://caniuse.com/indexeddb)
Why would you use this primitive api?
Supporting older browsers is great and all, but if you dont get anything over it except giant cookies, why bother?
When this was written, iOS 8 was unannounced and folks generally just used localStorage for cross-browser storage. IndexedDB isn't as high-level as some folks would like, and key-value is handy for many apps/sites.
Even with iOS 8's support for IndexedDB, there are edge cases in different browsers localForage handles, and it handles storage of Blob data and TypedArrays transparently too, which is handy.
What percentage figures are that? I have to assume it simply relates to the Android version installed, not to the Android browser market share. Android has multiple browsers available; Chrome and Firefox work on Android <4.4 and support IndexedDB per the linked page.
I have no idea how many people use "Android browser" versus Chrome; Google is certainly pushing for higher mobile Chrome adoption. -- Okay, http://www.netmarketshare.com/ seems to indicate that Android browser market is pretty much split two-thirds Android browser, one-thirds Chrome. No idea how reliable their dataset is.
IOS8 brings indexeddb to ipads; at that point it pretty much runs everywhere, just use indexeddb.
Its a pretty decent async API which supports reasonably complex queries (better than get-by-key like this), and has a (basic but working) node implementation to run unit tests against. (see http://caniuse.com/indexeddb)
Why would you use this primitive api?
Supporting older browsers is great and all, but if you dont get anything over it except giant cookies, why bother?