Постоянно перенаправляйте веб-приложения на домашний экран iOS

Question

У меня есть одностраничное веб-приложение, использующее Sencha Touch, которое было добавлено на домашний экран примерно на 2000 iPad. Я хочу изменить URL-адрес веб-приложения, не требуя от всех этих пользователей удаления значка запуска с главного экрана, перехода на новый URL-адрес и добавления его на главный экран снова. Приложение также использует манифест кэша для кэширования HTML, CSS, JavaScript и изображений, и приложение способно работать полностью в автономном режиме.

Веб-страницы, добавленные на домашний экран в iOS, похоже, реагируют на HTTP 301 (постоянное перенаправление), как и ожидалось, но я обнаружил, что поведение iOS 8 на устройствах iPad 2 выглядит странным, как я опишу. Я создал веб-сайт ASP.NET MVC, который развертываю по тому же URL-адресу, заменив приложение Sencha Touch, чтобы выполнить постоянное перенаправление. Вот процесс, который я использую, и поведение, которое я вижу:

1. Когда приложение запускается со старого URL, оно запрашивает только cache.manifest, и я возвращаю HTTP 404, чтобы приложение прекратило кэширование.

2. Приложение загружается, и у меня есть обработчик события в JavaScript приложения для события "applicationCache " устаревшего ", которое вызовет window.location.reload(true). Затем приложение перезагрузится и на этот раз запросит ранее кэшированную HTML-страницу (которая размещена в корне URL-адреса), а мой сайт ASP.NET MVC затем вернет HTTP 301 для перенаправления на новый URL-адрес.

3. Как только приложение достигает нового URL, оно начинает загружать ресурсы из cache.manifest по новому URL. У меня есть обработчик события "updateready" applicationCache, который вызовет window.location.reload (true) и перезагрузит приложение. Как только приложение перезагрузится, оно будет запрашивать все ресурсы (запросы XHR к службам) с нового URL-адреса, как и ожидалось.

4. Когда я тестирую это на iPad 1 под управлением iOS 5, это работает именно так, как я и ожидал. После загрузки и кэширования ресурсов с нового URL-адреса он всегда выполняет каждый запрос с нового URL-адреса с этой точки. Я могу перевести устройство в режим полета, и приложение будет отлично работать в автономном режиме.

5. Именно здесь начинается странное поведение, и я вижу это только на своих iPad, работающих под управлением iOS 8.x (у меня нет устройств под управлением iOS 6 или 7). Затем я закрываю приложение, нажав кнопку "Домой", и снова запускаю его с иконки на главном экране. Когда я перезапускаю приложение, оно всегда сначала возвращается к старому URL-адресу (iOS 5 всегда переходит к новому URL-адресу), что странно, потому что предыдущий HTTP 301 должен был предотвратить это. Отсюда возможны два варианта поведения:

5а. Иногда он запрашивает только HTML-страницу со старого URL (корневого URL), и в этом случае он получает другой HTTP 301, а затем перенаправляет на новый URL, запрашивает манифест кэша и загружает приложение. Оттуда и далее он никогда не будет снова отправлять запросы на старый URL, когда я открою и закрою приложение. Когда я переключаю устройство в режим полета, приложение отлично работает в автономном режиме. У меня есть два iPad 2 под iOS 8.3 и 8.4, и это будет происходить примерно в 50% случаев на этих устройствах.

5б. В других случаях это не так хорошо работает. При перезапуске приложения после загрузки кэшированных ресурсов с нового URL-адреса оно возвращается к старому URL-адресу и не запрашивает страницу HTML, а вместо этого запрашивает cache.manifest вместе с CSS и JavaScript. Запрос cache.manifest приведет к другому HTTP 404, но если я продолжу закрывать и повторно открывать приложение, он никогда не сочтет кеш устаревшим и больше не будет запрашивать страницу HTML. Интересно, что я могу воспроизвести это только на iPad 2s. У меня iPad Air 1 под управлением iOS 8.3, и я когда-либо видел только 5 a на этом устройстве.

6. Для случая, описанного в 5b, он запрашивает файлы JavaScript. Итак, я пошел в один из файлов JavaScript и поместил в window.location.reload(true), что заставляет его запрашивать страницу HTML, что приводит к другому HTTP 301. Теперь, когда происходит такой сценарий, он отправляет его новому URL, но каждый раз, когда я закрываю и заново открываю приложение, оно повторяет весь цикл. Он переходит на старый URL, получает JavaScript, перезагружается, получает 301, а затем переходит на новый URL. Когда я переключаю устройство в режим полета и открываю приложение, оно не работает.

Я обнаружил, что если я перевожу iPad 2s в режим полета и запускаю приложение по старому URL, затем запускаю его снова и выполняю 404 для cache.manifest и 301 для HTML, то 5 a всегда будет происходить. Это похоже на ошибку в iOS 8 (которая, возможно, также существует в 6 и 7), и я пытаюсь найти обходной путь, который я могу реализовать на своем веб-сайте ASP.NET MVC, чтобы перенаправить на новый URL, который будет работать 100% времени.

Любая идея будет принята с благодарностью.

Answer 1

Я понял, как избежать странного поведения. Как я упоминал выше, приложение прослушивает "устаревшее" событие в applicationCache и затем вызывает window.location.reload(true), чтобы снова захватить страницу и получить 301. Я обнаружил, что если вместо перезагрузки той же страницы, Я перенаправляю на другую страницу и обратно, она работает идеально в 100% случаев. Он перенаправляет на новый URL, кэширует ресурсы, затем никогда не запрашивает старый URL. Я также обнаружил, что закрытие приложения и его повторное открытие после того, как кэш устарел, имеет тот же эффект.