Aplicaciones Web Progresivas y Service Workers
Las Aplicaciones Web Progresivas (PWA) buscan hacer realidad la eterna promesa de tener aplicaciones Web similares a las aplicaciones convencionales que usamos en nuestros teléfonos móviles.
A fin de cumplir esta promesa, se busca que estas aplicaciones Web sean; rápidas, tengan un interfaz similar a la de cualquier aplicación nativa para móvil, puedan realizar notificaciones como cualquier otra App, y sobretodo, que puedan funcionar (mas o menos) sin conexión a Internet.
¿Cómo convertir Webs en Aplicaciones Web Progresivas?
Para lograr este objetivo, hay varios aspectos involucrados que hay que contemplar. Algunos son bien conocidos como los que nos permiten que una Web sea responsive. Sin embargo, otros menos conocidos son:
Single Page Application
Lo que se conoce como una SPA (Single Page Application). La idea de las SPA es tener «toda la aplicación Web» en una «única página», de forma similar a lo que sucede cuando, por ejemplo, entramos a nuestro correo electrónico de gmail. La SPA sería básicamente la aplicación Web, y tendría todo lo necesario para trabajar (aunque sea de forma limitada) incluso sin conexión. Así, siguiendo con el ejemplo, deberíamos de ser capaces de, por ejemplo, redactar un email aunque no tuviéramos conexión. Obviamente, tarde o temprano es muy probable que la aplicación Web necesite tener conexión a Internet, pero la filosofia que hay detrás de las Aplicaciones Web Progresivas es que puedan «funcionar» sin una conexión continua y estable a Internet. Para poder crear una página Web tipo SPA, podéis echarle un vistazo a frameworks como React, Angular o Vue. No es un tema fácil, y de hecho, técnicamente no es un requisito imprescindible, pero si es algo muy interesante y recomendable si vamos a hacer una PWA.
Título e iconos
Otro aspecto para hacer pasar una Web por una aplicación nativa móvil, tiene que ver con aspectos más estéticos, como por ejemplo, el icono y el título que tendrá dicha aplicación Web en el escritorio de nuestro móvil. Para este tipo de detalles, desafortunadamente, aún no hay una forma estandarizada y en cada sistema operativo es diferente. En iOS, por ejemplo, se hace simplemente con unos elementos meta en el head de nuestra página Web. Mientras que en el caso de Android (y Chrome), se hace a través de un archivo llamado manifest.json. Al igual que sucede en iOS, deberemos de indicar este archivo usando un meta en el head de nuestra página; con un atributo rel=»manifest» y otro atributo href indicando la localización de nuestro archivo json.
En el siguiente enlace podéis crear un favicon todos los iconos necesarios para diferentes sistemas operativos y un archivo manifest.json básico (que deberíais de mejorar añadiendo lo que le falte);
https://www.favicon-generator.org/
Para más detalles sobre el manifest.json;
https://developers.google.com/web/fundamentals/web-app-manifest/
Service Worker
Finalmente, otro aspecto que si que es fundamental para lograr crear Aplicaciones Web Progresivas, es que la aplicación pueda hacer cosas como enviar notificaciones o funcionar sin conexión; y para ello, necesitamos un Service Worker.
¿Qué son los Service Workers?
Lo primero de todo es no confundir los Service Workers con los Web Workers. Los segundos sirven simplemente para ejecutar en un hilo secundario tareas pesadas de nuestra página y de este modo evitar que dichas tareas pesadas puedan bloquear el hilo de ejecución principal. Con esto se logra que la página Web no se quede «como bloqueada» mientras esta haciendo «cosas complicadas» con JavaScript.
Un Service Worker, por otro lado, sería algo en cierto modo similar a los servicios de Windows, o los dameons de Linux. Con la diferencia de que en lugar de instalarse en nuestro sistema operativo, podríamos decir que se instalan en el navegador.
Si queréis ver los Service Workers que tenéis instalados en Chrome, podéis abrir esta dirección en vuestro navegador.
chrome://serviceworker-internals/
Al igual que sucede con los servicios de Windows o los daemons de Linux, no son programas diseñados para que un usuario interactúe directamente con ellos, ya que no disponen de una interfaz de usuario. Es decir, no son «interactivos».
Así, la comunicación con estos programas, se realiza a través de las páginas Web de nuestro sitio (concretamente a través de la interfaz postMessage). Estos programas pueden estar realizando tareas en un segundo plano, sin intervención directa del usuario. Un aspecto importante es que a diferencia del resto de scripts de nuestra página Web, los Service Workers no se detienen ni se reinician cuando dentro de nuestro sitio Web cambiamos de una página a otra. De hecho, pueden seguir ejecutándose aunque no tengamos ninguna página abierta de nuestro sitio Web. Ahora bien, no vamos a tener control sobre cuándo se ejecuta o no nuestro Service Worker, por lo que si queremos almacenar algo de información para poder usarla entre ejecuciones, deberemos guardar dicha información en el servidor Web, o bien en el navegador del usuario (por ejemplo, usando el API IndexedDB).
Espero que este tema os haya resultado de interés. En un próximo artículo pasaremos de la teoría a la práctica y veremos en detalle cómo implementar un Service Worker para lograr que nuestra Web se aproxime al concepto de Aplicaciones Web Progresivas.