Кэш приложений и сервисные работники

Ответ 1

Вы правы, appcache становится неподдерживаемым.

И есть другие опции, которые хранят данные и/или активы внутри IDB, такие как:

• Офлайновые веб-приложения с CouchDB, PouchDB и Emeber CLI
• Ember-Pouch
• Офлайновые приложения, использующие Ionic Framework, PouchDB и AngularJS

Попробуйте найти "автономный pouchdb ember" или "offline pouchdb angular" для получения дополнительных примеров.

Единственными механизмами обеспечения автономной доступности сейчас являются рабочие службы и appcache. Период.

Все эти методы зависят от того, что ваш сайт является одностраничным приложением и точкой входа для достижения цели. Поэтому, если вы не используете appcache или работников службы, чтобы обеспечить, чтобы точка входа всегда достижима, вы должны отступить к кешу http и правильно установить заголовки, связанные с кешем, при обслуживании ваших активов, В любом случае, HTTP-кеш может быть выгнан в любой момент UA.

Для решения этой проблемы, если для приложения должно быть автономно и в Safari, единственным вариантом является использование appcache (AFAIK, нет новостей об удалении апкэша из Safari).

Чтобы снизить риск, вы можете выбрать сочетание одного из предыдущих методов (тех, которые хранят активы на IndexedDB) в дополнение к appcache, поэтому единственное, что вы используете, - это точка входа в SPA. Если appcache становится неподдерживаемым, и нет альтернативы сервисному работнику, вы можете переключиться на альтернативу кэширования.

В любом случае вы можете использовать обнаружение функций (if ('serviceWorker' in navigator) { ... }), чтобы узнать, доступны ли рабочие службы и использовать их в случае, если это так. Для appcache существует polyfill, основанный на обслуживании, называемый JakeCache (не тестировался), и другие должны прийти.

Ответ 2

Вы можете использовать сервис-работников и AppCache в одном и том же веб-приложении. Что происходит в таком случае, так это то, что браузеры, не поддерживающие Service Workers, будут использовать AppCache, а те, кто это делает, будут игнорировать AppCache и позволить Service Worker взять верх.

Источники: https://www.w3.org/TR/service-workers/#activation-algorithm, https://crbug.com/410665

Ответ 3

Существует определенно возможность использовать оба одновременно. Если вы хотите развернуть кросс-браузерное приложение в ближайшие пару лет, то я считаю, что вам нужно продолжать использовать AppCache, поскольку iOS только "думает о" внедрении Service Workers в следующие 5 лет.

Вот некоторый JavaScript, который мы используем, чтобы определить, следует ли использовать тот или иной и инициализировать оба

if ( 'serviceWorker' in navigator && b ) {
navigator.serviceWorker.register('/sw.js').then(function(registration) {
// Registration was successful
showMsg('ServiceWorker registration successful with scope: ', registration.scope);
if ( registration.installing ) {
  showMsg( 'Service worker installing' );
} else if ( registration.waiting ) {
  showMsg( 'Service worker installed' );
} else if ( registration.active ) {
  showMsg( 'Service worker active' );
}
  }).catch(function(err) {
    // registration failed :(
    showMsg('ServiceWorker registration failed: ', err);
  });

// Listen for claiming our ServiceWorker
navigator.serviceWorker.addEventListener('controllerchange', 
function(event) {
      // Listen for changes in the state of our ServiceWorker
      navigator.serviceWorker.controller.addEventListener('statechange', function() {
        // If the ServiceWorker becomes "activated", let the user know they can go offline!
        if (this.state === 'activated') {
        // This example is refreshing the app directly, but you can inform the user with a fancy modal window or similar
            window.location.reload( true );
        }
      });
    });

// Browsers not using Service Workers
    } else  if ('applicationCache' in window) {
      var iframe = document.createElement('iframe');
      iframe.style.display = 'none';
      iframe.src = 'load-appcache.html'
      document.body.appendChild(iframe);
      showMsg("Iframe loaded for AppCache management");

    } else {
      showMsg("no service worker - no appCache");

 }

Код, описанный для инициализации AppCache, помогает обновлять новые страницы при изменении файла appcache. Я схватил его из нескольких источников, но все они пришли из мощной презентации, которую Патрик Кеттнер поставил во время PWA Dev Summit 2016: (https://www.youtube.com/watch?v=IgckqIjvR9U&t=1005s)

load-appcache.html содержит только

<!DOCTYPE html>
<html manifest="offline.appcache">
    <head>
        <title>loding appCache</title>
   </head>
   <body></body>
</html>

Конечно, есть несколько возможностей, которые SW предоставляет для придания более привлекательного приложения, но с AppCache и IDB вы действительно можете сделать практически любую бизнес-логику, в том числе автономные.

Помните, что вы не сможете тестировать функциональность AppCache с Chrome, поскольку они отключили его, но вы все равно можете заставить Firefox (я тестировал с 50.1.0). Вы всегда можете использовать Safari, хотя:)

Ответ 4

В соответствии с Mozilla HTML5 Service Workers Doc:

Примечание.. Одна из замечательных особенностей сервисных работников заключается в том, что если вы используете функцию такие как weve, показанные выше, браузеры, которые не поддерживают службу работники могут просто использовать ваше приложение онлайн в ожидании нормальной работы. Кроме того, если вы используете AppCache и SW на странице, браузеры, которые не поддержка SW, но поддержка AppCache будет использовать это и браузеры, которые поддержка обоих будет игнорировать AppCache и позволить SW захватить.

Код "выше":

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw-test/sw.js', {scope: '/sw-test/'})
  .then(function(reg) {
    // registration worked
    console.log('Registration succeeded. Scope is ' + reg.scope);
  }).catch(function(error) {
    // registration failed
    console.log('Registration failed with ' + error);
  });
}

https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers