I have a application which works great on all browsers but IE. I am using the local database provided with HTML5. I need to store 3 attributes for the users of the application. I know in IE I can't use the database approach and I was thinking of using 3 arrays stored in local storage, one array for each attribute. Is there a better (and easier) way of doing this?
Thanks
For example, I want to store 1) destination 2) where they are from 3) date
So I was thinking I will store an array for destinations, an array fro from locations and an array for dates. Then using some id I can index the arrays and get the corresponding information.
If you need local storage, then you need local storage! Based on the information you describe, I think it's probably too heavy to use in a session cookie.
Check out the docs. Be aware that only IE8+ supports this, so if you need to support other versions - you'll need to do some extra work.
I would personally enable localStorage where possible, then fall back to a round-trip to the server if the browser doesn't support it (and the data is definitely too much for cookies).
Update RE Polyfills
Keep in mind that the polyfills suggested by Rafael will fall back to cookies if the browser doesn't support localStorage etc. Be sure to test with a good spread of data, and keep in mind that it will be sending all that data with each request (which has it's own ramifications).
For IE, you can use a polyfill to simulate a native localStorage: https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills
LocalStorage uses a key:value system. But you can save more than one data in one key, using JSON.Stringify & JSON.parse.
localStorage in IE does not work with this url:
file:///P:/Dropbox/abc_web/ingrid8/ingrid.htm#car..
through network if it works:
file://pedrojelp/p/Dropbox/abc_web/ingrid8/ingrid.htm#car..
Related
I have been trying to find a simple solution(like HTML5 localstorage) to store data for a Chrome app.
I see they have complex storing mechanism # http://developer.chrome.com/apps/storage.html but I hate this method because retrieving data is asynchronous. To retrieve data I have todo something like.
chrome.storage.local.get(key,function(data){console.log(data)});
I hate this method because I cannot assign a variable in a simple manner.
Chrome packaged apps do not support window.localStorage.setItem(); window.localStorage.getItem();
Ended up using sessionStorage since the localStorage is disabled
Whilst its probably not a best practice, you could use
localStorage.setItem('test', 'value');
localStorage.getItem('test'); // == value
Just be careful if storing objects in localStorage - youd need to JSON encode them first.
I'm using AmplifyJS Store. I think it's a good wrapper for persistent storage. I've been using it in a JQuery plugin and it works pretty well.
Lately though, I've been wondering if I can just do the same thing using a namespace variable in the window object?!
AmplifyJS Store + JSON2.js (required for data serialization) costs me 22Kb (8Kb minified) of file size alone, not to mention the additional supporting code I've had to create around it. Also, I'm using only sessionStorage (i.e. I have no need for persistence after the browser window closes, only while the window is active).
So, is there really any major reason I can't use the window object instead of AmplifyJS Store for my specific circumstance?! I've thought about the expiry feature but I can easily build in same functionality in a few lines of code.
Thanks.
HTML5 localStorage in window object by itslef has a very simple api:
var valueOfName = window.localStorage.getItem("name");
window.localStorage.setItem("name", "value");
you can even omit global window object:
var valueOfName = localStorage.getItem("name");
localStorage.setItem("name", "val");
moreover you can apply array-style notation:
var valueOfName = localStorage["name"];
localStorage["name"] = "value";
that is it! And it doesn't have an expire date, URL strings or other complications in its API which took place in elder cookies-approach. All what AmplifyJs provides (as I can see) is a support for older browsers (who were using cookies) by givin' you the same API as original localStorage does.
In other words if you are not targeted on Netscape Navigator, Mosaic and IE 7 you can forget about using of AmplifyJS and apply native localStorage API.
However despite an approach, you should never rely on client-side persistance for sure, because it is totally dependent from local browser (client could simply clear cache, reinstall something or sign-in from other computer) - use server-side databases and similiar technologies for saving user's info.
If you are actually trying to save persistent data (data that is still there if the page reloads or the user navigates away), storing it on the window object is not an option. The data won't be there when you check for it later.
Not duplicate : I've read many questions like this and it always ended up "use PHP or server-side stuff, and watch out for injection/data manipulation".
I want to store simple stuff on the client side (save and load), like a Google Map location, and want it to stay between refresh of the page.
I don't want to use PHP or any server-side thing.
How can I proceed ?
Thanks
You can use cookies or localStorage.
If html5 is not a problem I would say localstorage is the way to go:
//set value
localStorage.setItem('todoData', this.innerHTML);
//read value
if ( localStorage.getItem('todoData') ) {
edit.innerHTML = localStorage.getItem('todoData');
}
ripped from
http://net.tutsplus.com/tutorials/html-css-techniques/quick-tip-learning-about-html5-local-storage/ :-)
There are multiple options to store data in client side - IndexedDB, localstorage, webSQL, SessionStorage, Cookies, etc.
IndexedDB
Data can be queried efficiently. No limitation in size( but volume or
disk drivers limits the size )
It will store in Key-Object format
It will not be supported in safari browser
Support Queries
Asynchronous
localstorage
It will store value in key-value format (value should be always
String)
Synchronous
Helpful if you need to store a small amount of data
Limited size (Depends on browser)
Session Storage
If the user closes the tab, it will clear the data
You can check YDN-DB here
The key issue you have to keep in mind is you can't trust the client. If it's okay for the client to ask for any location, then it's okay for you to store the location on the client side. But you can't confirm that the value that you get back from the client side is one you have given to that client.
That's what it meant by "data manipulation" [injection is a special type of data manipulation, in that it is manipulated to include things like end quote marks if you're using it as part of a SQL query or other script.]
I highly suggest using localStorage for a few reasons:
It's supported by modern browsers,
INCLUDING IE.
You can store up to 5MB of data (10 in IE) where as a cookie is mere 4KBs
There's lots of libraries to make this easy. One of the most popular is LawnChair: http://westcoastlogic.com/lawnchair/ This will actually write to multiple places, including cookies, so that data isn't lost easily.
Also, as a note, you can't store objects with localStorage, just like you cant with cookies, however you can convert them. For example, if you want to store a Date() don't store it as new Date() store it as: '\'+Date().getTime()+'\'. Same for other objects.
Use Cookie.
How to access via javascript.
How about storing it in a cookie?
For JavaScript I recommend using jQuery, which simplifies a lot of work.
e.g. http://plugins.jquery.com/project/Cookie
Take a look at HTML5 Local Storage
Is it possible to serialize Javascript object variable and store into cookies? Or is there other way to accomplish the same thing?
If these objects aren't sensitive (I.e., you don't care if your users modify them), then serializing them into cookies is fine, provided that your objects are small enough not to cause issue.
If your cookies ARE sensitive (you need to depend on them to a level of integrity) or you have large structures, then why not consider storing these serialized objects in a persistant session that is stored on your server. You can then use the cookies as a key or ID to know which session to restore when your visitor returns. In this manner, the size of your serialized objects and whether they might 'fit' in a cookie is no longer relevant.
Another possibility if you not fussy about users modifying things, but do require ample space, (although may not work for all browsers,) is to create a HTML5 'local database' or client-side storage. In this manner, you are both eliminating your concern about the size of the cookies as well as the growing size of your own server-side database. This is probably the best option for sites where you want to store a lot of data per user, but you're not sure if they'll ever come back again. You can always resort to server-side storage (see above) for older browsers.
Here's a particularly good tutorial for getting started with HTML5 local databases: http://blog.darkcrimson.com/2010/05/local-databases/
I hope this is helpful & good luck!
I don't see why not if it fit into length limit of the cookie. I would convert serialized object into say Base64 though.
What problem you're solving?
Yes, it's possible, if the resulting string does'nt exceed the limit of the cookie-size(4KB)
How can I store data in a mobile widget (JIL/W3C). Is Widget.setPreferenceForKey() the only option?
You can store small-size data using Widget.setPreferenceForKey() method and retrieve it with Widget.preferenceForKey(). There are no other options at this moment.
Not really different to Radu's solution, but it allows you to store data in a persistent way. So your widget can store data on many different devices and in the browser.
You can read about it here: http://tinyhippos.com/2010/04/11/mobile-widgets-persistence-cross-platform-wrapper/
Hope it helps.
Yes, what Radu sais, it's the only option, if you want to persist the data. Keep in mind, though, that it's a key/value store and that keys and values are strings. To store objects, you'd need to convert them to/from JSON.
Documentation sadly is rare on this, but this is a good point to start: Opera dev