November 19, 2009 - Comments Off on Live blogging New York Web Standards Meetup—HTML5 part three
Live blogging New York Web Standards Meetup—HTML5 part three
HTML5 Part Three: Session, local storage, Web databases, and application cache
Marcus Lofthouse (tunecore.com) will continue the HTML5 series by exploring the following web storage techniques:
- Session and Local Storage—providing a javascript accessible interface to key-value storage.
- Web Databases—relational database support for storing structured data inside the browser.
- Application Cache—providing the ability to define a list of files the browser should store locally and not request from the server again (until you explicitly signal the browser that you have something new to offer). Strategically used, this allows for the creation of web applications that can be used completely offline.
HTML5 storage techniques
- Session/local storage
- Client-side browser databases
- Application cache
Current techniques
- Server-side storage
- Cookies: often used for customization
- Plugins (Google Gears): Not used as extensively as server-side storage or cookies
Some issues (server side)
- Requires persistent connection to the internet
- Large data sets have to be downloaded each time the page is loaded
- Can be processing intensive
Some issues (cookies)
- Difficult to work with in JavaScript
- Get sent to and from the server with each request (whether used or not)
- Limited to 4k depending on the browser
Session storage
- Allow 5–10 mb of storage
- Works in Firefox, Safari and IE 8
- Easy to use
Using session storage
sessionStorage.setItem(key, value);
sessionStorage['key'] = value;
sessionStorage.key = value;
sessionStorage.getItem(key);
sessionStorage.length;
sessionStorage.removeItem('key');
sessionStorage.clear();
Local storage
- Exactly the same—only different
- Different in scope & persistence
Session storage scope
- Accessible only to one instance of a browser tab or window
- All data is destroyed when window is closed
- Newly created windows or tabs will get a unique copy of sessionStorage; they will diverge from that point forward
- Prevents data leaking between windows
Local storage
- Accessible to all windows or tabs (for site—obeys same origin policy)
- Persistent storage between browser restarts
The base features are the same cross-browser, but each browser has its own specific extensions.
More than simple key-value pairs; can also store large chunks of XML or JSON.
Client-side database
- Provides persistent storage of well structured data
- Currently only supported in Webkit
Comments and concerns
- No standard web SQL dialect
- SQLite doesn't enforce types
- SQLite doesn't enforce data lengths
Positives
- Asynchronous DB calls keep the UI responsive
- JS interface provides an easy way to clean your data and avoid SQL injection attacks
- All database calls wrapped in transactions
- Database versioning
Opening a database
var name = 'cheesedb';
var version = '1.0';
Execute SQL statements; two flavors
executeSQL(sqlStatement, arguments);
executeSQL(sqlStatement …
Security issues
- Same origin policy
- Tools can allow users to modify their own local data.
What is an application?
- Desktop: compiled source, images, config/data files
- WebApp: HTML, images, CSS, JavaScript, config/data files
- Largest difference is delivery mechanism: webapps require you to access the sources via the internet
Application cache
- Allows you to instruct the browser to keep a local copy of a set of files.
- These files can be used offline, but more importantly won't request the resource from the server until told to do so again.
- If you specify all of the files needed to run your application you will be able to run it offline.
Application caching
- Cache manifest
Cache manifest
- Simple text file
- First line contains
CACHE MANIFEST - Following lines contain paths to files to be cached
- Document is declared as HTML5: <!DOCTYPE html>
- The cache manifest file is served with …
- New attribute for the
htmlelement:<html manifest="cache.manifest"> - The cache manifest automatically includes the file it is called from.
Other options
- Network section for content never to be cached
Updating cache manifest
- Browsers check to see if the cache file has been updated by doing a byte by byte comparison of the cache manifest file, not by looking to see if the server resources have been updated
- If the file has been changed the browser will download the new assets in the background
- Cache updating is atomic. If any file is not found, the cache manifest will re-download everything (304 or 200 requests).
Batteries about to fail; signing out
Published by: jeffreybarke in The Programming Mechanism
Tags: html5, marcus-lofthouse, nywebstandards