This is might be a dump question but i could not figure it out why.
So, i have to permanently store some configuration number into the browser, so if the app reload, it can get those config number right away. I think we can do it by using localStorage.
I implemented and got it working, using :
localStorage.setItem('token', 'fsdfdsfsdfdsfds');
localStorage.setItem('config1', 'config1');
localStorage.setItem('config2', 'config2');
localStorage.setItem('config3', 'config3);
However, after 2 hours all of the config1, config2, config3 are gone. Only the token one still exists in localStorage. I though that item in localStore should stay as long as we want. We have full control over it.
Any explain here ? Thanks
I suggest you use Chrome.storage.api, the data will persists when you close the browser. Works the same, key/pairs are stored and retrieved. I stopped using localStorage when I can do the same in Chrome.storage api.
I'm not sure how Chrome handles localStorage in incognito mode so I can't give you a detailed answer but one thing I know is that you can't rely on localStorage in incognito.
Check MDN -> Web Storage API -> Private Browsing / Incognito modes
Most modern browsers support a privacy option called 'Incognito', 'Private Browsing' or something similar that doesn't store data like history and cookies. This is fundamentally incompatible with Web Storage for obvious reasons. As such, browser vendors are experimenting with different scenarios for how to deal with this incompatibility.
Most browsers have opted for a strategy where storage APIs are still available and seemingly fully functional, with the one big difference that all stored data is wiped after the browser is closed. For these browsers there are still different interpretations of what should be done with existing stored data (from a regular browsing session). Should it be available to read when in Private mode? Then there are some browsers, most notably Safari, that have opted for a solution where storage is available, but is empty and has a quota of 0 bytes assigned, effectively making it impossible to write data to it.
Developers should be aware of these different implementations and take them into account when developing websites depending on Web Storage APIs. For more information please have a look at this WHATWG blog post that specifically deals with this topic.
Related
I am working on a site for an intranet. I want to optimize for performance, and I know the script I am loading won't have frequent changes to it. Is it better to cache the string of it (from an xhttp request) into local storage along with an expiry time like an hour or so. And then load from local storage and insert dynamically into the DOM.
Does anyone know if this method is still a good one to use? The browser I need to use is IE11 (IE10 rendering mode). Or chrome 49.
Thanks
Forget "still," as described this was never a good idea. The web browser can handle all of the caching for you, just set appropriate cache headers (in your case, to not bother to check back — not even an If-Modified-Since request — for an hour, as that's what you describe doing with local storage) and let the browser do its job.
I have a single page application, which loads a JSON data file from a server and displays it on the client. The data file only changes once per day, so after fetching it, I want to keep it cached on the client. So far, I have been using jStorage and am happy with the overall result. One thing is problematic though: according to the jStorage Browser support page, the cache size varies from browser to browser.
So my question: can I somehow find out if jStorage will be able to store all my data? The jStorage website itself does not give any clues to that.
Alternatively, since I'm only storing one big object, I could use a plug-in like sizeOf to check the object size before saving it, but I don't know if that is a reliable approach.
I am not sure how jStorage implements, you say 5mb so I guess it's using localstorage. Have you tried indexedDB which is browser native and theoretically limit to your hard drive capacity.
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API
I'm developing a Chrome extension and I need to store some data and then get it in some point. I did investigation on available storages and came across to the following ones: window.localStorage and chrome.storage.local.
So my question is, which one is the right choice to use in Chrome extensions:
window.localStorage or chrome.storage.local?
P.S. I'm using browser action to load a local HTML in IFRAME. So I'm not using popup.js.
localStorage
Pros:
Synchronous, and thus easier to work with: var value = localStorage[key]
Has support in Dev Tools: Resources > Local Storage to view and modify.
Cons:
Only stores strings, therefore you need to serialize data yourself, i.e. with JSON.stringify
Is not accessible from content scripts (or rather, context scripts share it with the page and not the extension), so you need to rely on Messaging to pass values to them.
Synchronous AND shared between concurrently-executing extension pages, leading to possible synchronization issues.
chrome.storage.local
Pros:
Automagically serializes JSON-compatible data, can store non-strings with no additional boilerplate.
Fully available within Content Scripts.
Supports events that notify about changes: chrome.storage.onChanged
With "unlimitedStorage" permission, can hold arbitrarily large amounts of data.
Has a nice built-in mechanism for default values:
chrome.storage.local.get({key: defaultValue}, function(value){/*...*/});
Fully supported in Firefox WebExtensions and Edge Extensions.
Cons:
Asynchronous, therefore a bit harder to work with:
chrome.storage.local.get("key", function(value){/* Continue here */});
Not visualized in Dev Tools; one needs to call chrome.storage.local.get(null) to get all values or use something like Storage Area Explorer.
chrome.storage.sync
Same as above, but:
Pros:
Automatically synced between signed-in Chrome instances, if extensions sync is enabled.
Cons:
Inflexible quotas on data size and update frequency.
As of 2016-11-06, not yet supported in either Firefox WebExtensions or Edge Extensions, so non-portable.
Note: storage.sync is now FF WebExtension compatible, though there is no way to make Chrome and FF natively sync between each other.
It depends entirely on what your Chrome Extension will be doing. window.localStorage is HTML5 storage. Unless you're running it in the background page, it can only allow you to get and set data into storage for a specific domain. This is also true for code injected into the DOM, since it would use the localStorage on the web page.
In other words, you won't be able to share data across different web pages unless you use localStorage in the background page, which operates independently of web pages, since it has a chrome:// URI as its domain.
chrome.storage.local, on the other hand, is designed for Chrome Extensions and Chrome Apps to store data in a more central location. Since this isn't accessible to normal web pages, each Extension gets its own storage. One possibility is for your background page to handle dealing with the setting and getting of the data, while your content scripts deal with modifying and interacting with the web page.
However, these API's work in content scripts as well, and both of the extensions I've written use chrome.storage.local called from the content scripts.
As an example, I built a Stack App that preserves inbox items in Stack Exchange until you've actually read them, called StackInbox. Since Stack Exchange sites span across hundreds of domains, I chose chrome.storage.local because I could save the user's accountId and reuse it across all the sites, ensuring that the inbox data is synchronized, while also using this directly in the content script.
As a simple test, put some data in localStorage on one domain, in a content script, and try to pull it from another, and you'll see that the data won't be there. With chrome.storage.local, this isn't a problem.
Lastly, Chrome Extensions and Chrome Apps are whitelisted, since the user chose to install it, so they typically can do more things than a normal website. For instance, by specifying the "unlimitedStorage" permission in your manifest, you can store data well beyond the 5MB limit placed upon HTML5 localStorage.
For more information, see Google's documentation on Chrome Storage.
We are in process of building conceptual model of web-based audio editor. And the first trouble we met is client-side caching system. In my opinion as server-side programmer having huge cache on client side is perfect idea, because in many cases it takes of server load by excepting multiple loading of the same data. Furthermore such cache could be good candidate for buffer for providing per-track operations, like filtering.
Our flex programmer says that this is a great trouble and it is impossible in almost any cases. But I am in great doubt, cause I know that actual Google Chrome browser version can simple keep up to 2 Gb in localStorage. Moreover I've found this example of online track-editor and looks like its caching mechanism working pretty good.
Is it possible to cache some data (smth about 100-200mb) on the client side using flash and js?
You can use SharedObject to store the data.
I am pretty sure that default size limit is too low for your needs, so your app will need to ask user to accept your new limit:
http://www.macromedia.com/support/documentation/en/flashplayer/help/help06.html
SharedObject is more reliable than the browser cache, and you control it from your app.
If you are using html5 then you can store large data on client side using html5 inbuilt database.
also refer this link
What we did when writing a video editor. Well, actually, in Flash you can save files to the user's machine, with the restriction that it must be transparent to the user (i.e. the user initiates the action, goes through the OS dialog and saves the file as they would normally save anything they download), similarly, you can load in a file from a user's computer, with the restriction that the user must initiate the action (as in by clicking with a pointing device or pressing a key).
This has certain advantages over different local storage strategies, which are mostly opaque to users (people don't usually know how to erase cookies, SharedObjects or web storage that comes with more modern browsers, but they are pretty much capable of saving and deleting the files on their system). Furthermore, all other opaque local storages may have restrictions that less savvy users might not know how to overcome / may not be possible to overcome in general - these would be size, location and ownership.
This will still be a bit of hindrance for your audience, because every time they need to save a file, they have to go through the OS's dialog, instead of doing Ctrl+S / Cmd+S / C-x C-s... But given all other options, this, IMO, leaves the user with the most choices / delivers best experience.
Another suggestion - you could, in principle, come up with a browser-based "enhanced" version of your application, which users would install as a browser plugin (if that's an editor they are using on a regular basis - why not?), in which case you wouldn't be limited to the clumsy options provided by web technologies. Chrome and Mozilla-based browsers encourage such development, however it's not standardized. Still, since these two browsers run on virtually any OS, that doesn't sound particularly as locking in your users into a certain platform...
I am using the localStorage in this demo here,
http://help.arcgis.com/en/webapi/javascript/arcgis/demos/exp/exp_webstorage.html
Basically it is a mapping application which caches map tiles in the localStorage.
I quite quickly reach the 5MB limit and from then onwards I get errors, QUOTA_EXCEEDED_ERR.
How can I extend the localStorage? Or what other options do I have to store data on the client side in HTML5, has anybody used the indexdDB, does it work in chrome?
http://www.w3.org/TR/IndexedDB/
And of course the web database specification has been deprecated so I would like to avoid that,
http://www.w3.org/TR/webdatabase/
My understanding is that the user can extend localstorage but the website can't (by design). You simply need to catch the error in Javascript and show the user a dialog requesting they increase their storage limit - preferably providing some instructions for major browsers.
EDIT: Perhaps not so simple. It seems some browsers don't allow the user to increase the storage size. Google seems convinced the localStorage API doesn't scale well to large files and developers should consider IndexedDB instead.