HTML5 Storage
Why Local Storage?

Data accessed over the internet can never be as fast as
accessing data locally

Data accessed over internet not secure

HTML5 storage is on client
Persistent Local Storage
•
Native client applications use operating system to store data
such as preferences or runtime state
•
Stored in registry, INI files, XML or other places using key/value
pairs
•
Web applications can’t do this
Cookies
•
Invented early in Web’s history as a way to store persistent data
(“magic cookies”)
•
Small pieces of information about a user stored by Web server
as text files on user’s computer
•
Can be temporary or persistent
Cookies
•
Included with every HTTP request – slows down application by
transmitting same information repeatedly
•
Sends unencrypted data over internet with every HTTP request
•
Limited to 4KB data
•
Example: filling out a text form field
Cookies not enough
•
More storage space
•
On the client
•
Beyond page refresh
•
Not transmitted to server
History
IE: DHTML Behaviors
• userData behavior allowed 64K per domain
• Hierarchical XML-based structure
Adobe Flash (2002)
• “Flash cookies” or Local Shared Objects
• Allows Flash objects to store 100K data per domain
temporarily
History
AMASS (AJAX Massive Storage System)
•
•
•
Brad Neuberg
Flash-to-JavaScript bridge
Limited by Flash design quirks
Flash 8: ExternalInterface (2006)
•
Easier to access Local Shared Objects
AMASS rewritten
•
•
•
Integrated into Dojo Toolkit: dojox.storage
100KB storage
Prompts user for exponentially increased storage
History
Google: Gears (2007)
•
•
•
•
Open source browser plug-in
Provides additional capability in browsers (geolocation API in IE)
API to embedded SQL database
Unlimited data per domain in SQL database tables
By 2009 dojox.storage could auto-detect and provide unified interface
for Flash, Gears, Adobe AIR and early prototype of HTML5 storage (in older
version of Firefox)
Previous Storage Solutions
•
Either specific to single browser or relied on third party plug-in
•
Different interfaces
•
Different storage limitations
•
Different user experiences
HTML5 Storage
•
Provides standardized API
•
Implemented natively
•
Consistent across browsers
•
HTML5 storage is a specification named “Web Storage”
•
•
•
Previously part of HTML5 specifications
Split into its own specification
Different browsers may call it “Local Storage” or “DOM Storage”
Web Application Support
•
Supported by latest version of all browsers!
IE
8+
Firefox
3.5+
Safari
4.0+
Chrome
4.0+
Opera
10.5+
IPhone
2.0+
Android
2.0+
•
Access through localStorage object on global window object
•
Before using, detect whether browser supports it
Check for HTML5 Storage
function supports_html5_storage() {
try {
return 'localStorage' in window
&& window['localStorage'] !== null;
} catch (e) {
return false;
}
}
Or use Modernizr
if (Modernizr.localstorage) {
// window.localStorage is available!
} else {
// no native support for HTML5 storage :(
// maybe try dojox.storage or a third-party solution
}
Using HTML5 Storage
Using HTML5 Storage
localstorage object
setItem( )
getItem( )
removeItem( )
clear( )
Using HTML5 Storage
Tracking changes to the HTML5 storage area
if (window.addEventListener) {
window.addEventListener("storage", handle_storage, false);
} else {
window.attachEvent("onstorage", handle_storage);
};
Using HTML5 Storage
Tracking changes to the HTML5 storage area
The handle_storage callback function will be called with a
StorageEvent object, except in Internet Explorer where the event
object is stored in window.event.
function handle_storage(e) {
if (!e) { e = window.event; }
}
Using HTML5 Storage
StorageEvent Object
PROPERTY
TYPE
key
string
DESCRIPTION
the named key that was added, removed, or modified
oldValue
any
the previous value (now overwritten), or null if a new item was
added
newValue
any
the new value, or null if an item was removed
url*
string
the page which called a method that triggered this change
Using HTML5 Storage
• Limitations in current browsers:
• 5 MB of storage from each origin.
• Can not ask user for more storage (except for Opera,
sort of)
HTML5 in action
HTML5 in action
function saveGameState() {
if (!supportsLocalStorage()) { return false; }
localStorage["halma.game.in.progress"] = gGameInProgress;
for (var i = 0; i < kNumPieces; i++) {
localStorage["halma.piece." + i + ".row"] = gPieces[i].row;
localStorage["halma.piece." + i + ".column"] = gPieces[i].column;
}
localStorage["halma.selectedpiece"] = gSelectedPieceIndex;
localStorage["halma.selectedpiecehasmoved"] = gSelectedPieceHasMoved;
localStorage["halma.movecount"] = gMoveCount;
return true;
}
function resumeGame() {
if (!supportsLocalStorage()) { return false; }
gGameInProgress = (localStorage["halma.game.in.progress"] == "true");
if (!gGameInProgress) { return false; }
gPieces = new Array(kNumPieces);
for (var i = 0; i < kNumPieces; i++) {
var row = parseInt(localStorage["halma.piece." + i + ".row"]);
var column = parseInt(localStorage["halma.piece." + i + ".column"]);
gPieces[i] = new Cell(row, column);
}
gNumPieces = kNumPieces;
gSelectedPieceIndex = parseInt(localStorage["halma.selectedpiece"]);
gSelectedPieceHasMoved = localStorage["halma.selectedpiecehasmoved"] == "true";
gMoveCount = parseInt(localStorage["halma.movecount"]);
drawBoard();
return true;
}
HTML5 in action
•
In the saveGameState() function, we did not worry about the
data type:
localStorage["halma.game.in.progress"] = gGameInProgress;
HTML5 in action
•
But in the resumeGame() function, we need to treat the value
we got from the local storage area as a string and manually
construct the proper Boolean value ourselves:
gGameInProgress = (localStorage["halma.game.in.progress"] ==
"true");
HTML5 in action
Similarly, the number of moves is stored in gMoveCount as an
integer. In the saveGameState() function, we just stored it:
•
gMoveCount = parseInt(localStorage["halma.movecount"]);
HTML5 in action

But in the resumeGame() function, we need to coerce the value
to an integer, using the parseInt() function built into JavaScript:

gMoveCount = parseInt(localStorage["halma.movecount"]);
Beyond Key-Value Pairs: Competing Visions
Beyond Key/Value Pairs: Competing Visions
2007 – Google Gears (based on SQLite) -> Web SQL Database
openDatabase('documents', '1.0', 'Local document storage',
5*1024*1024, function (db) {
db.changeVersion('', '1.0', function (t) {
t.executeSql('CREATE TABLE docids (id, name)');
}, error);
});
Beyond Key/Value Pairs: Competing Visions
Web SQL Database
The Web SQL Database specification has been implemented
by four browsers and platforms.
Safari
4.0+
Chrome
4.0+
Opera
10.5+
Mobile
Safari
3.0+
Android
2.0+
Beyond Key/Value Pairs: Competing Visions
SQL-92
Oracle SQL
Microsoft SQL
MySQL
PostgreSQL
SQLite SQL
Beyond Key/Value Pairs: Competing Visions
Indexed Database API
Formerly known as WebSimpleDB
Now colloquially referred to as “indexedDB”
Beyond Key/Value Pairs: Competing Visions
IndexedDB
object store
Shares many concepts with a SQL database:
• Records (keys or attributes)
• Fields (values)
• Datatypes
But no query language!
Beyond Key/Value Pairs: Competing Visions
Firefox 4: An early walk-through of IndexedDB
HTML5 Rocks: IndexedDB example