Develop Reference

Backup local storage from smartphone

I made a webpage (todo app) that uses locale storage for saving the data in json format. I use it on my smartphone (android) so all data is stored locally on my device (ca 200 kB)
Now, I would like to backup the data somehow. I have tried different approaches (email, post form, copy-paste) but none of them has worked so far. Is there an easy straigt foreward way to do this?

You don't have control over the localStorage to that extend. But there are several ways to store data across different storages (e.g. evercookie) even though I would not use that at all (not sure how legal that is, if at all)
But the best way would probably be to backup the data on your server and periodically let your users send their localStorage to you if there were changes.
If the localStorage got wiped, then just ask the server to send back the last stored set of data for that user.
If you are using Cordova/Phonegap you might want to look into http://docs.phonegap.com/en/1.4.1/phonegap_file_file.md.html#FileWriter to create a copy of the localStorage as physical file.

When should I use PHP Session vs Browser Local Storage vs JavaScript Object Parameters?

When is it appropriate to use the many different ways that modern day AJAX based applications are storing data? I'm hoping for some specific guidelines that I can give developers. Here's what I'm seeing so far, and it's getting messy.
PHP Server Side Session: PHP Session data is probably the oldest way to store session based information. I'm often passing in parameters through various AJAX calls from JavaScript/jQuery objects - to store in PHP Session. I'm also returning objects of data (some session information) back through as a response/result to JavaScript/jQuery methods.
Browser based Local Storage: This is often used to store data that needs to persist on the front end, yet I'm uncertain at times when to use it. One good use was to store geolocation information from navigator.geolocation. I've been storing a lot of information here, but I am not certain that is wise. It never seems to expire, but can be deleted from Resources.
JavaScript Object with config parameter(s): I've been building JavaScipts objects with an init method that sets-up a 'settings' parameter. This is very useful as I usually build it from data passed in from PHP. With jQuery Mobile this data can even persist from page to page and change with AJAX request responses.
So, what guidelines would you give on usage of each?

PHP Session data is NOT Permanent Data storage as when you destroy the browsers session you will loose the Data. This is useful if you dont
want to permanently store data.
Browsers Local Storage is Permanent unless you delete the data yourself or you clear the browsers cache. Some users clear the cache from time to time so this can be a problem.
Any other method Such as Objects is not permanent Data storage.
Other Browser related Permanent storage are COOKIES (if you don't
expire them at session close), IndexedDb (Check here for current browser support http://caniuse.com/#feat=indexeddb).
So depending on your Website or App you need to decide what data needs to be
stored for a short time, or for long time or forever until you deleted it manually.
As an example, you will use LocalStorage if you were storing
Bookmarks, and if you were Storing Geolocation points you use Cookies
and expire them after you close the browser or the App.
If you were Logging in to an Account using PHP then best practice is to create a PHP
Session, and even change the session timeout when the user clicks
(Remember me).
These are just a couple of examples from thousands of possible needs.

Searching and clearing LocalStorage

I know, localStorage supports up to 5MB only. In our application we are planning use localStorage (sessionStorage doesn't fits for our need, since we support multiple tabs). Currently there is only one big javascript object serialized and stored in localStorage, in the future it may exceed up to 15 objects but definitely not more than that.
The problem is, clearing the localStorage. Since our application allows user to login in multiple ways (SSO etc...). So without landing in Login page, they can login into our application and as well as signing off in other application will sign off in our application too or close the browser. For security reason, we need to clean the localStorage once the user session is over.
So we planned to store the personId in localStorage, in every page request along with the html response we send the personId from the server, and if it doesn't match with the localStorage's personId then it will clear the localStorage.
My doubt here is, search in localStorage is not asynchronous so will it take much time to search personId out of 15 keys (Which has some large string as value)?
localStorage.setItem("personId", 1234);
localStorage.setItem("object1", "A very big serialized form of javascript object gets stored");

Writing values is really fast and there is no significant difference between large and short values: http://jsperf.com/local-storage-set
You can test the search on this site too... You could share the search code too, so others can take a look on it.

Offline webapp. How to store data?

Introduction:
App must be able to run completely offline, store data locally and post it online via AJAX whenever there is an internet connection available - this may be some days later.
Question:
How to store data using Javascript?
Additional notes:
I don't want to use any server-side technology.
It must be secure like a database. I've read about cookies and html5 storage but none of them sound convincing.

If you are supporting modern browsers, you can make use of HTML5 Local Storage.
Persistent local storage is one of the areas where native client applications have held an advantage over web applications. For native applications, the operating system typically provides an abstraction layer for storing and retrieving application-specific data like preferences or runtime state. These values may be stored in the registry, INI files, XML files, or some other place according to platform convention. If your native client application needs local storage beyond key/value pairs, you can embed your own database, invent your own file format, or any number of other solutions.
Example
// Save data to a the current session's store
sessionStorage.setItem("username", "John");
// Access some stored data
alert( "username = " + sessionStorage.getItem("username"));
// Get the text field that we're going to track
var field = document.getElementById("field");
// See if we have an autosave value
// (this will only happen if the page is accidentally refreshed)
if ( sessionStorage.getItem("autosave")) {
// Restore the contents of the text field
field.value = sessionStorage.getItem("autosave");
}
// Check the contents of the text field every second
setInterval(function(){
// And save the results into the session storage object
sessionStorage.setItem("autosave", field.value);
}, 1000);
Browser Compatibility
Older Browsers
Use Polyfill.

Depending on how complex your data structures are that you want to store you could look at indexedDB. It's availability is still pretty bleeding edge but with a polyfil you can target the majority of modern desktop and mobile browsers.
The data stored is no more secure than any other client storage model since it's meant to be read with JavaScript.
The API itself is pretty complex to dive straight into using so you might want to look at wrapper APIs such as PouchDB which syncs with CouchDB or if you want something much simpler there's db.js.

You can use HTML5 Local Storage
Use polyfill for older browser
https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills#web-storage-localstorage-and-sessionstorage

Exactly what you want:
You can set up a CouchDB instance on IrisCouch to store your data. CouchDB is a database that acts as a webserver, so it can serve html pages based on its own data -- this use of the CouchDB (to serve pages) is commonly called CouchApp.
So you learn about CouchDB and write a HTML/Javascript/CouchDB-flavored app to serve your page. There are tools that facilitate this.
After that, you only need to send the data to your CouchDB database and it will be on your web page. You'll manage the client side stuff with PouchDB, a implementation of CouchDB that runs on your browser and saves your data locally, so you never lose it, and automatically updates your local data on the CouchDB server and vice-versa. It's the bleeding edge of the offline storages on the internet.
To ensure that the clients will not send bad data to the server, you can set up authentication (so to connect Pouch with Couch you will need to provide a password) or you can set up validation functions (so the server will only accept data storage requests that match certain parameters you define). These two approaches are well explained in the guide I linked before (here), but you will certainly run into all of this during your CouchDB learning process.
A lot of stuff, but a cool solution enough for the trouble. Also, this CouchDB thing is so easy I can bet you'll read and learn everything in one or two days.

Storing persistent data in browser

For my web application, I need to store form inputs spanning across multiple pages, until I finally process/manipulate them to produce some results (its mostly formatting the data entered and presenting it in some layout). The options I think I have are -
Keep sending user's inputs to the server, store it there in some database, do the final manipulation there only, and show the result.
Store the inputs in browser's storage as the user fills the forms, and finally use this stored data to manipulate and show results.
I very much want to use the second method, and perhaps a possible way is using cookies, but I'm afraid I might just hit some upper limit of cookie data storage. I'm also open to understanding the merits of the first method, or any third method.
thanks.

Use webstorage (you can client-side store around 5MB of text or binary data)
Firefox demo: http://codebase.es/test/webstorage.html
DOM Storage is supported in these web browsers:
Internet Explorer 8
Firefox 2 for sessionStorage, 3.5 for localStorage
Safari 4
Just google for sessionStorage and localStorage objects.
Also modern webkit browsers supports client-side sql.
Edit:
I'm not sure about what you want to do but using AJAX you can store everything in javascript variables and serverside databases or sessions are a good choice.

Hitting the storage limit of the cookie could indicate you are trying to store too much on the client side. It might be prudent to store it serverside, in something like a session. The key to the session could then be stored in a cookie.
An alternative method is to not have the requests span multiple pages, and just store the data on the client side, not as a cookie, but as different form fields and/or text fields (they could be hidden). The merit of such a method is it doesnt hit the cookie limit as you have. It also makes your serverside code easier/cleaner, since it doesn't have to keep track of state (something you'd always have to do if spanning across pages, and thus the reason you are hitting the cookie limit in the first place).

You could use a small Flash Movie to store some data via Flash's Shared Memory Api or have a look at Google Gears.
Maybe also consider, that every byte you store in the cookie have to be transmitted everytime you website makes a request to the server.

Generally cookies have a max size of 4k so you could store quite a bit of data in there.
Be careful with validating all information that lives cookies - all the information resides on a client browser and can easily be manipulated by users of the site at any time.
You didn't say which platform you use. Spring Webflow does exactly the kind of form processing that you want:
http://www.springsource.org/webflow
Even if you don't use Java you could use some of the principles.
Edit: One more drawback of big/complex persistent cookies is that you have to make sure that any new code you deploy is backwards compatible with all the cookies that are out in the wild.

I would suggest storing the data in a session variable until you get to the final step rather than a cookie. I think this would be safer for your data as the user does not have direct access to the data, so you can validate as you go.