I have built a html5 gallery which does work offine but what I need help with is getting the app to detect if the user is online and if so will update the mainifest when the user opens up the app.
Firstly, you need to make sure that the manifest file isn't listed in the manifest file as this will prevent it from being re-fetched even if the user is online.
Once you have done this, if you set cache-mode to prefer-online it will re-fetch the pages when a connection is available. If you only want to update the manifiest, you don't need to do this step, most user agents will re-fetch the manifest when a connection is available as long as it is not included in its own listing.
You can also force it using the JavaScript API:
window.applicationCache.update()
You can see this example and lots more details of the JavaScript API here.
Related
So, I am working on a project(building a chrome extension) that requires data to be stored on the local machine of the user. The size of data is quite large hence I thought of using IndexDB for this purpose.
My Question is whether is it possible to connect a chrome extension with IndexDB and query the database at the same time??
If Yes, Then how can I integrate them. In which file(popup.js or background.js or any other file) should I include the source code for creating the database.
I want the code for creating the database to run only once. After that I only want to update or delete data only.
If No, then is there any other way to achieve this?? The data is large hence I cannot store data in local storage.
Any paper, online material, advice or method from chrome developers or any other valid site would be helpful. Any example would help me alot.
Thankyou.
You can store tons of data in any HTML5 storage (including IndexedDB or localStorage) and chrome.storage.local with "unlimitedStorage" permission.
HTML5 data is stored per URL origin and each extension has its own one that looks like chrome-extension://id where id is a 32-character string that is the extension's id. In Firefox the origin looks like moz-extension://id.
Extension's own HTML5 storage:
can be accessed in any extension page (popup, options, background) just like you would do it in a web page, there are no differences.
cannot be accessed in a content script as it runs in a web page and thus can only access HTML5 storage of the web page's URL origin.
chrome.storage.local can be accessed in any extension page and in a content script.
No need for special event to create/upgrade your IndexedDB storage - it'll happen automatically if needed - simply open it as shown in the documentation whenever you need to access it and your onupgradeneeded callback will be invoked in case there was no DB or it was outdated.
Use a wrapper library for IndexedDB that provides a simplified syntax. Some are listed in the documentation, but you can probably find better ones yourself.
I'm making a webapp for members of my caving club to search through and view cave survey note PDFs. It works fine, and I got the AppCache working for the web version of it.
However, since the PDFs are quite large and slow to download, and many members have the PDFs on their local machines from the same SVN the website gets them from, it would be ideal for them to be able to use a page with links to a local SVN folder of their choosing.
The design goals:
The site displays links to PDF files on the local filesystem
Whenever I add features to the site, users get them automatically the next time they open the page and they're connected to the internet
But after the first time they open the page, the site works offline.
Sadly web browsers don't appear to support this useful combination of design goals at once.
I can satisfy #1 by having users download a copy of the site, add their local SVN path in a JS, and open their local copy in the browser, so that file:/// links work.
I can satisfy #2 by having absolute links to JS bundles on the server.
I can satisfy #3 by using the AppCache.
I thought I could get clever by having the copy of the page on the local file system have <html manifest="https://myserver.com/myapp.appcache">, but unfortunately Chrome doesn't seem to allow a local file to use an app cache manifest hosted on a server, for seemingly no good reason to me.
Does anyone know of another way I could satisfy all 3 goals?
Perhaps there's some simple program/config I could give my friends that would intercept web requests to https://myserver.com/some/folder and instead serve them out of a folder on their local file system?
Andy,
I know this post is a bit old but came across it looking for something else related to AppCache. My understanding it that the html page and the manifest must reside in the same domain for it to work. So I think you need to modify your design:
Create a JavaScript function that acts as a setting for the user to enter the path to their local copy of the PDF's. Store this information in localstorage.
Create a html template page for the document links.
Create a JavaScript function that populates the html template page with any documents and links the user enters.
This way, the users visit your application online and it uses appcache to store itself and the JS files for offline use. To access the PDF's, the user clicks a settings button that launches a page to collect path information and saves the information in localstorage. The users can then access the template page which will populate with the documents they entered.
Here is a good intro to localstorage: [http://www.smashingmagazine.com/2010/10/local-storage-and-how-to-use-it/]
I've developed an iPad web app that uses the appcache. It's not intended to be a fully offline app but I use the appcache to store large image files so that they're not sent over 3G. Problem is when the manifest is updated the appcache updates whether the iPad is on wifi or 3G, which could be expensive.
Is it possible to have the user decide if the appcache can be updated or not? From what I've seen, this isn't possible, it all happens automatically, you just get events. But perhaps there's some trickery like writing the manifest on the fly or similar.
Using PHP on the server side if that helps. Thanks.
Connection Type: Theory & Future
There is a draft spec of Network Information API on W3C that provides the information of the connection type (ethernet wifi 2g 3g 4g etc.), but it hasn't been implemented on any browser yet apart from:
the stock Android browser on Android 2.2+ (not the Google Chrome browser)
navigator.connection.type // Based on W3C draft, (Implemented on stock Android browser)
and PhoneGap which is not exactly a browser
navigator.network.connection.type // on PhoneGap
Having that information in the future you could detect if the user has cellular data, then temporarily remove the src of the images and ask the user through a confirmation dialog.
You will also probably have to cancel the app cache update using:
window.applicationCache.abort() (documentation)
Reality
Unfortunately, the Net Info API is not available (at least not widespread) at the moment, but certainly will help in the future.
Long shot
There is a database that includes network speed (DIAL = dial up, DSL = broadband/cable, COMP = company/T1), but I haven't used it and I doubt it will help.
Dynamic App Cache
While checking into this, I tried to generate the html tag along with the manifest declaration on the fly, in order to combine it with the Network Info API but the AppCache manifest is loaded before javascript execution and is not affected afterwards.
So altering the manifest file on the fly through Javascript is not possible and data URI is not an option.
Alternative solution
HTML5 application cache is an untamed beast at the moment and there are talks to improve it. Until it changes to support more complex configurations (bandwidth level flag would be awesome), you could change perspective on the solution, although App Cache may be the best you have at the moment.
Depending on how big your images are you could rely on the normal browser cache. You could combine localStorage and far-future expiration HTTP headers. LocalStorage in order to keep track of the loaded/cached images.
First add a far in the future date for expiration on your images HTTP headers
On page load, remove all src from imgs
Loop the images and check localStorage if each image was loaded in the past
If there are images that were not loaded in the past, display a dialog confirming for the downloading of those images
If the image was loaded in the past, then put back the src on the img
For every image that is downloaded, save its URL on localStorage
I don't know what the status of indexedDB is on the iPad, but this could be an alternative solution.
In short: Indexeddb is a clientside database. Data is stored in object stores which are key/value pairs. The maximum storage capacity is in theory the maximum of your disk space. For more information about indexeddb:
Specification
My blog
What you could do with the indexeddb:
When someone navigates to a page:
Check every image tag if it is present in the indexeddb
if present
Get the image from the indexeddb and put it in the image tag
if not present
Download it
store it in the indexeddb
put the image in the image tag.
As extra (in the future) you can do as discribed by Sev: check the connetion type and only download the image when working on a fast internet connection.
I have 'invented' a working solution developing a webapp on the iPad (iOS 6.0.x) that may answer your question.
The idea is first to check if a localstorage variable is set/defined or not yet (I use the title of the page, thus the webapp name.)
If this localstorage variable exists, then assume (in webapp sandbox context) that its the first time the app is being run. At this point I populate a UUID in conjunction with $PHP_SESSION($uuid) to avoid 'cross app contamination' in server-side PHP land.
In addition to this I have a dynamic manifest.appcache.php which includes in the CACHE section a list of files to add to the manifest. Thus;
<?
echo $manifest_file_list[0]."\n";
?>
Using the JS appcache manifest event listeners I then monitor the progress to something like $('#manifestappcache').html(result);
From my experiences so far, I've concluded that the HTML5 Manifest scheme was really terribly designed.
My site serves a manifest file when a user is logged in. Unfortunately, when they log out, they can still access the cached protected materials. Can anyone think of a way to fix this?
A manifest file is designed to take a website offline and still be able to navigate. It essentially just tells the browser to download and keep that stuff in cache. If your adding secret stuff to the manifest and the user goes offline, he needs to be able to still access it - or whats the point of having a special logged-in-manifest-file if he has to be loggedin (therefor online)?
You could add javascript that checks if the user is online again and if he is, tries to validate the "login state" and redirects or removes the secret stuff from localstorage (if you would use localstorage to save the "secret" stuff and javascript to display it instead of a manifest file )
Lets say the secret stuff is an image and you are not using a manifest file, but just displaying images when the user is logged in and its crusial, the user cant view that image after logout, you would need to set the http headers to no-cache and cache-expire to some random date of the past, so that a normal user would see it anymore. Problem then is, that the image is downloaded everytime somebody visits the website..
You need to approach the HTML5 Application Cache in a different way. It is not useful for caching server-side dynamically generated pages, especially those that require a login to reach. The Application Cache has no concept of logins, nor securing a page from somebody with a different/no login.
It is much more appropriate for an AJAX-based site, where all HTML/CSS/JavaScript is static and registered in the Application Cache, and data is instead fetched via AJAX then used to populate pages. If you need to cache data in the application for offline use, then use one of the offline data storage mechanisms such as Local Storage/Session Storage, or IndexedDB, for data.
You can then make your own judgement on how much data you want to cache offline, since there's no way to validate a login without making a call to the server that is naturally inaccessable whilst offline.
What if when the user logs out or is not logged in they get a manifest with only network:*
I'd like to try my hand at some Chrome Extension Development. The most I have done with extensions is writing some small Greasemonkey scripts in the past.
I would like to use localStorage to store some data and then reveal the data on a extension button click later on. (Its seems like this would be done with a popup page)
How do I run a script everytime a page from lets say http://www.facebook.com/* is loaded?
How do I get access to the page? I think based off my localStorage requirement I would have to go down the background_page route (correct?) Can the background page and popup page communicate across the localStorage?
UPDATE:
I'm actually looking to learn the "Chrome way". I'm not really looking to run an existing Greasemonkey script
Google actually has some pretty good documentation on creating extensions. I recommend thoroughly reading the following two articles if you haven't already done so:
http://code.google.com/chrome/extensions/getstarted.html
http://code.google.com/chrome/extensions/overview.html
If you want to give your extension access when the user browses to Facebook, you'll need to declare that in the extension's manifest.
Unless you're wanting to save data beyond the life of the browser process, you probably don't need to use local storage. In-memory data can just be stored as part of the background page.
Content scripts (which run when you load a page) and background pages (which exist for the duration of the browser process) can communicate via message passing, which is described here:
http://code.google.com/chrome/extensions/messaging.html
Overall, I'd suggest spending some time browsing the Developer's Guide and becoming familiar with the concepts and examples.
Chrome has a feature to automatically convert greasemonkey scripts to extensions!