I have a web application that uses a lot of offline storage. It was running good until the data increased and reached around 8MB. Whenever storing that much data to the WebSQL, I received error stating "The inspeted target has crashed." I assume that it has to do with the storage capacity, although I am not sure. Since everything was working fine until the data increased, I would like to check after increasing the WebSQL capacity. There is a post I read that talk about creating a manifest.json file. My question is
Does this work for web applications?
Where is this file placed?
What are the furhter steps to take after creating this file?
What about other browsers? Does this solve problem for only Chrome?
I think this has something to do with the implementation of your WebSQL. I have offline databases in WebSQL that are well over 100MB and load in Chrome without a hitch.
Related
I have a 6MB binary file in my AppEngine backed app. I need to get this file to my GWT client to do many computations. I'm trying to avoid doing the computations on the server to save my instance hours quota. But this means I have to get the file to my client somehow.
I also don't want to download it to the app each time the app is opened, that would hurt my appengine outgoing bandwidth quota.
It would be nice to download it once, then have the client somehow store it for use the next time the app is opened.
How to best do this?
A ClientBundle? Use HTML5 Storage? Is this sort of thing just not done, and should I just do the computations on the server and send the result to the client?
The most easiest way to permanently cache the file is using application cache.
Another ways is HTML5 Storage (localStorage), but there is 2.5 MB limit. To use more than that amount, you have use IndexedDB (Chrome, Firefox, IE10) and WebSQL (Safari, Opera). A wrapper library like YDN-DB help in this case.
You can use DataResource:
https://developers.google.com/web-toolkit/doc/latest/DevGuideClientBundle#DataResource
The only problem you face is the file size. Different browsers have different limits - I've seen 5MB and 8MB numbers. If you can compress your file to be under 5MB, you should be fine with most browsers. (By the way, it's an enormous amount of data if it can't be compressed any further.)
Also, you can detect a mobile browser (or offer a different URL for mobile version), and do computations on the server for mobile users.
I had a doubt regarding HTML5 storage technologies like WebSQL, WebStorage/LocalStorage, and indexedDB and to a lesser extent appCache.
Considering the case of chrome (my default browser), these stores are maintained in chrome browser's own directory. Do they impact the starting-up time of the browser?
A colleague has said to experience browser slowing down or behaving in sluggish manner when a larger amount of data is stored.
Couldn't find references to how these technologies impact the browser working, so would love if any fellow-stacker could guide me.
Be careful : the WebSQL API is dead (it was based on sqlite instead of a generic API and so was judged not desirable by the Mozilla team, the Indexed Database API will be used instead but you should probably wait for it to be more supported).
LocalStorage is fine, I use it in all my web applications without problems nor measurable boot time. But keep it for parameters, preferences, and so on, as the only reliable storage is always server side. The local storage can be removed, lost, modified, not readable for many reasons (user uses another browser or computer for example). And it seems to me that a big local storage is a burden to the user and thus not very correct (which is probably the reason why this size is limited).
BTW, there is no reason a reasonnable local storage could slow in a measurable manner the launching of a browser.
I agree with dystroy; Normally the local storing is harmless if done the right way. Storing MASSIVE amounts of data in the browser on the other hand is quite discouraged. It won't slow down the browser performance overall but will slow down the web app using it (as far as I know, Chrome fetches the local storage values dynamically when the 'owner app' is called).
With HTML5's offline capabilities is it possible to create an app that will persist after the connection is lost and the browser is closed? Specifically, here's what I'd like to do:
Connect to the app while online. Download the entire app including a small database it runs on.
Close the browser and disconnect.
Open the browser again while offline and load the app from the local cache.
Thanks to Mark Pilgrim's excellent book I believe I have an idea of how to accomplish the first step, I'm mainly wondering if the last step is possible. If this is possible, I'm guessing it requires some configuration of the browser. Any settings I should be aware of that aren't obvious?
Thanks very much for any help offered.
The last step should be possible - it just depends on what extent you want to implement it to. To my knowledge it shouldn't require any browser settings. You just have to be aware of the limitations of local storage, which I believe is 5mb max at the moment (for most browsers). Obviously you'd have to perform the checks for such permissions as outlined int the Dive Into Html5 guide you linked.
The quickest and dirtiest way is to simply issue a GET request to your online app. If it responds correctly, then use the online version. If not, use the local cache. Just disguise the timeout/failed response as a 'loading' screen.
I am building a mobile app that must work in Blackberry, iPhone and Android phones. I am building this mobile app in HTML5, CSS and JQuery Mobile. Then I will use PhoneGap to allow the code to run as a native mobile app for the phone. The mobile app must be able to work without connection to the internet. The only time the app must require an internet connection is when it loads for the first time, because that's when the app will download over 50 MB worth of data. Next time the app has internet connectivity, it will poll the server for more recent data to consume.
My problem lies in where do I store 50 mb worth of data which can be updated when internet connectivity exists?
Additional Notes
I've been discouraged by others to use Web SQL Database because the specification is no longer in active maintenance. I've read that localStorage and cache manifest has a storage limit of about 3-5 mb depending on the browser. From experience, I've encountered a lot of challenges working with the PhoneGap API to create one set of code that will reliably write to all of the following file systems: ios, bb, android.
Based on your needs: (store 10,000 images, 10,000 pdfs, +videos etc.) I don't think a "lightweight" HTML5 application is going to suit your needs.
I think that a native application is likely going to work much better where you have proper filesystem access to store the files on the device as needed (and even structure them better).
The HTML5 localStorage (5mb) and the WebSQL (SQLLite) (5mb-~50mb) database options really won't give you what you need as far as I can tell.
WebApp "wrappers" like PhoneGap and WebWorks (for BlackBerry) will give you the filesystem access you need, but I'm not sure if either of them have limitations that you'll hit size/quantity wise... hopefully someone with experience in these wrapper frameworks can indicate any size limits they've encountered.
With many browsers adding proper local storage support (and with this whole HTML5 buzz), there is a lot of talk about offline web apps competing with desktop software. But, as a matter of fact - one quick "clear private data" on your browser (which a lot of people do) - clears all the local storage data.
I'm now thinking that local storage in browsers can at best be used to cache data temporarily before being sync-ed with the web server, but truly offline web applications can't rely on HTML5's local storage permanently due to the problem I outlined above.
Is there a scope for offline web applications that actually depend on data extensively?
My take on this is that the offline capability of online web apps can compete with desktop software, but not pure offline web-apps.
Why? Well, the major drawback of online web apps was what happens when you lose your network connection when doing any work. Seeing as this can be resolved now, the competition is truly on. Imagine editing a document online, then move around without internet, come back online and then sync the changes and continue to work as if nothing happened. That is truly awesome.
For this to work, the browser should allow to store data in a location that you can pick which would mean access to OS layer, which will probably not happen anytime soon...