简体   繁体   中英

HTML5 web app not caching when added to home screen in iOS

To be clear, the web app IS caching and is working fine offline in Mobile Safari.

The problem is when it is added to the home screen on an iPhone 4s and iPad 2, both running iOS 6.0.1. It won't work offline and gives a network error to connect to the internet ie "Cannot open MYWEBAPP. MYWEBAPP could not be opened because it is not connected to the internet"

I've been debugging this for several hours and can't seem to find a solution. I'm not receiving any errors in the console and I'm running Jonathan Stark's debugging code

I've tested the app in desktop Safari, Chrome and Firefox's developer tools both Online/Offline. As well as Web Inspector with the devices in Safari. The result is the same on either iPhone or iPad. They will both cache the web app and will work in Mobile Safari, but not when added to the home screen. No errors either offline or online.

As far as I know, I'm using best practices:

  1. Added HTML header: <html manifest="photo.appcache">

    I've also experimented with using different names for the manifest file including: cache.manifest and offline.manifest as I read that it makes a difference, but in my testing it does not matter what the name is as long as the extensions are .manifest or .appcache and is served appropriately in the .htaccess file.

  2. Added correct MIME types: AddType text/cache-manifest appcache manifest

    I've also tried: AddType text/cache.manifest manifest , AddType text/cache.manifest .manifest manifest , AddType text/cache-manifest .manifest

    I don't believe this worked: AddType text/cache.manifest but I don't remember. For the most part it didn't matter and I stuck with:

    AddType text/cache-manifest appcache manifest

    as that what was in the HTML5 Mobile Boilerplate.

  3. Added:

NETWORK: *

to the appcache file. I believe this allows everything to be downloaded as well as making all links work.

  1. I've tried removing this line: <meta name="apple-mobile-web-app-capable" content="yes"> because I read here on SO that is solved a problem similar to mine, but I can confirm that it does not work in my testing. Removing this line or setting the content to "no" when pressing on the home screen icon will redirect to Mobile Safari and not open fullscreen.

I've pretty much narrowed it down to it being a bug in iOS 6 (I'm actually using iOS 6.0.1), because I know that data has now been separated for web apps in the browser and those added to the home screen. I'm posting this issue here to see if any other developers have encountered the same issue.

I've solved this issue. I recommend the following for home screen web apps in iOS 6.

For testing purposes, use the Web Inspector and a nice JS script like Jonathan Stark's to know when the app has been cached in Mobile Safari:

http://jonathanstark.com/blog/debugging-html-5-offline-application-cache?filename=2009/09/27/debugging-html-5-offline-application-cache/

After it has been successfully cached, add the app to your home screen and leave it open in order for it to cache the home screen version separately. It has to fully cache in order for it to work offline.

Since my app cache is 22mb of data and the caching of the data is SEPARATE for the web app, the problem I had was not leaving the home screen app open long enough to cache.

This is terrible as far as user experience goes, but also good that the data is separate. I can confirm this because if you delete the website data from Safari, the home screen web app will still function.

As far as I know, there isn't a way to debug the data cached for the home screen web app, or where it is stored.

The answer above was very helpful. @aul said he didn't know of a way to debug the home screen web app but I found a way.

Hook your iPad or iPhone up to your computer, then in Safari go to Develop > and select your device. Your homescreen app must be open in order for it to appear in the drop down menu. Once you access the app, you can open up the error console and watch Jonathan Stark's script go to work. Once the manifest is downloaded, you will be able to use the app in offline mode.

This script made the life easier! Thanks to @Paul!

var cacheStatusValues = [];
cacheStatusValues[0] = 'uncached';
cacheStatusValues[1] = 'idle';
cacheStatusValues[2] = 'checking';
cacheStatusValues[3] = 'downloading';
cacheStatusValues[4] = 'updateready';
cacheStatusValues[5] = 'obsolete';

var cache = window.applicationCache;
cache.addEventListener('cached', logEvent, false);
cache.addEventListener('checking', logEvent, false);
cache.addEventListener('downloading', logEvent, false);
cache.addEventListener('error', logEvent, false);
cache.addEventListener('noupdate', logEvent, false);
cache.addEventListener('obsolete', logEvent, false);
cache.addEventListener('progress', logEvent, false);
cache.addEventListener('updateready', logEvent, false);

function logEvent(e) {
    var online, status, type, message;
    online = (navigator.onLine) ? 'yes' : 'no';
    status = cacheStatusValues[cache.status];
    type = e.type;
    message = 'online: ' + online;
    message+= ', event: ' + type;
    message+= ', status: ' + status;
    if (type == 'error' && navigator.onLine) {
        message+= ' (prolly a syntax error in manifest)';
    }
    console.log(message);
}

window.applicationCache.addEventListener(
    'updateready', 
    function(){
        window.applicationCache.swapCache();
        console.log('swap cache has been called');
    }, 
    false
);

setInterval(function(){cache.update()}, 10000);

I had a two part problem. I was generating my cache manifest with ASP.NET MVC/Razor because I wanted to be able to easily host the site off a virtual application and still have the paths line up. The content type wasn't getting set properly on the cache manifest, so Internet Explorer and Safari (iOS) weren't recognizing it (even though Chrome on PC and Android would).

Once I solved that problem, it still wasn't working when I tried to access my Azure hosted app with iOS Safari. When I tried to access with Internet Explorer, I saw that it didn't have the correct mime type for a font I was having.

So a word of warning: be absolutely sure of the mime type of not only the manifest, but also all files that the manifest depends on.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM