html5 - temporales - ¿qué es datos caché en un celular?
Caché de aplicaciones o trabajadores de servicios: ¿cuál utilizar en 2016/Q2? (4)
Pregunta rápida para discusión realmente, ya que quería recibir aportes de diferentes personas.
Estoy en el proceso de desarrollar una aplicación de página web que debe estar disponible sin conexión.
Ahora, para hacer esto, según lo entiendo, debería utilizar la función de almacenamiento en caché de la aplicación o utilizar trabajadores de servicio.
Sin embargo, aquí está el enigma que tengo. Al investigar el caché de la aplicación, el MDN establece claramente :
Obsoleto:
Esta característica ha sido eliminada de los estándares web. Aunque algunos navegadores aún lo admiten, está en proceso de ser descartado. No lo uses en proyectos antiguos o nuevos. Las páginas o aplicaciones web que lo utilizan pueden romperse en cualquier momento.
Luego, otro cuadro de diálogo sugiere utilizar trabajadores de servicio en su lugar.
La página Trabajadores del servicio continúa para indicar cómo los Trabajadores del servicio son una tecnología experimental, y es mejor consultar la tabla de compatibilidad.
La tabla de compatibilidad indica que Safari e Internet Explorer no son compatibles con los trabajadores de servicio. Además de consultar este sitio y suponiendo que es correcto, indica que Microsoft ha comenzado a trabajar para integrar a los trabajadores de servicio, sin embargo, para Safari están "en consideración" con "Señales positivas breves en el plan de cinco años".
Ahora, esto es una preocupación para el proyecto actual, ya que es esencial que sea compatible con safari, sin embargo, tampoco quiero que se rompa en otros navegadores.
¿Cuáles serían tus recomendaciones? Simplemente vaya con el caché de aplicaciones anterior y actualice en un futuro cercano. ¿Determinar el navegador de los usuarios y actuar adecuadamente? O, ¿hay alguna otra forma de que me esté perdiendo?
De acuerdo con el Documento de Trabajadores de Servicios HTML5 de Mozilla:
Nota: Una gran cosa acerca de los trabajadores de servicios es que si usa la detección de funciones como hemos mostrado anteriormente, los navegadores que no son compatibles con los trabajadores de servicios pueden usar su aplicación en línea de la manera normal que se espera. Además, si usa AppCache y SW en una página, los navegadores que no son compatibles con SW, pero sí lo son, AppCache lo utilizará, y los que admitan ambos ignorarán AppCache y dejarán que SW tome el control.
Código "arriba":
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
Definitivamente, existe la opción de utilizar ambos al mismo tiempo. Si desea implementar una aplicación de navegador cruzado en los próximos dos años, mi impresión es que tiene que seguir usando AppCache, ya que iOS solo está "pensando en" implementar trabajadores de servicio en los próximos 5 años.
Aquí hay algunos JavaScript que estamos usando para detectar si usar uno u otro e inicializar ambos
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");
}
El código descrito para inicializar AppCache ayuda a actualizar las nuevas páginas cuando cambia el archivo de appcache. Lo obtuve de varias fuentes, pero todas provinieron de la poderosa presentación que Patrick Kettner realizó durante la PWA Dev Summit 2016: ( https://www.youtube.com/watch?v=IgckqIjvR9U&t=1005s )
load-appcache.html no contiene nada más que
<!DOCTYPE html>
<html manifest="offline.appcache">
<head>
<title>loding appCache</title>
</head>
<body></body>
</html>
Por supuesto, SW ofrece múltiples posibilidades para ofrecer una aplicación más sofisticada, pero con AppCache e IDB puede hacer prácticamente cualquier lógica empresarial que desee, incluidas las capacidades fuera de línea.
Tenga en cuenta que no podrá probar la funcionalidad de AppCache con Chrome ya que la han desactivado, pero aún puede forzar Firefox (lo he probado con 50.1.0). Aunque siempre puedes usar Safari :)
Podría elegir usar Service Workers y AppCache en la misma aplicación web. Lo que sucede en tal caso es que los navegadores que no admiten Trabajadores de servicio usarán AppCache, y los que lo hagan ignorarán el AppCache y dejarán que el Trabajador de servicio asuma el control.
Fuentes: https://www.w3.org/TR/service-workers/#activation-algorithm , https://crbug.com/410665
Tienes razón, appcache se está quedando sin soporte .
Y hay otras opciones que almacenan datos y / o activos dentro del BID, tales como:
- Aplicaciones web sin conexión con CouchDB, PouchDB y Emeber CLI
- Ember-Pouch
- Aplicaciones sin conexión que utilizan Ionic Framework, PouchDB y AngularJS
Trate de googlear " offline pouchdb ember " o " offline pouchdb angular " para obtener más ejemplos.
Los únicos mecanismos para garantizar la disponibilidad fuera de línea en este momento son los trabajadores de servicios y appcache. Período.
Todas estas técnicas se basan en que su sitio sea una aplicación de una sola página y que el punto de entrada sea accesible. Por lo tanto, si no está utilizando appcache o trabajadores de servicio para garantizar que el punto de entrada esté siempre accesible, debe recurrir a la memoria caché http y configurar correctamente los encabezados relacionados con la memoria caché cuando sirva sus activos. De todos modos, la caché http puede ser desalojada en cualquier momento por la UA.
Ante esta decisión, si es obligatorio que la aplicación se ejecute sin conexión y en Safari , la única opción es usar appcache (AFAIK, no hay noticias sobre cómo eliminar appcache de Safari).
Para reducir el riesgo, puede optar por combinar una de las técnicas anteriores (las que almacenan activos en IndexedDB) además de appcache, de modo que lo único que almacene en caché sea el punto de entrada para el SPA. Si appcache deja de ser compatible y no existe una alternativa de trabajador de servicio, podría cambiar a la alternativa de encabezados de caché.
De todos modos, puede usar la detección de características ( if (''serviceWorker'' in navigator) { ... } ) para ver si hay trabajadores de servicio disponibles y usarlos en caso de que estén disponibles. Hay un polyfill para appcache basado en trabajadores de servicio llamado JakeCache (no probado) y otros están por venir .