Офлайн-веб-програма iOS: завантажує мій маніфест, але не працює в режимі офлайн


74

Я пишу веб-програму, яка буде використовуватися офлайн на iOS. Я створив маніфест, подаю його як text/cache-manifest, і, як правило, він працює нормально, коли працює в Safari.

Якщо я додаю його як додаток на свій головний екран, то ввімкніть режим польоту, він взагалі не може відкрити програму - з’являється повідомлення про помилку, і він пропонує закрити програму. (Я думав, що в цьому полягає вся мета офлайн-програми!)

  • Коли я завантажую програму вперше в Інтернеті, я бачу в своїх журналах, що вона вимагає кожну сторінку, перераховану в маніфесті.

  • Якщо я вимкну режим літака та завантажу програму, я бачу, що перший файл, який він вимагає, - це мій файл main.html (який одночасно вказаний у маніфесті та має manifest=...атрибут). Потім він запитує маніфест та всі інші мої файли, отримуючи 200 для всіх (і 304 для всього, що запитується вдруге під час цього завантаження).

  • Коли я завантажую сторінку в Chrome і натискаю, журнали показують єдине, що вона намагається отримати на сервері, це "/favicon.ico" (це 404, і я не думаю, що iOS Safari намагається завантажити , у будь-якому випадку). Усі файли, перелічені в маніфесті, є дійсними та подаються без помилок.

  • Інспектор Chrome перелічує в розділі "КЕШ ЗАСТОСУВАННЯ" всі перераховані кешовані файли, які я очікую. Весь набір файлів становить близько 50 КБ, що перевищує будь-які обмеження щодо автономних ресурсів, які я знайшов.

Чи має це працювати, тобто, чи повинен я мати можливість створювати офлайн-додаток для iOS, використовуючи лише HTML / CSS / JS? І де я можу зрозуміти, чому це не працює в автономному режимі?

(Пов’язано, але для мене звучить не зовсім однаково, оскільки мова йде про Safari, а не про автономну програму: „ Не вдається змусити веб-програму працювати в автономному режимі на iPod “)

Відповіді:


22

Я підтверджую, що ім'я 'cache.manifest' вирішило проблему офлайн-кешування в IOS 4.3. Інша назва просто не працювала.


+1 це спрацювало для мене - хоча я бачив, що iPad отримував і використовував мій попередній маніфест, який називався offline.manifest
Пол Діксон,

7

Я знайшов налагодження офлайн-програм HTML5 для роботи. Я знайшов код з цієї статті, який допоміг мені зрозуміти, що сталося з моїм додатком:

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

Налагодження кешу офлайн-програм HTML 5 від Джонатана Старка

Якщо ви хочете надати офлайн-доступ до своєї веб-програми, кеш офлайн-додатків, доступний у HTML5, є вбивчим. Однак для налагодження це гігантський ПІТА, особливо якщо ви все ще намагаєтесь обговорити його.

Якщо ви боретеся з маніфестом кешу, додайте наступний JavaScript на свою основну сторінку HTML і перегляньте вихідні дані в консолі, використовуючи Firebug у Firefox або Debug> Показати консоль помилок у Safari.

Якщо у вас є питання, PLMK у коментарях.

HTH,
j

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);

1
Це акуратний трюк JS, але дотепер це не допомогло мені дізнатися нічого нового. Усі завантаження / перевірка / очікування в журналі виглядають точно так, як я очікував.
Ken

@Ken - шкода це чути. це, безумовно, допомогло мені звузити мої помилки (хоча все одно було боляче з’ясувати точну причину). Це також дало мені хороший відгук щодо того, чи кеш завантажився / перезавантажився успішно (перед тим, як це знати, я тестував би в автономному режимі після кожної зміни - знаючи це, я знав, що мені потрібно успішно отримати подію updateready, перш ніж це навіть варто було спробувати це в автономному режимі).
Bert F

Хм Чи потрібно мені хвилюватися з приводу того updatereadyчи іншого swapCache()? У мене склалося враження, що, оскільки я роблю програму, яка буде жити повністю в автономному режимі (після початкового завантаження взагалі не буде взаємодії з сервером), я можу просто помістити свої імена файлів у маніфест кешу, і все. Чи це складніше, ніж у моєму випадку?
Ken

5

Іноді група кешу програм потрапляє в поганий стан у MobileSafari - вона завантажує кожен елемент у кеш-пам’яті, а потім запускає загальну подію помилки кешу в кінці. Група кешу додатків, відповідно до специфікації, базується на абсолютній URL-адресі маніфесту. Я виявив, що коли ця помилка виникає, зміна шляху до маніфесту (наприклад, cache2.manifest тощо) дає вам нову групу кешу та обходить проблему. Я можу гарантувати, що всі наші веб-програми працюють у режимі офлайн у повноекранному режимі з версіями 4.2 та 4.3.


3

Жодна офлайн-програма (станом на iOS 4.2) не може працювати без підключення до Інтернету (що означає і режим польоту) під час використання <meta name="apple-mobile-web-app-capable" content="yes" />в розділі html head. Я перевірив це на кожному прикладі, який я бачив, і на тих, які використовують Safari, щоб зробити сайт нормально працюючим, але коли ви додасте цей мета-тег, він не буде працювати. Спробуйте свою програму без неї, і ви зрозумієте, що я маю на увазі.


1
@ pattern86 Цікаво, що у мене тут є сайт (все ще розробляю його, тому не можу поділитися, боюся), який, здається, працює нормально, використовуючи <meta name = "apple-mobile-web-app-enabled" content = "yes" / >. Я можу закрити браузер і офлайн-веб-програму, увімкнути режим польоту і все одно завантажувати офлайн-веб-програму без проблем. Чи потрібна якась інша поведінка для запуску цієї помилки? Я хочу переконатись, що ми не стикаємось із нею в дикій природі ...
Роуен

1
Цікаво, що PieGuy працює і на мене. Я на 4.2 (8C134), що є 4.2GM. Я спробую оновити 4.2.1 і подивлюсь, що станеться :(
Роуен,

@Rowan Я маю на увазі веб-програми поза мережею, які додаються на головний екран. Якщо ви додаєте їх у Safari та використовуєте їх там, це все одно має справно працювати. Ще не тестував це в iOS 4.3.
jsejcksn

@ pattern86 Так, я мав на увазі також веб-програми на головному екрані. У мене була можливість протестувати свій сайт за допомогою версій 4.2.1 та 4.3 - в обох випадках він працював нормально. Тож, схоже, тут є якийсь інший ефект (маніфест настільки чутливий до багатьох речей), але маніфест у цілому, здається, може функціонувати за призначенням.
Роуен

@Rowan Я радий, що ти змусив це запрацювати! Я спробую це колись на цих вихідних.
jsejcksn

3

Я виявив, що очищення кешу Safari після ввімкнення режиму літака є ефективним способом перевірки того, чи дійсно програма працює в автономному режимі.

Мене іноді обманювали, думаючи, що кеш додатків працював, коли ні.


2

Я боровся з цією проблемою iOS 4.3 "немає кешування в автономному режимі", оскільки оновив свій iPad до версії 4.3.1 з 4.2. В іншому дописі на цьому сайті я побачив, що він знову працює в 4.3.2. Тож я оновив iPad знову, тепер до iOS 4.3.3. Але все одно не вдалося змусити керувати офлайн-кешування, поки я не перейменував свій файл маніфесту на "cache.manifest". Потім кешування знову запрацювало, і я міг запустити офлайн-програму HTML5 з головного екрана. Мені не потрібно було розміщувати favicon.ico у маніфесті кешу. І у мене також відбувся повноекранний режим (встановивши для параметра "apple-mobile-web-app-enabled" значення "так").


1

У мене є кілька веб-програм, що працюють поза мережею та в режимі офлайн.

Коли я вимикаю режим аеропорту, я отримую запит на маніфест та деякі інші файли.

Я не отримую запитів на зображення, JavaScript, CSS або кешовані файли AJAX.

Якщо ви бачите запити на свої ресурси, IOS не кешує їх.

Загалом сафарі більш вимогливий до маніфестів.

Пропоную спробувати Safari на своєму комп’ютері.


Ні, як зазначалося вище (Safari - те саме, що Chrome, тут AFAICT), він ніколи не намагається запитувати будь-який ресурс (крім /favicon.ico) у браузері на робочому столі. Єдиний раз, коли це робиться, це з iOS Safari, коли він знаходиться в режимі польоту (або, коли інакше в автономному режимі, імовірно).
Кен

Я хотів би побачити сторінку. Я запускаю chrome / safari / firefox на своєму Mac вдома та iOS на iPhone та iPad.
JakeCigar

1

Я зіткнувся з такою ж проблемою сьогодні на iOS 4.3. Я зміг вирішити проблему, додавши файл favicon.ico, а також додавши його до маніфесту.



1

Після декількох днів возитися з тим, щоб веб-програми в автономному режимі працювали на iPhone / iPod Touch за допомогою автентифікації HTTP веб-сервера, я виявив ці корисні самородки:

  1. Переконайтесь, що Safari знаходиться в корені URL-адреси веб-програми, натискаючи "Додати на головний екран". Я використовував jQuery Mobile і іноді додавав посилання з "/ # pageId". Викликав неприємності.

  2. Запустіть свої дзвінки Ajax послідовно. Це може бути важливо лише у тому випадку, якщо ваш веб-додаток використовує аутентифікацію HTTP, але мій додаток паралельно запускав цілий ряд дзвінків Ajax при завантаженні сторінки, і це призвело до того, що програма зависла на "image-touch-startup-image".

  3. Виклики Ajax "успішні" в автономному режимі (принаймні за допомогою Prototype.js). Перевірте справжній фрагмент даних у відповіді Ajax, а не лише про статус HTTP. Я використовував це для тестування для відображення кешованих (SQL) або реальних даних.

  4. У маніфесті використовуйте "МЕРЕЖА: \ n * \ n". З того, що я міг назвати, це загальне твердження для всього, що не є явним у розділі "КЕШ:". Використовуйте Chrome, щоб переконатися, що ваш маніфест правильний. Подивіться на консоль Chrome на наявність помилок.

  5. Не пов’язаний безпосередньо, але трохи мене спокусив, дзвінки openDatabase.transaction () є АСИНХРОННИМИ! Значення, рядок JS коду після операції ( execute(), error(), success()) буде виконувати ДО success()функції.

Удачі!


1

Я знайшов це рішення, яке, здавалося, працювало для мене, оскільки я також стикався з цією проблемою під час свого розвитку. Наразі це виправлення добре працювало як для мене, так і для інших людей, з якими я просив протестувати, і я можу змусити його працювати в автономному режимі (в режимі польоту) та з головного екрану після кешування та іншого. Я написав про це на своєму сайті:

http://www.offlinewebapp.com/solved-apple-mobile-web-app-capable-manifest-error/

  1. Видаліть поточний значок веб-програми на головному екрані.
  2. Перейдіть у налаштування та очистіть кеш браузера Safari.
  3. Двічі торкніться домашньої кнопки, щоб відкрити панель багатозадачності. Знайдіть Safari, затримайте на ньому палець і вийдіть з нього.

Будь ласка, дайте мені знати, чи це також працює для вас! Удачі!


1

Я написав програму, і вона чудово працює через мобільний браузер, але при додаванні робочого столу ... Не працює. Я думаю, що Apple відмовився від IOS4, і всі зусилля зараз спрямовані на OS5. Сором :(


1

У мене є одне потенційне вирішення цього - це здається трохи божевільним, але ось що ... Я багато працюю з додатками cache.manifest та повноекранними програмами (ось вам тест, якщо вам потрібно: http://www.mrspeaker.net / 2010/07/12 / argy-bargy / - додати на головний екран, потім увімкнути режим польоту, і він запускається - принаймні, станом на iOS 4.2.1)

Одне дивне, що я виявив, - це те, що іноді здається, що якась "мета" інформація у файлах може зіпсувати їх від кешування - Ви коли-небудь помічали, що в bash, якщо ви робите "ls" деякі файли (залежно від вашого кольору налаштування) виділяються без видимих ​​причин? Файли можуть містити метадані, які операційна система (на мою думку) додає автоматично - і є способи їх видалити ... Я не пам’ятаю чому, але ось ще кілька деталей: Видаліть метадані з файлів у Snow Leopard

Одного дня вирвавши волосся - і відмовившись здаватися, бо я знав, що ПОВИНЕН спрацювати ... Chrome говорив, що завантажує всі файли, але закінчується загальною помилкою. Врешті-решт я відтворив структуру проекту з порожніми файлами та скопіював / вставив вміст. Це спрацювало - почав кешувати як слід!

Коли я подивився файли, то помітив, що там є мета-інформація. Я спробував очистити цю інформацію, і оригінальний проект знову запрацював. Я не впевнений, що це стало причиною того, що це знову спрацювало - можливо, це був просто випадковість.

Оскільки це спрацювало, я надто над цим не думав. Через кілька місяців та сама проблема повторилася, і фокус копіювання / вставлення знову запрацював. Я був зайнятий, тож не розслідував далі - але поклявся, що наступного разу, коли це станеться, досягну суті .... але мені поки що не доводилося.

Фу. У будь-якому разі, рада, що мені довелося це десь записати ...

[ОНОВЛЕННЯ: місяці та місяці пізніше - мені не вдалося відтворити це, тому я не думаю, що це метадані]

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.