<h1>Tu primera Progressive Web App</h1>

Introducción

¿Qué hace de una aplicación web, una Progressive Web Aplicación?

Las Progressive Web Aplicaciones dan un instalable, experiencia de aplicación como en ordenadores de escritorio y móviles que se crean y entregan directamente a través de la página web. Son aplicaciones web que son rápidas y confiables. Y lo más importante, son aplicaciones web que funcionan en cualquier navegador. Si estás creando una aplicación web hoy, ya estás en el camino hacia la creación de una Progressive Web Aplicación.

Rápida y Confiable

Toda experiencia web ha de ser rápida, y esto es en especial cierto para las Progressive Web Aplicaciones. Rápida se refiere mientras que se tarda en obtener contenido significativo en la pantalla y brinda una experiencia interactiva en menos de cinco segundos.

Y, debe ser confiablemente rápido. Es difícil enfatizar lo bastante lo bueno que es el desempeño confiable. Piénsalo de esta manera: la primera carga de una aplicación nativa es frustrante. Está recluído por una tienda de aplicaciones y una descarga enorme, mas cuando llegas al punto de instalar la aplicación, ese coste inicial se amortiza en todos los inicios de la aplicación, y ninguno de esos inicios tiene un retraso variable. Cada comienzo de aplicación es tan rápido como el último, sin variación. Una Progressive Web Aplicación debe ofrecer este rendimiento confiable que los usuarios aguardan de cualquier experiencia instalada.

Instalable

Las Progressive Web Aplicaciones pueden ejecutarse en una pestaña del navegador, pero también son instalables. diseño páginas web ciudad real ñadir a marcadores un lugar sencillamente añade un acceso directo, pero una Progressive Web Aplicación instalada se ve y se comporta como todas y cada una de las demás aplicaciones instaladas. Se comienza desde exactamente el mismo lugar que se lanzan otras aplicaciones. Puedes controlar la experiencia de lanzamiento, incluyendo una pantalla de comienzo adaptada, iconos y más. Se ejecuta como una aplicación, en una ventana de aplicación sin una barra de direcciones o bien otra interfaz de usuario del navegador. Y como todas las demás aplicaciones instaladas, es una aplicación de nivel superior en el gestor de tareas.

Recuerda, es esencial que una PWA instalable sea rápida y confiable. Los usuarios que instalan una PWA esperan que sus aplicaciones funcionen, sin importar lo más mínimo en qué tipo de conexión de red estén conectados. Es una expectativa de referencia que todas las aplicaciones instaladas deben cumplir.

Móvil y Escritorio

Mediante el uso de técnicas de diseño acomodable, las Progressive Web Aplicaciones marchan en el móvil y escritorio, usando una base de código única entre plataformas. Si estás considerando escribir una aplicación nativa, eche una ojeada a los beneficios que ofrece una PWA.

Qué construirás

En este laboratorio de código, vas a edificar una aplicación web meteorológica utilizando las técnicas de una Progressive Web App. Tu aplicación:

• Usará diseño amoldable, por lo que funciona en escritorio o bien móvil.

• Será rápido, usa un service worker para guardar en precache los recursos de la aplicación (HTML, CSS, JavaScript, imágenes) precisos para ejecutar y guardar en caché los datos meteorológicos en tiempo de ejecución para progresar el desempeño.

• Será instalable, usando un manifiesto de aplicación web y el evento beforeinstallprompt para avisar al usuario que es instalable.

Lo que aprenderás

• Cómo crear y agregar un manifiesto de aplicación web.

• Cómo administrar una experiencia sin conexión simple

• Cómo suministrar una experiencia sin conexión completa

• Como hacer instalable tu aplicación

Este laboratorio de código está enfocado en Progressive Web Aplicaciones. Los conceptos y los bloques de código no relevantes se pasan por alto y se dan para que usted simplemente copie y pegue.

Lo que necesitarás

• Una versión reciente de Chrome (setenta y cuatro o bien siguiente) las PWAs son solo aplicaciones web y marchan en todos y cada uno de los navegadores, mas usaremos ciertas funciones de Chrome DevTools para comprender mejor lo que está sucediendo a el nivel de navegador y usarlo para probar la experiencia de instalación.

• Conocimiento de HTML, CSS, JavaScript y .

Preparación

Consigue una clave para la API de Dark Sky

Nuestros datos meteorológicos proceden de . Para poder usarlo, deberás solicitar una API key. Es fácil de emplear y sin costo para proyectos no comerciales.

Verifica que tu API key marcha correctamente

Para demostrar que tu API key marcha apropiadamente, efectúa una solicitud HTTP a la API de DarkSky. Actualiza la URL a continuación para sustituir DARKSKY_API_KEY con tu API key. Si todo funciona, debería ver el último pronóstico del tiempo para la ciudad de la ciudad de Nueva York.

/forecast/DARKSKY_API_KEY/40. ,-setenta y tres.

Obtén el código

Hemos puesto todo cuanto precisas para este proyecto en un repositorio de Git. Para comenzar, deberás conseguir el código y abrirlo en tu entorno de desarrollo favorito. Para este laboratorio de código, aconsejamos usar Glitch.

Muy recomendable: emplea Glitch para importar el repositorio

Usar Glitch es el método recomendado para trabajar a través de este código.

1. Abre una nueva pestaña del navegador y ve a .

1. Si no tienes una cuenta, deberás registrarte.

1. Haz clic en New Project, entonces Clone from Git Repo.

1. Clone /googlecodelabs/your-first-pwapp.git y Haz clic en Accept.

1. Una vez que se haya cargado el repositorio, edita el archivo .env y actualízalo con tu API key DarkSky.

1. HAz clic en el botón Mostrar Live para poder ver la PWA en acción.

Alternativa: Descargar código y trabajar localmente

Si quieres descargar el código y trabajar de forma local, deberás tener una versión reciente de Node y la configuración del editor de códigos y listo para usar.

1. Desempaqueta el fichero zip descargado.

1. Ejecuta npm install para instalar las dependencias necesarias para ejecutar el servidor.

1. Edita server.js y configura la API key de DarkSky.

1. Ejecuta node server.js para empezar el servidor en el puerto ocho mil.

1. Abre una pestaña del navegador en

Establecer una línea de base

¿Cuál es nuestro punto de partida?

Nuestro punto de inicio es una aplicación meteorológica básica diseñada para este laboratorio de código. El código se ha simplificado demasiado para enseñar los conceptos en este laboratorio de código y tiene poco manejo de errores. Si escoges volver a utilizar algo de este código en una aplicación de producción, asegúrate de manejar cualquier error y probar absolutamente todo el código.

Algunas cosas para probar...

1. Agrega una nueva ciudad con el botón más azul en el rincón inferior derecha.

1. Actualiza los datos con el botón de actualización en el rincón superior derecha.

1. Borra una ciudad utilizando la x en la parte superior derecha de cada tarjeta de urbe.

1. Mira cómo marcha en el escritorio y en el móvil.

1. Mira lo que sucede cuando te desconectas.

1. Usando el panel de la Red de Google Chrome, mira qué sucede cuando la red se limita a Slow 3G.

1. Agrega un retraso al servidor de pronóstico mudando FORECAST_DELAY en server.js

Auditoría con Lighthose

es una herramienta fácil de usar para asistir a mejorar la calidad de tus sitios y páginas. Cuenta con auditorías de desempeño, accesibilidad, Progressive Web Apps y más. Cada auditoría tiene un documento de referencia que explica por qué la auditoría es esencial, así como la manera de solucionarla.

empresas de web madrid ón Weather y verificar los cambios que hemos efectuado.

Vamos a ejecutar Lighthouse

1. Abre tu proyecto en una nueva pestaña.

1. Abre Google Chrome DevTools y cambia a la pestaña Audits, DevTools muestra una lista de categorías de auditoría, déjelas todas y cada una habilitadas.

1. Haz clic en Ejecutar auditorías, después de segundos, Lighthouse te da un informe en la página.

La auditoría Progressive Web App

Nos vamos a centrar en los resultados de la auditoría de la Progressive Web App.

Y hay mucho colorado en lo que centrarse:

• ❗FALLADO: La página actual no responde con un 200 cuando está desconectado.

• ❗FALLADO: start_url no responde con un 200 cuando está desconectado.

• ❗FALLADO: No registra un service worker que controle la página y start_url.

• ❗FALLADO: El manifiesto de la aplicación web no cumple con los requisitos de instalación.

• ❗FALLADO: No está configurado para una pantalla de inicio personalizada.

• ❗FALLADO: No establece un color de tema de la barra de direcciones.

¡Saltemos y empecemos a solucionar algunos de estos inconvenientes!

Añadir un manifiesto de aplicación web

Al final de esta sección, nuestra aplicación meteorológica pasará las siguientes auditorías:

• El manifiesto de la aplicación web no cumple con los requisitos de instalación.

• No está configurado para una pantalla de comienzo adaptada.

• No establece un color de tema de la barra de direcciones.

Crear el manifiesto de la aplicación web.

es un fichero JSON simple que deja que tú, el desarrollador, puedas supervisar cómo se muestra tu aplicación al usuario.

Usando el manifiesto de la aplicación web, tu aplicación web puede:

• Indicar al navegador que quieres que se abre tu aplicación en una ventana independiente ( display ).

• Definir qué página se abre cuando la aplicación se inicia por vez primera ( start_url ).

• Definir cómo debería ser la aplicación en el dock o bien lanzador de apps ( short_name, icons ).

• Crear una pantalla de name ( name, icons, colors ).

• Indicar al navegador que abre la ventana en modo horizontal o retrato ( orientation ).

• Y .

Crea un archivo llamado public/manifest.json en tu proyecto y copia/pega los siguientes contenidos:

public/manifest.json

El manifiesto acepta una serie de iconos, destinados a diferentes tamaños de pantalla. Para este laboratorio de código, hemos incluido algunos otros ya que los necesitábamos para nuestra integración con iOS.

Añadir un enlace al manifiesto de la aplicación web

A continuación, debemos informarle al navegador sobre nuestro manifiesto agregando <link rel="manifest"... a cada página de nuestra aplicación. Añade la siguiente línea al elemento <head> en tu archivo index.html.

DevTools, un pequeño desvío

DevTools proporciona una manera rápida y fácil de repasar tu archivo manifest.json. Abre el panel Manifest en el panel Aplication. Si has agregado la información del manifiesto adecuadamente, podrás verla analizada y mostrada en un formato entendible por los humanos en este panel.

Safari en iOS no acepta el manifiesto de aplicación web (), por lo que deberás añadir al <head> de tu archivo index.html :

Bonus: arreglos fáciles de Lighthouse

Nuestra auditoría de Lighthouse mencionó otras cosas que son bastante fáciles de reparar, así que cuidémoslas mientras que estamos aquí.

Establecer la descripción meta

Bajo la auditoría de posicionamiento SEO, Lighthouse anotó que nuestro "". Las descripciones se pueden enseñar en los resultados de búsqueda de Google. Las descripciones únicas y de alta calidad pueden hacer que tus resultados de búsqueda sean más relevantes para los usuarios y pueden aumentar tu tráfico de búsqueda.

Para agregar una descripción, agrega la próxima etiqueta meta al <head> de tu documento:

Establecer el color del tema de la barra de direcciones

En la auditoría de PWA, Lighthouse observó que nuestra aplicación "". El hecho de que la barra de direcciones del navegador coincida con los colores de su marca proporciona una experiencia de usuario más envolvente.

Para establecer el tono del tema en el móvil, añade la próxima etiqueta meta al <head> de tu documento:

Verificar cambios con Lighthouse

Ejecuta Lighthouse de nuevo (haciendo click en el signo + en el rincón superior izquierda del panel Audits) y verifica tus cambios.

Auditoría SEO

• ✅ PASADO: El documento tiene una meta descripción.

Auditoría de Progressive Web App

• ❗FALLADO: La página actual no responde con un 200 cuando está desconectado.

• ❗FALLADO: start_url no responde con un doscientos cuando está desconectado.

• ❗FALLADO: No registra un service worker que controla la página y start_url.

• ✅ PASADO: El manifiesto de la aplicación web cumple con los requisitos de instalación.

• ✅ PASADO: Configurado para una pantalla de inicio personalizada.

• ✅ PASADO: Establece un color de tema de la barra de direcciones.

Proporciona una experiencia offline básica

Los usuarios esperan que las aplicaciones instaladas siempre y en todo momento tengan una experiencia de referencia si están sin conexión. De ahí que es esencial que las aplicaciones web instalables nunca muestren el dinosaurio sin conexión de Google Chrome. La experiencia sin conexión puede abarcar desde una página sin conexión simple hasta una experiencia de solo lectura con datos guardados anteriormente en caché, hasta una experiencia sin conexión completamente funcional que se sincroniza automáticamente cuando se restaura la conexión de red.

En esta sección, añadiremos una página sin conexión simple a nuestra aplicación meteorológica. Si el usuario intenta cargar la aplicación mientras que está sin conexión, mostrará nuestra página adaptada, en lugar de la página sin conexión típica que muestra el navegador. Al final de esta sección, nuestra aplicación meteorológica pasará las siguientes auditorías:

• La página actual no responde con un 200 cuando está desconectado.

• start_url no responde con un 200 cuando está desconectado.

• No registra un service worker que controla la página y start_url.

En la próxima sección, sustituiremos nuestra página sin conexión personalizada con una experiencia sin conexión completa. Esto mejorará la experiencia sin conexión, mas lo que es más esencial, mejorará significativamente nuestro desempeño, ya que la mayoría de nuestros activos (HTML, CSS y JavaScript) se almacenarán y servirán localmente, eliminando la red como un posible cuello de botella.

Si no estás familiarizado con los service workers, leyendo puedes hacerte una idea básica sobre lo que pueden hacer, cómo marcha su ciclo de vida y más. Una vez que hayas completado este laboratorio de código, asegúrate de comprobar el para tener una visión más detallada de cómo trabajar con los service workers.

Las funciones proporcionadas a través de los service workers se deben considerar una mejora progresiva y se deben agregar solo si el navegador las acepta. Por servirnos de un ejemplo, con los service workers puedes guardar en caché la y los datos de tu aplicación, de forma que esté libre incluso cuando la red no lo esté. Cuando los service workers no son compatibles, no tiene por nombre al código sin conexión y el usuario consigue una experiencia básica. El uso de la detección de características para otorgar mejoras progresivas tiene poca sobrecarga y no se interrumpirá en los navegadores antiguos que no son compatibles con esa característica.

Registrar el service worker

El primer paso es registrar al service worker. Agrega el siguiente código a tu fichero index.html :

Este código comprueba si la API de service workers está disponible y, si lo está, el service worker en /service-worker.js se registra cuando la página es .

Ten en cuenta que el service worker se sirve desde el directorio raíz, no desde un directorio /scripts/. Esta es la forma más fácil de configurar el scope de tu service worker. El scope del service worker determina qué ficheros controla el service worker, esto es, desde qué senda el service worker interceptará las solicitudes. El valor predeterminado de scope es la ubicación del archivo de service worker y se extiende a todos los directorios a continuación. Entonces, si service-worker.js se halla en el directorio raíz, el service worker controlará las solicitudes de todas y cada una de las páginas web en este dominio.

Precache página sin conexión

Primero, debemos decirle al service worker qué guardar en caché. Ya hemos creado una simple (public/offline.html) que se mostrará cada vez que no haya conexión de red.

En tu service-worker.js, añade '/offline.html', al array de FILES_TO_CACHE, el resultado final debería verse así:

A continuación, debemos actualizar el acontecimiento install para indicar al service worker que precachee la página sin conexión:

Nuestro acontecimiento install ahora abre la caché con caches.open() y da un nombre de caché. Administrar un nombre de caché nos deja versionar archivos, o bien datos separados de los recursos almacenados en caché a fin de que podamos actualizar fácilmente uno pero no afecte al otro.

Una vez que la caché esté abierta, podemos llamar a cache.addAll(), que consigue una lista de URLs, las obtiene del servidor y agrega la contestación a la caché. Ten en cuenta que cache.addAll() se rechazará si falla ciertas peticiones individuales. Eso significa que tienes la garantía de que, si el paso de instalación se efectúa apropiadamente, tu caché estará en un estado consistente. Pero, si falla por alguna razón, lo intentará de nuevo automáticamente la próxima vez que se inicie el service worker.

DevTools, un pequeño desvío

Veamos cómo puedes emplear DevTools para comprender y depurar los service workers. Ya antes de regresar a cargar tu página, abre DevTools, ve al panel Service Workers en el panel Aplication. Debe tener un aspecto como este:

Cuando ves una página en blanco como esta, significa que la página en la actualidad abierta no tiene ningún service worker registrado.

Ahora, recarga tu página. El panel service workers ahora debería tener este aspecto:

Cuando veas información como esta, significa que la página tiene un service worker en ejecución.

Junto a la etiqueta de estado, hay un número (34251 en un caso así), observa ese número mientras trabaja con los service workers. Es una manera fácil de saber si tu service worker ha sido actualizado.

Limpieza de páginas sin conexión antiguas

Usaremos el acontecimiento activate para limpiar los datos antiguos en nuestro caché. Este código garantiza que tu service worker actualiza nuestra caché toda vez que cambie alguno de los archivos de la shell de la aplicación. Para que esto funcione, necesitarías acrecentar la variable CACHE_NAME en la parte superior de tu fichero de service worker.

Agrega el siguiente código a tu evento activate :

DevTools, un pequeño desvío

Con el panel service workers abierto, actualiza la página, verá el nuevo service worker instalado y el incremento del número de estado.

El service worker actualizado toma el control de manera inmediata por el hecho de que nuestro evento install finaliza con self.skipWaiting() y el evento activate concluye con self.clients.claim(). Sin esos, el service worker precedente continuaría controlando la página siempre que haya una pestaña abierta en la página.

Solicitudes de red fallidas

Y por último, precisamos manejar los acontecimientos de fetch. Vamos a utilizar una . El service worker primero intentará recobrar el recurso de la red, si eso falla, devolverá la página sin conexión de la caché.

El controlador fetch solo precisa manejar las navegaciones de la página, por lo que otras solicitudes pueden ser eliminadas del supervisor y serán tratadas normalmente por el navegador. Pero, si la solicitud .mode es navigate, utiliza fetch para procurar conseguir el elemento de la red. Si falla, el manejador de catch abre la caché con caches.open(CACHE_NAME) y utiliza cache.match('offline.html') para conseguir la página sin conexión predefinida. El resultado se devuelve al navegador mediante evt.respondWith().

DevTools, un pequeño desvío

Revisemos para asegurarnos de que todo funciona como lo aguardamos. Con el panel service workers abierto, actualiza la página, verás el nuevo service worker instalado y el aumento del número de estado.

También podemos verificar qué ha sido guardado en caché. Ve al panel Cache Storage en el panel Application de DevTools. Haz clic con el botón derecho en Cache Storage, selecciona Refresh Caches, expande la sección y deberías ver el nombre de su caché estática en el lado izquierdo. Al hacer click en el nombre de la memoria caché se muestran todos los ficheros que están en caché.

Ahora, probaremos el modo sin conexión. Vuelve al panel Service Workers de DevTools y marca la casilla Offline. Después de mudarlo, deberías ver un pequeño icono de advertencia amarillo junto a la pestaña del panel Network. Esto señala que estás desconectado.

Recarga tu página y... ¡funciona! ¡Obtenemos nuestro panda desconectado, en vez del dino desconectado de Google empresa diseño tiendas online valencia !

Consejos para probar los service workers

Depurar a los service workers puede ser un desafío, y cuando se trata de almacenamiento en caché, las cosas pueden transformarse en una pesadilla aún más si la caché no se actualiza cuando se espera. Entre el ciclo de vida típico de un service worker y un fallo en su código, puedes frustrarte rápidamente. Pero no .

Usar DevTools

En el panel service workers del panel Application, hay algunas casillas de verificación que harán tu vida mucho más fácil.

• Offline - Cuando se marca, simula una experiencia sin conexión y evita que cualquier solicitud vaya a la red.

• Actualización en la recarga - Cuando se marca, se obtendrá el service worker más reciente, se instalará y se activará de inmediato.

• Bypass para red - Cuando se marca, las solicitudes pasan por alto al service worker y se envían de forma directa a la red.

Borrón y cuenta nueva

En algunos casos, posiblemente esté cargando datos en caché o bien que las cosas no se actualizan como esperas. Para borrar todos los datos guardados (localStorage, indexedDB data, cached archivos) y quitar cualquier service worker, utiliza el panel Clear storage en la pestaña Application. Alternativamente, también puedes trabajar en una ventana de incógnito.

Consejos adicionales:

• Una vez que un service worker no ha sido registrado, puede continuar en la lista hasta el momento en que se cierre la ventana que contiene el navegador.

• Si hay varias ventanas abiertas de tu aplicación, un nuevo service worker no entrará en vigencia hasta que todas y cada una de las ventanas hayan sido recargadas y actualizadas al último service worker.

• ¡Desregistrar un service worker no borra la caché!

• Si existe un service worker y un nuevo service worker está registrado, el nuevo service worker no tomará el control hasta el momento en que la página es recargada, a menos que .

Verificar cambios con Lighthouse

Ejecuta Lighthouse nuevamente y verifica tus cambios. ¡No olvides desactivar la opción Offline antes de verificar tus cambios!

Auditoría SEO

• ✅ PASADO: El documento tiene una meta descripción.

Auditoría de Progressive Web App

• ✅ PASADO: La página actual responde con un doscientos cuando está sin conexión.

• ✅ PASADO: start_url responde con un 200 cuando está desconectado.

• ✅ PASADO: Registra un service worker que controla la página y start_url.

• ✅ PASADO: El manifiesto de la aplicación web cumple con los requisitos de instalación.

• ✅ PASADO: Configurado para una pantalla de comienzo adaptada.

• ✅ PASADO: Establece un color de tema de la barra de direcciones.

Brindar una experiencia sin conexión completa

Tómate un momento, pon tu teléfono en modo avión e procura ejecutar ciertas de sus aplicaciones preferidas. En casi todos los casos, proporcionan una experiencia sin conexión bastante robusta. Los usuarios esperan un experiencia robusta de sus aplicaciones. Y la página web no debería ser diferente. Las Progressive Web Aplicaciones deben diseñarse para unas condiciones sin conexión como escenario principal.

Ciclo de vida del service worker

El ciclo de vida del service worker es la parte más complicada. Si no sabes qué es lo que está tratando de hacer y cuáles son los beneficios, puedes sentir que está combatiendo contra ti. Mas en el momento en que sepas cómo marcha, puedes ofrecer actualizaciones integrales y prudentes a los usuarios, mezclando lo mejor de la página web y los patrones nativos.

install

El primer acontecimiento que recibe un service worker es install. Se activa tan pronto como el worker se ejecuta, y solo lleva por nombre una vez por service worker. Si alteras la secuencia de comandos de tu service worker, el navegador lo considerará un service worker diferente, y obtendrá su evento install.

Normalmente, el evento install se usa para guardar en caché todo lo que necesita a fin de que tu aplicación se ejecute.

activate

El service worker recibirá un evento activate toda vez que se inicie. El objetivo principal del evento activate es configurar el comportamiento del service worker, limpiar los recursos que quedan de las ejecuciones anteriores (por ejemplo, cachés antiguas) y preparar al service worker para manejar las peticiones de red (por ejemplo, el evento fetch que se describe a continuación).

fetch

El acontecimiento fetch deja que el service worker intercepte cualquier solicitud de red y maneje las peticiones. Puede ir a la red para conseguir el recurso, puede extraerlo de su propia caché, generar una contestación personalizada o cualquiera de las múltiples opciones. Echa un vistazo a para poder ver las diferentes estrategias que puedes emplear.

Actualizando un service worker

El navegador comprueba si hay una nueva versión de tu service worker en todos y cada carga de página. Si encuentra una nueva versión, la nueva versión se descarga y también instala en segundo plano, pero no está activada. Se halla en estado de espera, hasta que ya no queda ninguna página abierta que utilice el viejo service worker. En el momento en que se cierran todas y cada una de las ventanas que usan el antiguo service worker, el nuevo service worker se activa y puede tomar el control. Consulte la sección del documento del ciclo vital del service worker para conseguir más detalles.

Elegir la estrategia de almacenaje en caché correcta

Elegir la adecuada depende del género de recurso que intentes almacenar en caché y de cómo podría necesitarlo más adelante. Para nuestra aplicación meteorológica, vamos a dividir los recursos que necesitamos para guardar en caché en dos categorías: los recursos que deseamos incluir en caché y los datos que almacenaremos en caché en tiempo de ejecución.

Almacenamiento en caché de recursos estáticos

Precachear tus recursos es un término similar a lo que pasa en el momento en que un usuario instala una aplicación de escritorio o móvil. Los recursos clave necesarios para que la aplicación se ejecute se instalan o se guardan en la memoria caché del dispositivo para que puedan cargarse más tarde, si hay conexión de red o no.

Para nuestra aplicación, almacenaremos previamente todos nuestros recursos estáticos cuando nuestro service worker esté instalado, de modo que todo cuanto precisamos para ejecutar nuestra aplicación se almacene en el dispositivo del usuario. Para asegurar que nuestra aplicación se cargue a la velocidad de la luz, usaremos la estrategia ; en lugar de ir a la red para conseguir los recursos, se extraen de la caché local; Sólo si no está libre, intentaremos obtenerlo de la red.

Extraer de la memoria caché local suprime cualquier variabilidad de la red. No importa en qué tipo de red esté el usuario (WiFi, 5G, 3G o bien incluso 2G), los recursos clave que precisamos para ejecutar están libres prácticamente inmediatamente.

Los datos de la aplicación

La es ideal para determinados tipos de datos y marcha bien para nuestra aplicación. Consigue los datos en la pantalla lo más rápido posible, después los actualiza cuando la red ha devuelto los datos más recientes. Stale-while-revalidate significa que debemos empezar dos solicitudes asíncronas, una para la memoria caché y otra para la red.

En circunstancias normales, los datos almacenados en la memoria caché se devolverán casi inmediatamente proporcionando la aplicación con datos recientes que puede usar. Entonces, cuando vuelva la solicitud de red, la aplicación se actualizará utilizando los datos más recientes de la red.

Para nuestra aplicación, esto proporciona una mejor experiencia que la red, recurriendo a la estrategia de caché pues el usuario no tiene que aguardar hasta el momento en que la solicitud de la red caduque para poder ver algo en la pantalla. Posiblemente en un inicio vean datos más viejos, mas una vez que se devuelva la solicitud de red, la aplicación se actualizará con los datos más recientes.

Actualizar la lógica de la aplicación

Como se mencionó anteriormente, la aplicación debe comenzar dos solicitudes asíncronas, una para la caché y otra para la red. La aplicación emplea el objeto caches disponible en window para acceder a la memoria caché y recuperar los últimos datos. Este es un genial ejemplo de mejora progresiva en tanto que el objeto caches puede no estar disponible en todos los navegadores, y si no es así, la petición de red debería marchar.

Actualiza la función getForecastFromCache() para verificar si el objeto caches está disponible en el objeto global window y, si lo está, pide los datos de la memoria caché.

Después, debemos modificar a fin de que haga dos llamadas, una a getForecastFromNetwork() para obtener el pronóstico de la red y otra a getForecastFromCache() para obtener el último pronóstico almacenado en caché:

Nuestra aplicación meteorológica ahora realiza 2 solicitudes asíncronas de datos, una desde la caché y otra a través de un fetch. Si hay datos en la caché, serán devueltos y procesados extremadamente rápido (decenas y decenas de milisegundos). Luego, cuando responda fetch, la tarjeta se actualizará con los datos más recientes de forma directa de la API meteorológica.

Observe cómo la petición de caché y la solicitud fetch acaban con una llamada para actualizar la tarjeta de pronóstico. ¿Cómo sabe la aplicación si muestra los últimos datos? Esto se maneja en el siguiente código de renderForecast() :

Cada vez que se actualiza una tarjeta, la aplicación almacena la marca de tiempo de los datos en un atributo oculto en la tarjeta. La aplicación sencillamente comprueba si la marca de tiempo que ya existe en la tarjeta es más reciente que los datos que se pasaron a la función.

Pre-cachear nuestros recursos de la aplicación

En el service worker, añadimos un DATA_CACHE_NAME para poder separar los datos de nuestras aplicaciones del shell de la aplicación. Cuando se actualiza el shell de la aplicación y se suprimen los cachés más antiguas, nuestros datos permanecerán íntegros, listos para una carga súper rápida. Ten en cuenta que si su formato de datos cambia en el futuro, necesitará una forma de manejar eso y garantizar que el shell y el contenido de la aplicación estén sincronizados.

No olvides actualizar también CACHE_NAME; Vamos a estar mudando todos nuestros recursos estáticos también.

Para que nuestra aplicación funcione sin conexión, debemos almacenar anteriormente todos y cada uno de los recursos que precisa. Esto también ayudará a nuestro desempeño. En lugar de tener que obtener todos y cada uno de los recursos de la red, la aplicación podrá cargarlos todos desde la caché local, eliminando la inestabilidad de la red.

Actualiza el array FILES_TO_CACHE con la lista de archivos:

Ya que estamos produciendo manualmente la lista de archivos a cachear, cada vez que actualizamos un archivo, debemos actualizar CACHE_NAME. Pudimos eliminar offline.html de nuestra lista de archivos en caché por el hecho de que nuestra aplicación ahora cuenta con todos y cada uno de los recursos necesarios para trabajar sin conexión y jamás volverá a enseñar la página sin conexión.

Actualizar el controlador de eventos activate

Para asegurar que nuestro acontecimiento activate no elimina accidentalmente nuestros datos, en el evento activate de service-worker.js, reemplaza if (key !== CACHE_NAME) con:

public / service-worker.js

Actualizar el supervisor de acontecimientos fetch

Necesitamos alterar el service worker para detener las solicitudes a la API metereológica y guardar sus contestaciones en la caché, para que podamos acceder a ellas fácilmente más adelante. En la estrategia stale-while-revalidate, aguardamos que la contestación de la red sea la "fuente de la verdad", siempre y en todo momento nos da la información más reciente. Si no puede, está bien fallar por el hecho de que ya hemos recuperado los últimos datos almacenados en caché en nuestra aplicación.

Actualiza el manejador de acontecimiento fetch para manejar las solicitudes a la API de datos por separado de otras peticiones.

El código intercepta la solicitud y comprueba si es para un pronóstico del tiempo. Si es así, emplea fetch para realizar la petición. En el momento en que se devuelve la respuesta, abre la memoria caché, clona la contestación, la guarda en la memoria caché y devuelve la respuesta al solicitante original.

Necesitamos eliminar la comprobación evt.request.mode !== 'navigate' por el hecho de que deseamos que nuestro service worker maneje todas las solicitudes (incluidas imágenes, scripts, archivos CSS, etc.), no solamente las navegaciones. Si dejamos ese registro, solo se entregará el HTML desde la memoria caché del service worker, todo lo demás se solicitará desde la red.

Pruébalo

La aplicación, sin conexión, debe estar absolutamente funcional ahora. Actualiza la página para asegurarte de que tienes instalado el service worker más reciente, entonces guarda un par de urbes y presiona el botón de actualización en la aplicación para obtener información actualizada sobre el tiempo.

Luego ve al panel Cache Storage en el panel Application de DevTools. Expande la sección y verás el nombre de su caché estático y la caché de datos en el lado izquierdo. Al abrir la caché de datos se deben enseñar los datos guardados para cada urbe.

Luego, abre DevTools y cambia al panel service workers, y marca la casilla de verificación Offline, entonces intenta regresar a cargar la página, después desconecta y vuelve a cargar la página.

Si estás en una red rápida y quiere ver cómo se actualiza datos de previsión del tiempo en una conexión lenta, ajusta el FORECAST_DELAY propiedad en server.js a 5000. Todas las peticiones a la API de pronóstico se retrasarán 5000ms.

Verificar cambios con Lighthouse

También es una buena idea regresar a ejecutar Lighthouse.

Auditoría SEO

• ✅ PASADO: El documento tiene una meta descripción.

Auditoría de Progressive Web App

• ✅ PASADO: La página actual responde con un doscientos cuando está sin conexión.

• ✅ PASADO: start_url responde con un 200 cuando está desconectado.

• ✅ PASADO: Registra un service worker que controla la página y start_url.

• ✅ PASADO: El manifiesto de la aplicación web cumple con los requisitos de instalación.

• ✅ PASADO: Configurado para una pantalla de inicio adaptada.

• ✅ PASADO: Establece un color de tema de la barra de direcciones.

Añadir experiencia de instalación

Cuando se instala una Progressive Web Aplicación, se ve y se comporta como todas y cada una de las demás aplicaciones instaladas. Se empieza desde exactamente el mismo sitio que se lanzan otras aplicaciones. Se ejecuta en una aplicación sin una barra de direcciones u otra interfaz de usuario del navegador. Y como todas y cada una de las demás aplicaciones instaladas, es una aplicación de nivel superior en el conmutador de labores.

En Google Chrome, una Progressive Web Aplicación puede instalarse a través del menú contextual de 3 puntos, o puede proporcionar un botón u otro componente de UI al usuario que le pedirá que instale tu aplicación.

Auditoría con Lighthouse

Para que un usuario pueda instalar tu Progressive Web Aplicación, debe cumplir con . La manera más fácil de contrastar es emplear Lighthouse y asegurarse de que cumpla con los criterios instalables.

Si has trabajado con este código, tu PWA ya debería cumplir con estos criterios.

Agrega install.js a index.html

Primero, agregamos el install.js a nuestro archivo index.html.

Escucha el acontecimiento beforeinstallprompt

Si se cumple la función de agregar a la pantalla de comienzo , Google Chrome activará un acontecimiento de beforeinstallprompt, que puede utilizar para señalar que tu aplicación se puede "instalar" y luego solicitar al usuario que la instale. Añade el próximo código para escuchar el acontecimiento beforeinstallprompt :

Evento guardar y mostrar el botón de instalación

En nuestra función saveBeforeInstallPromptEvent, saveBeforeInstallPromptEvent una referencia al evento beforeinstallprompt para poder llamar a prompt() más adelante y actualizar nuestra interfaz de usuario para enseñar el botón de instalación.

Mostrar el prompt / ocultar el botón

Cuando el usuario hace click en el botón de instalación, debemos llamar a .prompt() en el acontecimiento beforeinstallprompt guardado. También necesitamos ocultar el botón de instalación, por el hecho de que solo se puede llamar a .prompt() una vez en cada evento guardado.

Al llamar a .prompt() se mostrará un diálogo modal al usuario y se te pedirá que añadas tu aplicación a la pantalla de comienzo.

Registrar los resultados

Puedes verificar qué respondió el usuario al cuadro de diálogo de instalación escuchando la promesa que devuelve la propiedad userChoice del acontecimiento beforeinstallprompt salvado. La promesa devuelve un objeto con una propiedad outcome después de que se haya mostrado la petición y el usuario haya respondido a ella.

Un comentario sobre userChoice, , no es una función como podría esperarse.

Registrar todos los eventos de instalación

Adicionalmente a cualquier UI que añadadas para instalar tu aplicación, los usuarios también pueden instalar tu PWA a través de otros métodos, por ejemplo, el menú de 3 puntos de Chrome. Para rastrear estos acontecimientos, escuche el evento instalado.

Después, necesitaremos actualizar la función logAppInstalled, para este laboratorio de código, solo usaremos console.log, pero en una aplicación de producción, probablemente desearás registrar esto como un evento en tu software de analíticas.

Actualizar el service worker

No olvides actualizar CACHE_NAME en tu archivo service-worker.js, ya que has efectuado cambios en los ficheros que están en caché. diseño tiendas online zaragoza de verificación Bypass for network en el panel service workers del panel de aplicaciones en DevTools funcionará en el desarrollo, pero no ayudará en el mundo real.

Pruébalo

Vamos a ver cómo fue nuestro paso de instalación. Para estar seguro, usa el botón Clear site data en el panel de aplicaciones de DevTools para eliminar todo y asegurarte de que estamos empezando nuevamente. Si ya instalaste la aplicación, asegúrate de desinstalarla, de lo contrario, el icono de instalación no volverá a aparecer.

Verifica que el botón de instalación esté visible

Primero, comprobamos que nuestro ícono de instalación se muestre adecuadamente, asegúrate de probar esto tanto en el escritorio como en el móvil.

1. Abre la URL en una nueva pestaña de Google Chrome.

1. Abre el menú de tres puntos de Chrome (junto a la barra de direcciones). ▢ Verifica que vea "Instalar Tiempo..." en el menú.

1. Actualiza los datos metereológicos con el botón de actualización en la esquina superior derecha para asegurarnos de que cumplimos con las . ▢ Verifica que el icono de instalación esté visible en el encabezado de la aplicación.

Verifica que el botón de instalación funcione

A continuación, nos cercioramos de que todo se instala adecuadamente y de que nuestros acontecimientos se activan apropiadamente. Puedes hacerlo tanto en tu escritorio como en tu móvil. Si deseas probar esto en el móvil, asegúrate de que estás utilizando la depuración remota para ver lo que se está registrado en la consola.

1. Abre Google Chrome y, en una nueva pestaña del navegador, navega a tu PWA Clima.

1. Abre DevTools y cambia al panel de la consola.

1. Haz click en el botón de instalación en la esquina superior derecha. ▢ Comprueba que el botón de instalación desaparezca ▢ Verifica que se muestra el cuadro de diálogo modal de instalación.

1. Haz click en Cancelar. ▢ Verifica que "El usuario rechazó la petición A2HS" se muestra en la salida de la consola. ▢ Comprueba que el botón de instalación vuelva a aparecer.

1. Haz click en el botón Instalar nuevamente, entonces haz click en el botón Instalar en el diálogo modal. ▢ Comprueba que "El usuario aceptó la solicitud A2HS" se muestra en la salida de la consola. ▢ Comprueba que "aplicación meteorológica se haya instalado" se muestre en la salida de la consola. ▢ Comprueba que la aplicación meteorológica se añade al sitio donde en general encontrará las aplicaciones.

1. Inicia la PWA Clima. ▢ Comprueba que la aplicación se abre como una aplicación independiente, así sea en una ventana de la aplicación en el escritorio o bien en pantalla completa en el móvil.

Ten en cuenta que si está ejecutando en el escritorio desde localhost, tu PWA instalada puede mostrar una pancarta de dirección por el hecho de que localhost no se considera un host seguro.

Verifica que la instalación de iOS funcione correctamente

Veamos también el comportamiento en iOS. Si tienes un dispositivo iOS, puedes usarlo, o bien si estás utilizando un Mac, prueba el simulador de iOS disponible con Xcode.

1. Abre Safari y en una nueva pestaña del navegador, navega a tu PWA Clima.

1. Haz click en el botón Compartir! .

1. Desplázate hacia la derecha y Haz clic en el botón Agregar a la pantalla de inicio. ▢ Verifica que el título, la URL y el icono sean correctos.

1. Haz clic en Agregar. ▢ Verifica que el icono de la aplicación se agrega a la pantalla de comienzo.

1. Inicia la PWA Clima desde la pantalla de comienzo. ▢ Verifica que la aplicación se inicia en pantalla completa.

Bonus: ### si tu aplicación se comienza desde la pantalla de inicio

La media query display-mode deja aplicar estilos en dependencia de cómo se lanzó la aplicación, o determinar cómo se lanzó con JavaScript.

También puedes revisar la media query display-mode con .

Bonus: Desinstalando tu PWA

Recuerda, beforeinstallevent no se dispara si la aplicación ya está instalada, con lo que a lo largo del desarrollo probablemente querrás instalarla y desinstalarla múltiples veces para asegurarte de que todo marcha como se esperaba.

Android

En Android se desinstalan de igual forma que otras aplicaciones instaladas.

• Abre el cajón de aplicaciones.

• Desplázate hacia abajo para hallar el icono del tiempo.

• Arrastra el ícono de la aplicación a la parte superior de la pantalla.

• Elige Desinstalar.

ChromeOS

En ChromeOS, las PWA se desinstalan fácilmente desde el cuadro de búsqueda del iniciador.

• Abre el lanzador.

• Escribe "Clima" en el cuadro de búsqueda, tu PWA Tiempo debería aparecer en los resultados.

• Haz click derecho (alt-click) en la PWA Clima.

• Haz clic en Eliminar de Google Chrome...

macOS y Windows

En Mac y Windows se deben desinstalar a través de Chrome.

• En una nueva pestaña del navegador, abre chrome://apps.

• Haz clic derecho (alt-clic) en la PWA Tiempo.

• Haz click en Eliminar de Google Chrome...

Felicitaciones

¡Enhorabuena, has construido con éxito tu primera Progressive Web Aplicación!

Agregaste un manifiesto de aplicación web para dejar que se instalase, y añadiste un service worker para garantizar que tu PWA sea siempre y en toda circunstancia rápida y confiable. Has aprendido cómo emplear DevTools para auditar una aplicación y cómo esto puede progresar la experiencia de usuario.

Ahora conoce los pasos clave necesarios para transformar cualquier aplicación web en una Progressive Web App.

Lectura adicional

referencia

Encontró un problema o bien tiene comentarios?

Ayúdanos a prosperar nuestros laboratorios de códigos enviando una el día de hoy. ¡Y gracias!