Different ways to store web data Locally - javascript

Is there anyway to have a client side small database that syncs with server side database whenever there is a change in data?
So I am looking at writing a javascript program to store a bunch of student application forms. But the internet connection is gonna be unstable as the personnel using it will be moving around campus to collect form data on his tablet.
I have looked at localstorage, but it does not have any database features.
I am really looking for technologies that can do local database entries and make asynchronous syncing easy (like what dropBox did was awesome except that it is not a web application)
I hope my question is clear
Thanks

It depends upon what kind of support you want.
Check out http://diveintohtml5.ep.io/storage.html#future where they talk about the Web SQL Database specification and IndexedDB.
It may work (Web SQL Database that is), since it sounds like a controlled environment.

following storage mechanisms when available:
Standard HTTP Cookies
Local Shared Objects (Flash Cookies)
Silverlight Isolated Storage
Storing cookies in RGB values of auto-generated, force-cached
PNGs using HTML5 Canvas tag to read pixels (cookies) back out
Storing cookies in HTTP ETags
Storing cookies in Web cache
Internet Explorer userData storage
HTML5 Session Storage
HTML5 Local Storage
HTML5 Global Storage
HTML5 Database Storage via SQLite
Copypasta from evercookie description. Several items were removed because too short lifespan and/or too few space. Do not borrow his code, tho, it uses jquery and is clumsy in the other ways.

Related

storing json data locally, should I use cookie or html5 local storage

I've started developing mobile website using jquery mobile. Since I have to carry accross multiple pages some json data I wonder what would be a better approach, storing that json data inside cookie or using html5 local storage. Both approaches would use jquery.
Scenario would be following:
Home controller returns some initial data as json
User selects some from that initial list
User selection should be stored immediatly on local storage
When navigate further on different page those data should be available (retrieving from local storage)
Either approach will work. The decision on which to use comes down to a handful of points:
Do you need access to the JSON data on the server? If so, it's simpler to use cookies (otherwise you'll have to script the page to manually send the JSON when the server needs it). Or if you rarely/never need the JSON data on the server, you'll save some bandwidth by using local storage.
Do you need to store large amounts of data? With cookies you're limited to 4K per cookie. With local storage you have access to 5 MB of space.
Are you concerned about supporting older browser versions, or some esoteric/less popular browsers that don't have HTML5 support? Cookies will work with a broader range of browsers than local storage.
Further discussion here: Local Storage vs Cookies
localStorage would be better option for your need than cookie.
Cookie send the request to HTTP during every page is loaded.

Offline storage for mobile devices?

I am writing a mobile website that needs to store some data offline, and to sync that data when there is an internet connection. It is possible to use HTML5 Web SQL Databases, but there's a space limit of 5MB. I am wondering:
Can I create multiple databases in HTML5 Web SQL Databases, so that the total size can exceed 5MB?
If not, is it possible to store offline data into a local database app (if there is any) installed on smartphones?
Thanks.
Web browsers will eventually support file access using a sandbox. But for now you are limited to webStorage, Web SQL, or indexedDB along with a data limit per domain.
Here is information on webStorage, maybe you can put some data there.
Here is some information on web SQL., but it looks like web SQL is being deprecated in favor of indexedDB. So you might want to re-consider your direction.
This would likely be your best bet - indexedDB. It is a form of no-SQL storage. Check the spec. for limits. SO won't let me post the link, but it is in caniuse as well.

Offline app : use HTML5 Filesystem API to store MySQL database

I need to build a PHP/MySQL app that allows offline access on iPads (for travelling salesmen often in deep country without internet connection). I have to manage a daily (or on demand when the device is online) sync between the local data and my remote server. I have a large database, which cannot fit in the 5M localStorage limitation. IndexedDB or Filesystem API are not available on Safari (according to http://caniuse.com/).
Is there other ways that would be appropriate to get it done?
Can't you use WebSQL? ( see question What is the maximum size of a Web SQL DB in iOS (Safari) on the iPad? How about LocalStorage? ).
If you coded it for LocalStorage you could easily use that LocalStorage API to access WebSQL on iOS devices...
Perhaps a jump to PhoneGap would solve some of your problems?
Do you need to store ALL data from your database?
I have a library for doing Syncrhonization, it's LocalStorage at the moment but the next update will allow me to use nearly any storage mechanism as it only needs one index. Purging data that is no longer required is on the list too... It's located at https://github.com/forbesmyester/SyncIt and you can even see a presentation courtesy of SkillsMatter / LondonAJAX.

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.

Categories

Resources