Cache di applicazioni o lavoratori del servizio - quali utilizzare nel 2016/Q2?

Question

Domanda veloce per la discussione, perché volevo ricevere suggerimenti da persone diverse.

Sono in procinto di sviluppare un'applicazione per le pagine Web che deve essere disponibile offline.

Ora, per fare questo, a quanto ho capito, si andrebbe ad utilizzare sia la funzionalità di caching dell'applicazione che gli addetti all'assistenza.

Tuttavia, ecco l'enigma che ho. Quando la ricerca della cache dell'applicazione, the MDN clearly states:

Deprecated:
Questa caratteristica è stata rimossa dagli standard Web. Sebbene alcuni browser possano ancora supportarlo, è in fase di rilascio. Non usarlo in progetti vecchi o nuovi. Le pagine o le app Web che lo utilizzano potrebbero interrompersi in qualsiasi momento.

Dopo di che un'altra finestra di dialogo suggerisce invece di utilizzare i lavoratori dell'assistenza.

The Service Workers page quindi prosegue affermando che i Service worker sono una tecnologia sperimentale ed è consigliabile consultare la tabella di compatibilità.

La tabella di compatibilità indica che Safari e Internet Explorer non supportano i servizi di manutenzione. Ulteriormente consultando this site e assumendo che sia accurato, afferma che il lavoro è iniziato da Microsoft per integrare i lavoratori del servizio, tuttavia per Safari sono "In considerazione" con "Brevi segnali positivi nel piano quinquennale".

Ora questa è una preoccupazione per il progetto corrente in quanto è essenziale che sia compatibile con i safari, tuttavia, anche io non voglio che si rompa in altri browser.

Quali sarebbero i tuoi consigli? Basta andare con la vecchia Application Caching e aggiornarla nel prossimo futuro? Determina il browser degli utenti e agisci in modo appropriato? Oppure, c'è un altro modo che mi manca?

Answer 1

Hai ragione, appcache is becoming unsupported.

E ci sono altre opzioni che memorizzano i dati e/o le attività all'interno di IDB quali:

• Offline Web Applications with CouchDB, PouchDB and Emeber CLI
• Ember-Pouch
• Offline apps using Ionic Framework, PouchDB and AngularJS

Prova googling "offline pouchdb ember" o "offline pouchdb angular "per ulteriori esempi.

Gli unici meccanismi per garantire la disponibilità offline al momento sono gli addetti all'assistenza e l'appcache. Periodo.

Tutte queste tecniche si basano sul fatto che il sito sia un'applicazione singola e il punto di ingresso sia raggiungibile. Pertanto, se non si utilizzano appcache o addetti all'assistenza per garantire che il punto di ingresso sia sempre raggiungibile, è necessario eseguire il fallback nella cache http e impostare correttamente cache-related headers quando si servono le risorse. In ogni caso, la cache http può essere sfrattata in qualsiasi momento dall'UA.

Di fronte a questa decisione, se è obbligatorio che l'applicazione venga eseguita offline e in Safari, l'unica opzione è utilizzare appcache (AFAIK, non ci sono notizie sulla rimozione di appcache da Safari).

Per ridurre il rischio si può optare per la combinazione di una delle tecniche precedenti (quelle che memorizzano le risorse su IndexedDB) oltre ad appcache quindi l'unica cosa che si memorizza nella cache è il punto di ingresso per la SPA. Se appcache non è supportata e non è disponibile alcuna alternativa al servizio di assistenza, è possibile passare alle intestazioni della cache alternative.

In ogni caso, è possibile utilizzare il rilevamento delle funzioni (if ('serviceWorker' in navigator) { ... }) per verificare se i lavoratori del servizio sono disponibili e utilizzarlo nel caso in cui lo sia. C'è un polyfill per appcache basato su operatori di servizio chiamati JakeCache (non testato) e others are to come.

Answer 2

È possibile scegliere di utilizzare i Service Worker e AppCache sulla stessa web app. Quello che succede in questo caso è che i browser che non supportano i Service Worker useranno AppCache e quelli che lo faranno ignoreranno AppCache e lasceranno il Service Worker prendere il sopravvento.

Fonti: https://www.w3.org/TR/service-workers/#activation-algorithm, https://crbug.com/410665

Answer 3

v'è sicuramente la possibilità di utilizzare entrambi allo stesso tempo. Se si desidera distribuire un'applicazione cross-browser nei prossimi due anni, la mia impressione è che si debba continuare a utilizzare AppCache, poiché iOS sta solo "pensando" all'implementazione dei Service Worker nei prossimi 5 anni.

Ecco alcuni JavaScript che stiamo usando per rilevare se utilizzare uno o l'altro e per inizializzare sia

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

} 

Il codice descritto per inizializzare AppCache aiuta rinfrescare le nuove pagine quando il file AppCache modifiche. Ho afferrato da varie fonti, ma tutti provenienti dalla presentazione potente che Patrick Kettner consegnato nel corso del vertice PWA Dev 2016: (https://www.youtube.com/watch?v=IgckqIjvR9U&t=1005s)

carico appcache.html contiene nulla, ma

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

Ci sono ovviamente molteplici possibilità che SW fornisce per offrire un'app più elaborata, ma con AppCache e IDB puoi davvero fare praticamente tutte le logiche di business che vuoi, comprese le funzionalità offline.

Attenzione che non sarà possibile testare la funzionalità di AppCache con Chrome poiché sono stati disabilitati, ma è comunque possibile forzare Firefox (l'ho testato con 50.1.0). È sempre possibile utilizzare Safari però :)

Answer 4

Secondo HTML5 Operai Doc di Mozilla:

Nota: Una cosa grandiosa di lavoratori dei servizi è che se si utilizza la funzionalità di rilevamento come abbiamo mostrato sopra , i browser che non supportano il servizio lavoratori possono semplicemente utilizzare la tua app online nel modo normale previsto. Inoltre, se si utilizza AppCache e SW su una pagina, i browser che non supportano il supporto ma supportano AppCache lo utilizzeranno, mentre i browser che supportano l' ignoreranno AppCache e consentiranno a SW di assumere il controllo.

Codice "sopra":

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