Como Desarrollar Aplicaciones Web Progresivas Con Angular

UNIVERSIDAD MAYOR DE SAN SIMON
FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCIÓN DE POSGRADO
“COMO DESARROLLAR APLICACIONES WEB

PROGRESIVAS CON ANGULAR”
TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO

DE DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES
EMPRESARIALES VERSIÓN I.
POSTULANTE : JULIO CESAR QUISPE SOLIZ

TUTOR : Ing. EDSON ARIEL TERCEROS TORRICO
Cochabamba – Bolivia
2018
1
Agradecimientos
A mis madre y hermana; por siempre darme su
fuerza y apoyo incondicional que me ha
ayudado y llevado hasta donde estoy ahora.
A mi tutor de proyecto, por la colaboración que
me brindo a lo largo del mismo.
A Digital Harbor por abrir las puertas para
realizar este diplomado de doble titulación.
A mis amigos que me ayudaron y apoyaron en
los módulos de nuestro diplomado.
¡Muchas Gracias!
2
Índice de contenidos
1. Generalidades ........................................................................................................................... 11
1.1. Antecedentes Generales ........................................................................................................ 11
1.2. Antecedentes Específicos ....................................................................................................... 11
2. Metodología ............................................................................................................................. 11
3. Aplicaciones web progresivas ..................................................................................................... 12
3.1. Definición.............................................................................................................................. 12
3.1.1. Características de una aplicación web progresiva .............................................................. 12
3.1.2. Fiables ........................................................................................................................... 12
3.1.3. Veloces .......................................................................................................................... 13
3.1.4. Atractivas....................................................................................................................... 13
3.2. Tecnologías que aprovecha las aplicaciones web progresivas .................................................... 13
3.2.1. Diseño Responsivo.......................................................................................................... 13
3.2.1.1. Enfoque en diseño responsivo ..................................................................................... 14
3.2.2. Service Worker............................................................................................................... 14
3.2.2.1. Ciclo de vida de un Service Worker .............................................................................. 15
3.2.2.2. Requisitos .................................................................................................................. 16
3.2.2.3. Registro de un Service Worker..................................................................................... 17
3.2.2.4. Instalar un Service Worker .......................................................................................... 17
3.2.2.5. Cacheo y retorno de peticiones ................................................................................... 19
3.2.2.6. Actualización del Service Worker ................................................................................. 20
3.2.3. El modelo de App Shell ................................................................................................... 20
3.2.3.1. Beneficios .................................................................................................................. 22
3.2.3.2. Requisitos .................................................................................................................. 22
3.2.3.3. Compilar una App Shell ............................................................................................... 22
3.2.4. Manifiesto de la aplicación .............................................................................................. 23
4. Aplicación web progresiva con Angular ....................................................................................... 26
4.1. Definición.............................................................................................................................. 26
4.2. Fundamentos ........................................................................................................................ 26
4.2.1. Arquitectura .................................................................................................................. 26
4.2.2. Módulos ........................................................................................................................ 27
4.2.3. Componentes y plantillas ................................................................................................ 28
4.2.4. Formularios.................................................................................................................... 28
3
4.2.5. Enrutamiento y Navegación ............................................................................................ 29
4.2.6. Agregar App Shell ........................................................................................................... 29
4.2.6.1. Cargador.................................................................................................................... 30
4.2.6.2. Cabecera.................................................................................................................... 30
4.2.7. Agregar el manifiesto a una aplicación Angular. ................................................................ 30
4.2.8. Agregar Service Worker .................................................................................................. 32
5. Uso de herramientas para la auditoria de una aplicación web progresiva....................................... 36
5.1. Lista de verificación para una aplicación web progresiva........................................................... 36
5.1.1. Lista base de verificación ................................................................................................ 36
5.1.1.1. El sitio es servido a través de HTTPS ............................................................................. 36
5.1.1.2. Las páginas responden en dispositivos móviles ............................................................. 36
5.1.1.3. Todas las URL de las aplicaciones se cargan sin conexión ............................................... 36
5.1.1.4. Metadatos proporcionados para agregar home screen.................................................. 37
5.1.1.5. Primera carga rápida incluso en 3G .............................................................................. 37
5.1.1.6. El sitio funciona navegador cruzado ............................................................................. 37
5.1.1.7. Las transiciones de página deben ser rápidas ................................................................ 37
5.1.1.8. Cada página tiene una URL .......................................................................................... 38
5.2. Auditar aplicaciones web con Lighthouse ................................................................................ 38
5.2.1. Corre Lighthouse como una extensión Chrome................................................................. 39
5.2.2. Lighthouse desde línea de comandos ............................................................................... 39
5.2.3. Registro Service Worker.................................................................................................. 40
5.2.3.1. Requerimientos para esta auditoria ............................................................................. 40
5.2.3.2. Implementación de la auditoria ................................................................................... 40
5.2.4. Manifiesto de la aplicación .............................................................................................. 40
5.2.4.1. Como aprobar la auditoria........................................................................................... 40
6. Aplicación de caso de estudio..................................................................................................... 42
6.1. Migración de una aplicación Angular....................................................................................... 42
6.2. Auditar aplicación con Lighthouse........................................................................................... 42
6.3. Agregar App Shell .................................................................................................................. 44
6.3.1. Cargador........................................................................................................................ 44
6.3.2. Cabecera ....................................................................................................................... 44
6.3.3. JS Fallback...................................................................................................................... 44
6.4. Agregar el Manifiesto en la aplicación ..................................................................................... 45
4
6.5. Agregar Service Worker.......................................................................................................... 47
6.6. Uso de la aplicación como aplicación nativa............................................................................. 49
7. Conclusiones............................................................................................................................. 52
5
Índice de figuras
Figura 1 Ciclo de vida de un Service Worker........................................................................................ 16
Figura 2 Registro de un Service Worker. ............................................................................................. 17
Figura 3 Registro de recursos en caché con un Service Worker............................................................. 18
Figura 4 Agregar un Listener para cacheo y retorno de peticiones. ....................................................... 19
Figura 5 Definición de las diferentes secciones de una aplicación. ........................................................ 21
Figura 6 Ejemplo de una aplicación con Shell definida.......................................................................... 23
Figura 7 Ejemplo de archivo manifest.json. ......................................................................................... 24
Figura 8 Arquitectura de una aplicación Angular.................................................................................. 27
Figura 9 Ejemplo de un manifiesto en una aplicación Angular............................................................... 31
Figura 10 Agregar un manifiesto en una aplicación Angular.................................................................. 32
Figura 11 Agregar referencias de un manifiesto en el index.html en una aplicación Angular. .................. 32
Figura 12 Comando para agregar librerías para service worker en una aplicación Angular. ..................... 33
Figura 13 Definición de un archivo ngsw-config.json para una aplicación Angular. ................................. 33
Figura 14 Habilitar Service Worker en una aplicación Angular. ............................................................. 34
Figura 15 Agregar el módulo Service Worker en una aplicación Angular. ............................................... 34
Figura 16 Comando para hacer build de una aplicación Angular con Service Worker. ............................. 35
Figura 17 Comando para crear una aplicación Angular como aplicación web progresiva......................... 35
Figura 18 Ejemplo de una auditoría realizada con Lighthouse en una aplicación web. ............................ 39
Figura 19 Estructura mínima de un archivo manifest.json. ................................................................... 41
Figura 20 Opciones para auditar una aplicación web progresiva con Lighthouse. ................................... 42
Figura 21 Resultado de la auditoria en la aplicación del caso de estudio................................................ 43
Figura 22 Detalles de la auditoria en la aplicación del caso de estudio................................................... 43
Figura 23 Código de la cabecera de la aplicación del caso de estudio. ................................................... 44
Figura 24 Index.html para cuando los scripts no están disponibles........................................................ 45
Figura 25 Manifiesto de la aplicación del caso de estudio..................................................................... 46
Figura 26 Habilitación del manifiesto en la aplicación. ......................................................................... 46
Figura 27 Agregando el manifiesto en el archivo index.html. ................................................................ 47
Figura 28 Archivo de configuración para el Service Worker de la aplicación........................................... 48
Figura 29 Habilitación del Service Worker en la aplicación Angular. ...................................................... 48
Figura 30 Importar el Service Worker en el módulo de la aplicación Angular. ........................................ 49
Figura 31 Aplicación sin el uso de las tecnologías web progresivas........................................................ 50
Figura 32 Iconos de acceso directo de la aplicación web progresiva como nativas. ................................ 50
6
Figura 33 Aplicación web progresiva en una computadora de escritorio................................................ 51
Figura 34 Aplicación web progresiva en un dispositivo móvil. ............................................................... 51
7
Resumen
La presente monografía, está centrado en mejorar la experiencia del usuario cuando

utiliza un dispositivo móvil.
Tomando en cuenta la necesidad de mejorar estos aspectos en las aplicaciones web

para uso móvil, y el objetivo de construir una aplicación web progresiva con Angular, se
puede decir que se hizo un análisis de experiencia sobre una aplicación Angular normal,
donde se aplicó principios y algunas tecnologías para convertir este en una aplicación
web progresiva.
Para cumplir con esto se identifica los conceptos, características y principios de una
aplicación web progresiva. Con los conceptos de PWA se investigará las tecnologías
necesarias para realizar una aplicación web progresiva. Luego se realizó una auditoria
de una aplicación web progresiva con Lighthouse.
También se realizó un análisis de experiencia en base a una aplicación web Angular y

migrar este a una aplicación web progresiva.
Como herramientas de desarrollo primordial se empleó Angular, CSS, librerías

JavaScript, Service Worker, para test de la aplicación web progresiva, el uso del plugin
Lighthouse para Chrome y los principios que una aplicación web progresiva debe
cumplir.
8
Introducción
El estado actual de las aplicaciones Web existentes, es el de servicios enfocados a

ofrecer mejores soluciones al usuario final, brindando un ambiente más adecuado de
acuerdo al tipo de equipo que el usuario final emplea en el uso de la aplicación. Para
esto es necesario crear aplicaciones Web que puedan adaptarse de la mejor manera de
acuerdo al ambiente del usuario final. Para ello se hace uso de muchas técnicas como:
hojas de estilo, HTML válido semánticamente, menor refrescamiento de pantalla, mayor
intervención de programación del lado del cliente con JavaScript, entre otras; que
resultan en aplicaciones más dinámicas e intuitivas para el usuario.
En la actualidad existe aplicaciones móviles para los usuarios finales, pero estos
dependen que sean desarrollados exclusivamente para este tipo de entornos, empleado
un lenguaje de programación, librerías, y otros conjuntos de herramientas para la
construcción de estas aplicaciones.
El empleo de los estándares y tecnologías para construir aplicaciones web progresivas

que combinan lo mejor en experiencia en la Web y lo mejor de las apps nativas permite
realizar aplicaciones más amigables para el usuario final. Este tipo de aplicaciones
permite estar disponibles para los usuarios a través de la instalación en el dispositivo
móvil. A medida que el usuario compila progresivamente una relación con la aplicación
con el paso del tiempo, se hace más y más poderosa. Se carga rápidamente, incluso
con redes débiles, envía notificaciones push relevantes, tiene un ícono en la pantalla
principal y se carga como experiencia de pantalla completa y de primer nivel.
El enfoque que se empleará para la construcción de la aplicación web progresiva será

mediante la librería Angular. Esto es debido al enfoque practico y fácil que tiene esta
librería, y también las herramientas que provee para construir la aplicación.
Se abordará los siguientes subtemas para la construcción de la aplicación:
• Fundamentos de una aplicación web progresiva.

• Construir una aplicación web progresiva con angular.
• Uso de herramientas de auditoria para la optimización de una aplicación web
progresiva.
• Aplicación de un caso de estudio.
9
El resultado de la siguiente monografía ayudará a las personas interesadas a
comprender conceptos, como construir aplicaciones web progresivas, como auditar una
aplicación para comprobar si cumplimos con los requerimientos de una aplicación web
progresiva y como emplear Angular para este tipo de aplicaciones.
10
1. Generalidades
1.1. Antecedentes Generales
Vivimos en una era digital de muchos cambios, tenemos nuevas tecnologías de información
y comunicación. Las páginas web ahora existentes proveen de servicios a sus usuarios para
realizar cualquier tipo de trabajo. Con el boom de los dispositivos móviles, muchos usuarios
acceden a las aplicaciones web a través de estos, y esperan tener la mejor experiencia en
cuanto a: las imágenes, el contenido, tablas, gráficos, los botones y otras opciones que se
puedan ver de manera adecuada y sean lo más parecido a una aplicación nativa.
1.2. Antecedentes Específicos
Con el propósito de ofrecer mejores experiencias de las aplicaciones web en un entorno

móvil, tarea por supuesto urgente y necesaria porque estos representan un gran porcentaje
de los usuarios finales de una aplicación. Esto significa que se realizara un estudio acerca
de cómo podemos mejorar una aplicación web, aplicando los principios, conceptos y
tecnologías que una aplicación web progresiva establece.
La aplicación web progresiva que se desarrollará, usará la librería Angular debido a que
este provee de servicios, componentes y herramientas para el desarrollo de aplicaciones de
manera más rápida.
2. Metodología
Para el presente trabajo se utilizarán los siguientes métodos de investigación:

Método Bibliográfico, debido a que se realizará la lectura y compilación de libros, páginas web
oficiales relacionadas al tema de estudio.
Método Analítico, debido a que se procederá a revisar y analizar ordenadamente documentos
relacionados al tema de estudio, para la redacción del presente trabajo.
Método Empírico o de Campo, debido a que se utilizará un ejemplo de aplicación observadas
en el caso de estudio como construir aplicaciones web progresivas con Angular.
11
3. Aplicaciones web progresivas
Para la construcción de una aplicación web progresiva es necesario el estudio de los conceptos,
fundamentos y tecnologías sobre las aplicaciones web progresivas.
3.1. Definición
Como lo definió Google en su Web, las Progressive Web Apps (PWA) son “experiencias que
combinan lo mejor de la Web y lo mejor de las apps”. Están disponibles para los usuarios a
partir de la primera visita en una pestaña del navegador y no requieren instalación. A
medida que el usuario genera progresivamente una relación con la aplicación con el paso
del tiempo, ésta se hace más y más poderosa. Se carga rápidamente, incluso con redes
débiles, envía notificaciones push relevantes, tiene un ícono en la pantalla principal y se
carga como experiencia de pantalla completa y de primer nivel”. (Google, Progressive Web
Apps ILT - Concepts, s.f.).
3.1.1. Características de una aplicación web progresiva
Las aplicaciones web progresivas tienen las siguientes características

• Fiable - Carga instantáneamente y nunca muestre el downasaur, incluso en
condiciones de red inciertas.
• Rápido - Responde rápidamente a las interacciones del usuario con animaciones
suaves y sin necesidad de desplazarse con la barra Scroll.
• Atractivo - Como una aplicación natural en el dispositivo, con una experiencia de
usuario inmersiva.
Este nuevo nivel de calidad, permite que las aplicaciones web progresivas ganen un
lugar en la pantalla de inicio del usuario.
3.1.2. Fiables
Cuando se inician desde la pantalla de inicio del usuario, los “Service Workers” permiten
que una aplicación web progresiva se cargue instantáneamente, independientemente del
estado de la red.
Un Service Worker, escrito en JavaScript, es como un proxy del lado del cliente y
permite controlar el caché y cómo responder a las solicitudes de recursos. Por el
12
precaching de los recursos clave puede eliminar la dependencia de la red, lo que
garantiza una experiencia instantánea y confiable para sus usuarios.
3.1.3. Veloces
Se conoce que un 53% de los usuarios abandonará un sitio si tarda más de 3 segundos
en cargar y una vez que se carga, los usuarios esperan que sean rápidos, sin necesidad
de desplazamiento lento o interfaces lentas para responder. (Google, Progressive Web
Apps, s.f.)
3.1.4. Atractivas
Las aplicaciones web progresivas son instalables y viven en la pantalla de inicio del
usuario, sin la necesidad de una tienda de aplicaciones. Ofrecen una experiencia
inmersiva de pantalla completa, con la ayuda de un archivo de manifiesto de aplicación
web e incluso pueden volver a atraer a los usuarios con notificaciones push web.
El Manifiesto de la aplicación web permite controlar cómo aparece su aplicación y cómo

se lanza. Puede especificar los iconos de la pantalla de inicio, la página que se cargará
cuando se inicie la aplicación, la orientación de la pantalla e incluso si se mostrará o no
en el navegador Chrome.
3.2. Tecnologías que aprovecha las aplicaciones web progresivas
3.2.1. Diseño Responsivo
El término “responsive web design” fue acuñado por Ethan Marcotte. En su artículo
seminal de List Apart (Marcotte, 2010), consolidó tres técnicas existentes (diseño de
cuadrícula flexible, imágenes flexibles y consultas de medios y medios) en un enfoque
unificado y lo llamó diseño web receptivo. El término se usa a menudo para inferir el
mismo significado que una serie de otras descripciones tales como diseño de fluidos,
diseño elástico, diseño de líquidos, diseño adaptativo, diseño de dispositivos cruzados y
diseño flexible.
Sin embargo, como el Sr. Marcotte y otros han argumentado elocuentemente, una
metodología verdaderamente receptiva es en realidad más que simplemente alterar el
diseño de un sitio basado en tamaños de ventanas. En cambio, es invertir todo nuestro
enfoque actual para el diseño web. En lugar de comenzar con un diseño de sitio de
escritorio de ancho fijo y escalarlo y volver a fluir el contenido para ventanas pequeñas,
13
primero se debe diseñar para la ventana gráfica más pequeña y luego mejorar
progresivamente el diseño y el contenido para las ventanas más grandes. (Frain, 2012)
3.2.1.1. Enfoque en diseño responsivo
Un diseño web responsivo manejará el flujo del contenido de una página a medida
que las ventanas gráficas cambien, pero veamos más allá. HTML5 ofrece más que
HTML 4 y sus elementos semánticos más significativos formarán la base de nuestro
marcado. Las consultas de medios de CSS3 son un ingrediente esencial para un
diseño receptivo, pero los módulos CSS3 adicionales permiten niveles de flexibilidad
nunca antes vistos. Abandonaremos franjas de gráficos de fondo y JavaScript
complicado, reemplazándolos con degradados, sombras, tipografía, animaciones y
transformaciones de CSS3. Antes de seguir con la creación de un diseño web
impulsado por HTML5 y CSS3.
3.2.2. Service Worker
Los Service Worker son trabajadores scripts que se ejecutan en segundo plano. Escrito
en JavaScript con unas pocas líneas de código, permiten a un desarrollador interceptar
las solicitudes de red, manejar mensajes push y realizar muchas otras tareas.
Lo mejor de todo, si el navegador de un usuario no es compatible con los trabajadores
del servicio, retrocede y su sitio web funciona como un sitio web normal. (Hume, 2018)
La razón por el cual el API de un Service Worker es tan emocionante es porque permite
soportar experiencias fuera de línea, otorgando a los desarrolladores control total sobre
la experiencia.
Antes del Service Worker, existía otra API que proporcionaba a los usuarios una
experiencia fuera de línea en la web llamada AppCache. Pero hay una serie de
problemas con la API AppCache que los Service Worker fueron diseñados para evitar.
Los aspectos que se debe tener en cuenta sobre un trabajador de servicios son:
• Es un trabajador de JavaScript, por lo que no puede acceder al DOM
directamente. En cambio, un Service Worker puede comunicarse con las páginas
que controla, al responder a los mensajes enviados a través de la interfaz
postMessage, y esas páginas pueden manipular el DOM si es necesario.
14
• El Service Worker es un proxy de red programable que permite controlar cómo se
manejan las solicitudes de red desde su página.
• Finaliza cuando no se usa y se reinicia cuando es necesario, por lo que no se
puede confiar en el estado global de los encargados de onfetch y onmessage de
un Service Worker. Si hay información que necesita persistir y reutilizar durante
reinicios, los trabajadores del servicio tienen acceso a la API IndexedDB.
• Los Service Worker hacen un uso extenso de las promesas en JavaScript.
3.2.2.1. Ciclo de vida de un Service Worker
Un Service Worker tiene un ciclo de vida completamente separado de su página web.

Para instalar un Service Worker en un sitio, debe ser registrado, lo cual debe hacer
en el JavaScript de la página. El registro de un Service Worker hará que el navegador
inicie el paso de instalación en segundo plano.
Normalmente, durante el paso de instalación, se almacenan en caché algunos

recursos estáticos. Si todos los archivos se guardan en la memoria caché, entonces
el trabajador del servicio se instala. Si alguno de los archivos no se descarga y
almacena en caché, el paso de instalación fallará y el Service Worker no se activará
(es decir, no se instalará). Si esto sucede, lo intentará de nuevo la próxima vez. Pero
eso significa que, si se instala, sabrá que tiene esos recursos estáticos en el caché.
Cuando este se instala, el paso de activación seguirá y puede gestionar cualquier
contenido en él cache.
Después del paso de activación, el Service Worker controlará todas las páginas que
estén dentro de su alcance, aunque la página que registró al trabajador del servicio
por primera vez no se controlará hasta que se cargue de nuevo. Una vez que un
Service Worker tiene el control, estará en uno de dos estados: el Service Worker
finalizará para ahorrar memoria o manejará eventos de búsqueda y mensajes que
ocurran cuando se realice una solicitud de red o un mensaje desde su página.
A continuación, se muestra una versión demasiado simplificada del ciclo de vida del
Service Worker en su primera instalación.
15
Figura 1 Ciclo de vida de un Service Worker
Fuente: (Hume, 2018)
3.2.2.2. Requisitos
Los requerimientos necesarios para correr aplicaciones progresivas son:

• Navegador - Las opciones del navegador están creciendo. Los trabajadores del
servicio son compatibles con Chrome, Firefox y Opera. Microsoft Edge ahora
muestra soporte público y Safari.
• HTTPS - Durante el desarrollo, podrá usar el Service Worker a través de
localhost, pero para implementarlo en un sitio, deberá tener la configuración de
HTTPS en su servidor.
16
3.2.2.3. Registro de un Service Worker
Para instalar un Service Worker, debe iniciar el proceso registrando este en la página.
Esto le dice al navegador dónde vive su archivo JavaScript de Service Worker.
Figura 2 Registro de un Service Worker.

Fuente: Elaboración Propia.
Este código verifica si la API de trabajador de servicio está disponible, y si lo está, el

Service Worker en /sw.js se registra una vez que se carga la página.
Una sutilidad con el método register() es la ubicación del archivo de Service Worker. En
este caso, se nota que el archivo del trabajador del servicio está en la raíz del dominio.
Esto significa que el alcance del Service Worker será el origen completo. En otras
palabras, este trabajador de servicio recibirá eventos de búsqueda para todo en este
dominio. Si se registra el archivo del Service Worker en /example/sw.js, entonces el
Service Worker solo observara los eventos de búsqueda para las páginas cuyo URL
comience con /example/.
3.2.2.4. Instalar un Service Worker
Después de que una página controlada inicie el proceso de registro, cambiemos al

punto de vista de la secuencia de comandos del trabajador de servicio, que maneja el
evento de instalación.
17
Para el ejemplo más básico, se debe definir callback para el evento de instalación y
decidir qué archivos desea almacenar en caché.
Dentro del callback de instalación, se debe seguir los siguientes pasos:
1. Abre un caché.
2. Guarda en caché los archivos.
3. Confirme si todos los activos requeridos están en la memoria caché o no.
Figura 3 Registro de recursos en caché con un Service Worker.

Fuente: Elaboración propia.
Si todos los archivos se almacenan en la memoria caché, se instalará Service Worker. Si

alguno de los archivos no se descarga, el paso de instalación fallará. Esto permite contar
con todos los recursos que se definió, pero significa que debe tener cuidado con la lista
de archivos que decide almacenar en caché en el paso de instalación. La definición de
una larga lista de archivos aumentará; las posibilidades de que un archivo falle en la
caché, lo que hará que el Service Worker no se instale.
18
3.2.2.5. Cacheo y retorno de peticiones
Después de que se instala un Service Worker y el usuario navega a una página

diferente o se actualiza, el Service Worker comenzará a recibir eventos de búsqueda,
un ejemplo de los cuales se encuentra a continuación.
Figura 4 Agregar un Listener para cacheo y retorno de peticiones.

Este método examina la solicitud y encuentra los resultados en caché de cualquiera

de los cachés creados por el Service Worker.
Si se tiene una respuesta coincidente, se devuelve el valor almacenado en caché, de

lo contrario se devuelve el resultado de una llamada a recuperar, lo que hará una
solicitud de red y devolverá los datos si se puede recuperar algo de la red. Este es un
ejemplo simple y utiliza todos los activos almacenados en memoria caché durante el
paso de instalación.
Si se quiere almacenar en caché nuevas solicitudes acumulativamente, se lo puede

realizar manejando la respuesta de la solicitud de búsqueda y luego agregarla a la
memoria caché.
19
3.2.2.6. Actualización del Service Worker
Habrá un momento en el que el Service Worker necesitará una actualización. Cuando

llegue ese momento, deberá seguir estos pasos:
1. Actualice el archivo JavaScript de Service Worker. Cuando el usuario navega

hacia su sitio, el navegador intenta volver a descargar el archivo de script que
definió al Service Worker en segundo plano. Si hay incluso una diferencia de
bytes en el archivo del Service Worker en comparación con lo que tiene
actualmente, lo considera nuevo.
2. Se iniciará su nuevo Service Worker y se desencadenará el evento de

instalación.
3. En este punto, el Service Worker anterior todavía está controlando las páginas
actuales, por lo que el nuevo Service Worker entrará en estado de espera.
4. Cuando se cierren las páginas actualmente abiertas del sitio, se matará al

antiguo Service Worker y el Service Worker tomará el control.
5. Una vez que el nuevo Service Worker tome el control, se activará el evento de
activación.
Una tarea común que se producirá en la devolución de llamada activada es la

administración del caché. La razón es porque si se borrara cualquier memoria caché
antigua en el paso de instalación, cualquier Service Worker anterior, que tenga el
control de todas las páginas actuales, dejará de servir repentinamente los archivos de
ese caché.
3.2.3. El modelo de App Shell
El Shell de la aplicación es solo el mínimo de UI que necesita para mostrar algo al

usuario. Eso podría ser una barra de navegación, un menú, algunas pestañas, lo que
sea. Es importante que el usuario no mire fijamente una pantalla blanca en blanco para
preguntar si realmente desea esperar a que su aplicación termine de cargarse. Una vez
que este esqueleto de la aplicación esté visible, puede incorporar su contenido dinámico.
20
La parte de arquitectura aparece cuando es momento de decidir cómo va a separar el
contenido estático (el App Shell) de su contenido dinámico. (Sheppard, 2017)
Para aplicaciones de una sola página con arquitecturas con mucho código JavaScript,
una App Shell es un enfoque acertado. Este enfoque se basa en almacenar la Shell
agresivamente en caché (utilizando un Service Worker para lograr que la aplicación
funcione. El contenido dinámico carga cada página a través de JavaScript.
Figura 5 Definición de las diferentes secciones de una aplicación.

Fuente: (Sheppard, 2017)
21
3.2.3.1. Beneficios
Algunos de los beneficios de una arquitectura de App Shell con un Service Worker:
• Rendimiento confiable y rápido en todo momento. Las visitas repetidas son

extremadamente rápidas. Los recursos estáticos y la IU (p. ej. HTML, JavaScript,
imágenes y CSS) se almacenan en caché en la primera visita, y luego se cargan
instantáneamente en las visitas repetidas. El contenido se puede almacenar en
caché en la primera visita, pero generalmente se carga cuando se necesita.
• Interacciones similares a las aplicaciones nativas. Al adoptar un modelo de App
Shell, se puede crear experiencias con navegación e interacciones similares a las
aplicaciones nativas, completas con soporte sin conexión.
• Uso económico de datos. Diseño para hacer un uso de datos mínimo y es
criterioso en lo que almacena en caché, ya que guardar archivos que no son
esenciales (imágenes grandes que no se muestran en todas las páginas, por
ejemplo) provocará que los navegadores descarguen más datos de lo
estrictamente necesario. Aunque los datos son relativamente económicos en los
países occidentales, no es el caso de los mercados emergentes en donde la
conectividad y los datos son costosos.
3.2.3.2. Requisitos
La aplicación idealmente deberá:
• Cargarse rápidamente.
• Usar la menor cantidad de datos posible
• Usar recursos estáticos de una caché local
• Separar contenido de la navegación.
• Recuperar y mostrar contenido específico de la página (HTML, JSON, etc.)
• Opcionalmente, almacenar en caché contenido dinámico
3.2.3.3. Compilar una App Shell
Estructura la aplicación para una distinción clara entre la App Shell de la página y el
contenido dinámico. En general, la aplicación debe cargar la Shell más simple
posible, pero debe incluir contenido de página significativo con la descarga inicial. En
22
este punto es necesario determinar el balance correcto entre velocidad y
actualización de datos para cada fuente de datos.
Figura 6 Ejemplo de una aplicación con Shell definida.

3.2.4. Manifiesto de la aplicación
El manifiesto de las apps web es un archivo JSON que proporciona a los desarrolladores
un lugar centralizado para colocar los metadatos asociados a una aplicación web. Estos
metadatos incluyen, entre otros, el nombre de la aplicación web, los enlaces a íconos,
así como la URL preferida para abrir cuando un usuario inicia la aplicación web. El
manifiesto también permite a los desarrolladores declarar una orientación
predeterminada para su aplicación web, así como proporcionar la capacidad de
establecer el modo de visualización para la aplicación (por ejemplo, en pantalla
completa). Además, el manifiesto permite a un desarrollador alcanzar una aplicación
23
web a una URL. Esto restringe las URL a las que se aplica el manifies to y proporciona
un medio para enlace profundo en una aplicación web desde otras aplicaciones. (Ater,
2017)
Al usar estos metadatos, los agentes de usuario pueden proporcionar a los

desarrolladores medios para crear experiencias de usuario que sean más comparables a
las de una aplicación nativa.
Se puede dar al manifiesto el nombre que se desee. La mayoría de la gente

usa manifest.json. A continuación, se muestra un ejemplo:
Figura 7 Ejemplo de archivo manifest.json.

24
Los manifiestos de las aplicaciones web permiten guardar un marcador de sitio en la
pantalla de inicio de un dispositivo. Cuando un sitio se inicia de esta manera:
• Tiene un ícono y un nombre únicos para que los usuarios puedan diferenciarlo de
otros sitios.
• Muestra algo al usuario mientras se descargan los recursos o se restauran a
partir del caché.
• Proporciona características predeterminadas de visualización al navegador para
evitar una transición demasiado brusca cuando los recursos del sitio se
encuentren disponibles.
25
4. Aplicación web progresiva con Angular
Para la construcción de una aplicación web progresiva con Angular es necesario el estudio de
los fundamentos y arquitectura de una aplicación con esta librería.
4.1. Definición
Angular es una plataforma que facilita la creación de aplicaciones con la web. Angular
combina plantillas declarativas, inyección de dependencia, herramientas de extremo a
extremo y mejores prácticas integradas para resolver los desafíos de desarrollo. Angular
permite a los desarrolladores crear aplicaciones que se ejecutan en la web, el dispositivo
móvil o el escritorio. (Google, Angular Documentation, s.f.)
4.2. Fundamentos
4.2.1. Arquitectura
Los bloques de construcción básicos de una aplicación Angular son NgModules, que
proporcionan un contexto de compilación para los componentes. NgModules recopilan
código relacionado en conjuntos funcionales; una aplicación Angular está definida por un
conjunto de NgModules. Una aplicación siempre tiene al menos un módulo raíz que
habilita el arranque, y generalmente tiene muchos más módulos de características.
Los componentes definen vistas, que son conjuntos de elementos de pantalla que
Angular puede elegir y modificar según la lógica y los datos de su programa.
Los componentes usan servicios que proporcionan una funcionalidad específica que no
está directamente relacionada con las vistas. Los proveedores de servicios pueden
inyectarse en componentes como dependencias, haciendo que el código sea modular,
reutilizable y eficiente.
Tanto los componentes como los servicios son simplemente clases, con decoradores
que marcan su tipo y proporcionan metadatos que le dicen a Angular cómo usarlos.
Los metadatos de una clase de componente lo asocian con una plantilla que define una
vista. Una plantilla combina HTML común con directivas angulares y marcado de enlace
que permiten a Angular modificar el HTML antes de representarlo para su visualización.
26
Los metadatos de una clase de servicio proporcionan la información que Angular
necesita para ponerla a disposición de los componentes a través de la inyección de
dependencia (DI).
Los componentes de una aplicación generalmente definen muchas vistas, organizadas

jerárquicamente. Angular proporciona el servicio Router para ayudarlo a definir rutas de
navegación entre vistas. El enrutador proporciona sofisticadas capacidades de
navegación en el navegador.
Figura 8 Arquitectura de una aplicación Angular.

Fuente: (Google, Angular Documentation, s.f.)
A continuación, se desglosaron más los conceptos para los componentes principales de

una aplicación angular.
4.2.2. Módulos
Las aplicaciones son modulares y Angular tiene su propio sistema de modularidad

llamado NgModules. Los NgModules son contenedores para un bloque cohesivo de
código dedicado a un dominio de aplicación, un flujo de trabajo o un conjunto de
capacidades estrechamente relacionadas. Pueden contener componentes, proveedores
27
de servicios y otros archivos de código cuyo alcance está definido por el NgModule que
lo contiene. Pueden importar funcionalidad que se exporta desde otros NgModules y
exportar la funcionalidad seleccionada para que otros NgModules puedan utilizarla.
(Google, Angular Documentation, s.f.)
4.2.3. Componentes y plantillas
Una de las grandes ideas detrás de Angular es la idea de los componentes. En las
aplicaciones con angular, se escribe el marcado HTML que se convierte en la aplicación
interactiva, pero el navegador solo entiende un conjunto limitado de etiquetas de
marcado; Complementos como <select> o <form> o <video> tienen funcionalidad
definida por el creador de navegador. ¿Qué pasa si se quiere registrar las nuevas
etiquetas del navegador? ¿Qué pasaría si se quisiera tener una etiqueta <weather> que
muestre el clima? ¿O qué pasa si se quiere crear una etiqueta <login> que muestre un
panel de inicio de sesión? Esta es la idea fundamental detrás de los componentes:
mostrar al navegador nuevas etiquetas que tienen funcionalidad personalizada adjunta a
ellas. (Nate Murray, pág. 12)
Un componente controla una parte de pantalla llamado vista, este es conocido como la
plantilla de un componente.
4.2.4. Formularios
Los formularios son probablemente el aspecto más importante de una aplicación web.
Aunque a menudo se obtiene eventos de clicks en enlaces o moviendo el mouse, es a
través de los formularios que se obtiene la mayor parte de entrada de datos de los
usuarios.
Resulta que los formularios pueden ser muy complejas. Aquí hay algunas razones por
las cuales:
• Las entradas de formulario están destinadas a modificar datos, tanto en la página
como en el servidor.
• Los cambios a menudo deben reflejarse en otra parte de la página
• Los usuarios tienen mucha libertad de acción en lo que ingresan, por lo es
necesario validar.
• La UI necesita establecer claramente las expectativas y los errores, si los hay.
• Los campos dependientes pueden tener una lógica compleja.
• Poder probar los formularios, sin depender de los selectores de DOM.
28
Afortunadamente, Angular tiene herramientas para ayudar con todas estas cosas.
• FormControls - Las entradas en los formularios y dar objetos para trabajar con
ellos.
• Validators - Dan la posibilidad de validar las entradas, de la manera que se
quiera.
• Observers – Permite que los formularios puedan ver cambios y responda en
consecuencia. (Murray, Coury, Lerner, & Taborda, 2018)
4.2.5. Enrutamiento y Navegación
En el desarrollo web, el enrutamiento significa dividir la aplicación en diferentes áreas

generalmente basadas en reglas que se derivan de la URL actual en el navegador. Por
ejemplo, si visita el /inicio de un sitio web, se estará visitando la ruta del hogar de ese
sitio web o si se visita /acerca si quiere mostrar la "página acerca", y así sucesivamente.
La definición de rutas en una aplicación es útil porque podemos:

• Separar diferentes áreas de la aplicación
• Mantener el estado en la aplicación
• Proteger áreas de la aplicación en función de ciertas reglas
En Angular se configura las rutas por mapeo de rutas al componente que las manejará.
Hay tres componentes principales que se utiliza para configurar el enrutamiento en
Angular:
• Routes - Describe las rutas compatibles con la aplicación.
• RouterOutlet - Es un componente "marcador de posición" que muestra Angular
dónde ubicar el contenido de cada ruta
• RouterLink - Directiva que se usa para enlazar las rutas.
4.2.6. Agregar App Shell
Una arquitectura de App Shell es una forma de crear una aplicación web progresiva que
se carga al instante y de manera confiable en la pantalla de un usuario, en forma similar
a lo que se ve en las aplicaciones nativas. La arquitectura que una App Shell puede
tener son:
29
4.2.6.1. Cargador
El ejemplo más común de App Shell es el cargador (o spinner), que es visible para los
usuarios hasta que la aplicación y los datos estén listos.
4.2.6.2. Cabecera
Es necesario agregar una cabecera (o header) en una aplicación, para ello es

necesario usar hojas de estilos y definir un componente.
4.2.7. Agregar el manifiesto a una aplicación Angular.
El manifiesto es un archivo dentro de una aplicación que proporciona cierta información

descriptiva. Se agregará este archivo en la raíz de la aplicación Angular.
Este debe contener como mínimo este contenido:
30
Figura 9 Ejemplo de un manifiesto en una aplicación Angular.
También edita el archivo .angular-cli.json y agrega el manifiesto en la sección de

“assets”:
31
Figura 10 Agregar un manifiesto en una aplicación Angular.
Como puede ver en la configuración, se debe incluir iconos de diferentes tamaños para
el proyecto es necesario encontrar los tamaños indicados en el manifiesto. Es importante
el uso .png para los iconos de una aplicación.
Es necesario agregar al index.html la siguiente la siguiente definición:
Figura 11 Agregar referencias de un manifiesto en el index.html en una aplicación Angular.

Con esto la aplicación va incluir el archivo manifiesto.
4.2.8. Agregar Service Worker
Afortunadamente, el equipo de Angular hizo un gran trabajo para nosotros y brindó un

script sw listo, que se puede instalar en una sola línea:
32
Figura 12 Comando para agregar librerías para service worker en una aplicación Angular.
También se necesita un archivo de configuración de ngsw que tenga el siguiente

contenido:
Figura 13 Definición de un archivo ngsw-config.json para una aplicación Angular.

33
Ahora es necesario habilitar Service Worker en el proyecto en el archivo .angular-
cli.json.
Figura 14 Habilitar Service Worker en una aplicación Angular.

Para registrar Service Worker en una aplicación angular, es necesario agregar la

siguiente línea en el app.module.ts
Figura 15 Agregar el módulo Service Worker en una aplicación Angular.

34
Ahora es necesario hacer el build de la aplicación. Es muy importante usar la bandera
prod.
Figura 16 Comando para hacer build de una aplicación Angular con Service Worker.
Los pasos anteriores son obligatorios y en la mayoría de los casos redundantes, porque
la CLI angular puede hacer todo el trabajo para el paso de compilación.
Cuando iniciamos una aplicación angular desde cero se puede usar este flag al
momento de generar el proyecto.
Figura 17 Comando para crear una aplicación Angular como aplicación web progresiva.
Este indicador instalará el módulo sw npm, activará sw.angular-cli.json, registrará sw

para la aplicación y generará el archivo de configuración ngsw con algunos valores
predeterminados.
35
5. Uso de herramientas para la auditoria de una aplicación web progresiva
Para la auditoria y optimización de una aplicación web progresiva, es necesario la aplicación de

las características y tecnologías que una aplicación web progresiva requiere. Lighthouse es una
herramienta que puede emplearse para la auditoría.
5.1. Lista de verificación para una aplicación web progresiva
Las aplicaciones web progresivas (PWA) son confiables, rápidas y atractivas, aunque hay
muchas cosas que pueden llevar a una PWA desde una experiencia inicial a una
experiencia ejemplar.
Para ayudar a los equipos a crear las mejores experiencias posibles, se ha preparado una
lista de verificación que analiza todas las cosas que se consideran necesarias para ser una
aplicación web progresiva base.
5.1.1. Lista base de verificación
5.1.1.1. El sitio es servido a través de HTTPS
➢ Prueba - Usa Lighthouse para verificar que la aplicación corre sobre HTTPS.
➢ Solución - Implemente HTTPS y revise “letsencrypt.org” para iniciar.
5.1.1.2. Las páginas responden en dispositivos móviles
➢ Prueba -
• Use Lighthouse para verificar sí todos los diseños son aptos para
dispositivos móviles, aunque la verificación manual también puede ser
útil.
• Revise la prueba amigable móvil
➢ Solución - Considere la implementación de un diseño receptivo o la
prestación adaptativa de un sitio compatible con las vistas.
5.1.1.3. Todas las URL de las aplicaciones se cargan sin conexión
➢ Prueba - Cargue varias páginas en el PWA con un modo de avión habilitado.

Asegúrese que la aplicación presente algo de contenido incluso cuando no
esté conectado. Use Lighthouse para verificar que la URL de inicio responde
con un 200 cuando está desconectado.
➢ Solución - Utilice un Service Worker.
36
5.1.1.4. Metadatos proporcionados para agregar home screen
➢ Prueba - Use Lighthouse para verificar si el usuario tiene acceso para agregar
la aplicación al home screen.
➢ Solución - Agregue un archivo de manifiesto de aplicación web a su proyecto.
5.1.1.5. Primera carga rápida incluso en 3G
➢ Prueba - Use Lighthouse en un Nexus 5 (o similar) para verificar el tiempo a

interactivos <10s para la primera visita en una red 3G simulada.
➢ Solución -
• Hay muchas maneras de mejorar el rendimiento.
• Puede comprender mejor su rendimiento usando PagesPeed Insights
(objetivo de puntaje> 85) y SpeedIndex en WebPageTest (objetivo de
<4000 primera vista en Mobile 3G Nexus 5 Chrome)
• Algunos consejos son centrarse en cargar menos scripts, asegurar de
que la mayor cantidad de scripts se cargue de forma asíncrona con el
uso posible <script async> y asegurar de que el bloqueo del
procesamiento de CSS esté marcado.
• También puede considerar el uso del patrón PRPL y herramientas
como PageSpeed Module en el servidor.
5.1.1.6. El sitio funciona navegador cruzado
➢ Prueba - Sitio de prueba en Chrome, Edge, Firefox y Safari.

➢ Solución - Solucionar los problemas que se producen al ejecutar la aplicación
en el navegador.
5.1.1.7. Las transiciones de página deben ser rápidas
Las transiciones deben sentirse rápidas mientras toca, incluso en una red lenta, una clave
para percibir el rendimiento.
➢ Prueba – Se debe probar la aplicación en una red muy lenta simulada. Cada
vez que se toca un enlace / botón en la aplicación, la página debe responder
de inmediato, ya sea por:
• Pase de inmediato a la siguiente pantalla y muestre una pantalla de
carga de marcador de posición mientras espera contenido de la red.
37
• Se muestra un indicador de carga mientras la aplicación espera una
respuesta de la red.
➢ Solución - Si usa una aplicación de una sola página (cliente renderizado),
realice la transición del usuario a la página siguiente inmediatamente muestre
una pantalla de esqueleto y use cualquier contenido, como el título o la
miniatura, ya disponible mientras se carga el contenido.
5.1.1.8. Cada página tiene una URL
➢ Prueba - Asegúrese de que las páginas individuales se puedan vincular a

través de las URL y que las URL sean únicas con el fin de compartirlas en las
redes sociales mediante la prueba con páginas individuales que se pueden
abrir y acceder directamente a través de las nuevas ventanas del navegador.
➢ Solución - Si crea una aplicación de una sola página, asegúrese de que el
enrutador del lado del cliente pueda reconstruir el estado de la aplicación
desde una URL determinada.
5.2. Auditar aplicaciones web con Lighthouse
Lighthouse es una herramienta automatizada de código abierto diseñada para mejorar la

calidad de las apps web. Se puede ejecutar como una extensión de Chrome o desde la
línea de comandos. Se proporciona a Lighthouse una URL que se quiere auditar,
Lighthouse ejecuta una serie de pruebas contra la página, y luego genera un informe sobre
el rendimiento de la página. A partir de aquí, se puede usar las pruebas desaprobadas como
indicadores de lo que se puede hacer para mejorar una aplicación.
Lighthouse prueba si una aplicación:
• Puede cargarse en condiciones de red fuera de línea o escasa.

• Es relativamente rápido
• Se sirve desde un origen seguro
• Utiliza ciertas mejores prácticas de accesibilidad
Lighthouse está disponible como una extensión de Chrome para Chrome 52 (y posterior) y
una herramienta de línea de comandos.
38
5.2.1. Corre Lighthouse como una extensión Chrome
Descargue la extensión de Lighthouse Chrome desde Chrome Web Store.
Cuando este instalado, coloca un ícono de icono de Faro en la barra de tareas.
Ejecute Lighthouse en la aplicación seleccionando el icono y eligiendo generar informe

(con su aplicación abierta en la página del navegador).
Lighthouse genera una página HTML con los resultados. Una página de ejemplo se
muestra a continuación.
Figura 18 Ejemplo de una auditoría realizada con Lighthouse en una aplicación web.
5.2.2. Lighthouse desde línea de comandos
Se puede ejecutar Lighthouse desde la línea de comando (por ejemplo, para integrarlo
con un proceso de compilación), está disponible como un módulo de nodo.
Puede descargar Node desde nodejs.org (seleccione la versión que mejor se adapte a
su entorno y sistema operativo).
Para instalar el módulo Nodo de Lighthouse desde la línea de comando, se debe usar el
siguiente comando:
npm install -g lighthouse
Esto instala la herramienta globalmente. Luego puede ejecutar Lighthouse desde la línea
de comandos:
39
lighthouse <url>
Puede verificar las banderas y opciones de Lighthouse con el siguiente comando:
lighthouse –help
5.2.3. Registro Service Worker

5.2.3.1. Requerimientos para esta auditoria
El registro de un Service Worker es el primer paso para habilitar las siguientes

funciones de la app web progresiva:
• Sin conexión
• Notificaciones push
• Agregar un home screen
Registrar un Service Worker requiere solo unas pocas líneas de código, pero el único
motivo por el que se usaría un Service Worker sería para implementar una de las
funciones de app web progresiva mencionadas anteriormente. Para implementar
estas funciones, se necesita más trabajo.
5.2.3.2. Implementación de la auditoria
Verifica si el Depurador de Chrome devuelve una versión del Service Worker.
5.2.4. Manifiesto de la aplicación
El manifiesto de la aplicación web es la tecnología web que permite agregar una

aplicación web a la pantalla de inicio de un usuario. A esta función se la suele llamar
"agregar el Home Screen".
5.2.4.1. Como aprobar la auditoria
Es necesario agregar un archivo que contenta la estructura mínima de un

manifest.json
40
Figura 19 Estructura mínima de un archivo manifest.json.
41
6. Aplicación de caso de estudio
Para la construcción y migración de una aplicación angular a una aplicación web progresiva, se
empleó los conceptos que define una aplicación web progresiva, uso de tecnologías para la
agregación de un Service Worker, diseño responsivo, definición de un archivo manifiesto,
herramienta de auditoria y pruebas del uso de la aplicación en un dispositivo móvil.
6.1. Migración de una aplicación Angular
Se hará uso de la aplicación desarrollada en Angular, este contiene toda la lógica

implementa y probada. Ahora este no cumple con los requerimientos necesarios para ser
una aplicación web progresiva, por ello haremos la migración de esta.
6.2. Auditar aplicación con Lighthouse
Se iniciará la auditoria de la aplicación con esta herramienta.

Se presiona en el icono “Lighthouse” botón en opciones se habilita todas las opciones:
Figura 20 Opciones para auditar una aplicación web progresiva con Lighthouse.
Lighthouse permite cuatro opciones para las pruebas, y es recomendable ejecutarlas al

menos por primera vez.
42
Estos son los resultados en el proyecto:
Figura 21 Resultado de la auditoria en la aplicación del caso de estudio.

Los resultados son: cumplimiento en un alto porcentaje para la “accesibilidad” y las “mejores
prácticas”, pero con PWA la aplicación es deficiente.
Afortunadamente, se puede ver los detalles en la siguiente parte con más información que
Lighthouse provee:
Figura 22 Detalles de la auditoria en la aplicación del caso de estudio.

43
Con esos números y la lista generada para corregir, se tiene un punto de inicio.
6.3. Agregar App Shell
Un Shell de aplicación es la interfaz de usuario mínima que el usuario verá lo antes posible.
El Shell de la aplicación debe cargarse muy rápido para captar los ojos del usuario y hacer
que espere todo el contenido.
6.3.1. Cargador
El ejemplo más común de Shell de aplicaciones es loader (o spinner), que es visible para
los usuarios hasta que la aplicación y los datos estén listos.
6.3.2. Cabecera
El proyecto ya contiene la cabecera definida:
Figura 23 Código de la cabecera de la aplicación del caso de estudio.

6.3.3. JS Fallback
Algunas de las advertencias de Lighthouse dicen que: no proporcionan ningún

contenido, si los scripts no están disponibles. Para manejarlo, se puede usar la etiqueta
html <noscript>. Se agrega este en el index.html:
44
Figura 24 Index.html para cuando los scripts no están disponibles.
6.4. Agregar el Manifiesto en la aplicación
Como se muestra en la auditoria, se tiene una advertencia roja que indica que falta el
manifiesto. Se agregará este al proyecto.
45
Figura 25 Manifiesto de la aplicación del caso de estudio.
Abre el archivo .angular-cli.json y agrega manifiesto en la sección de assets/:
Figura 26 Habilitación del manifiesto en la aplicación.

Como puede ver en la configuración, se debe incluir iconos de diferentes tamaños para el
proyecto.
En el archivo index.html, agregue las siguientes etiquetas a la sección principal:
46
Figura 27 Agregando el manifiesto en el archivo index.html.
6.5. Agregar Service Worker
Para agregar Service Worker en la aplicación se necesita algunos archivos JavaScript.

Afortunadamente, el equipo de Angular hizo un gran trabajo y brindó un script Service
Worker listo, que se puede instalar en una sola línea:
npm install @angular/service-worker --save
También se necesita un archivo de configuración de ngsw:
47
Figura 28 Archivo de configuración para el Service Worker de la aplicación.
Entonces, se necesita habilitar el service worker para el proyecto con el archivo .angular-
cli.json:
Figura 29 Habilitación del Service Worker en la aplicación Angular.

48
Ahora es necesario registrar el Service Worker en la aplicación angular, agregue la siguiente
línea al archivo app.module.ts:
Figura 30 Importar el Service Worker en el módulo de la aplicación Angular.

6.6. Uso de la aplicación como aplicación nativa
Para instalar la aplicación en su dispositivo de teléfono a través del navegador Chrome.

Observe la ventana emergente en la parte inferior la opción de agregar icono al home
screen.
Después de presionar el botón agregar la aplicación al home screen, encontrará el ícono de

la aplicación en el espacio libre de la pantalla de inicio.
Y ahora puede usarlo como una aplicación nativa, ya no se necesita un navegador y lo

busca a través de la URL.
Ahora que la aplicación puede correr como una aplicación nativa podemos ver los
resultados comparado con nuestra aplicación web sin usar las tecnologías para las
aplicaciones web progresivas.
49
Figura 31 Aplicación sin el uso de las tecnologías web progresivas.
Fuente: Elaboración propia
Figura 32 Iconos de acceso directo de la aplicación web progresiva como nativas.

50
Figura 33 Aplicación web progresiva en una computadora de escritorio.
Figura 34 Aplicación web progresiva en un dispositivo móvil.

51
Podemos notar que la diferencia de la aplicación es distinta a una aplicación web normal,
porque tenemos accesos directo en los dispositivos, no hacen uso del navegador y corren
como si fueras aplicaciones nativas.
7. Conclusiones
Después de haber concluido con la investigación sobre aplicaciones web progresivas, tomando
en cuenta los fundamentos, conceptos, tecnologías, como auditar este tipo de aplicaciones y
como construir o migrar una aplicación de este tipo. Se puede concluir lo siguiente:
➢ Respecto a los fundamentos sobre una aplicación web progresiva, se ve que estos
disponen de muchas buenas características que se espera en una aplicación; que sean
“fiables”, veloces y atractivas para el usuario. También se ve que este se apoya en
tecnologías existentes como ser Service Worker, diseño responsivo con CSS and HTML,
el uso de cache del navegador y definición de un archivo manifiesto.
➢ Sobre el empleo de Angular para construir aplicaciones web progresivas, se puede
concluir que este reúne varios de los requerimientos que una aplicación web progresiva
necesita, el empleo de librerías para el diseño de los formularios, el uso de servicios
para obtener información, permite el cacheo fácil de estos y también que la librería
dispone de varios comandos para construir una aplicación web progresiva.
➢ Respecto al uso de herramientas para auditar una aplicación web progresiva, si se
cumple con las características y tecnologías; disponemos de una herramienta
Lighthouse. Este es muy útil al momento de construir una aplicación puesto que muestra
a través de métricas el porcentaje que se cumple de los requerimientos necesarios para
una aplicación web progresiva.
➢ Sobre el caso de estudio, se puede comprobar lo fácil que es crear o migrar una
aplicación Angular para que este sea aplicación web progresiva. Se pudo comprobar
que los conceptos que define una aplicación web progresiva son aplicables en una
aplicación Angular, dispone de comandos para agregar el Service Worker, o crear una
aplicación que contenga todo lo necesario para que se pueda iniciar una aplicación
desde cero.
52
Bibliografía
Ater, T. (2017). Building Progressive Web Apps - Bringing the Power of Native to the Browser.
Frain, B. (2012). Responsive Web Design with HTML5 and CSS3. Packt Publishing Ltd.
Hume, D. A. (2018). Progressive Web Apps.
Marcotte, E. (2010). Responsive Web Design. Obtenido de https://alistapart.com:
https://alistapart.com/article/responsive-web-design
Murray, N., Coury, F., Lerner, A., & Taborda, C. (2018). ng-book The Complete Guide to Angular.
Nate Murray, F. C. (s.f.). Making aComponen. En F. C. Nate Murray, ng-book The Complete Guide to
Angular (pág. 12).
Sheppard, D. (2017). Beginning Progressive Web App Development - Creating a Native App Experience on
the Web.
Páginas Web
Google. (s.f.). Obtenido de Progressive Web Apps ILT - Concepts: https://google-developer-

training.gitbooks.io/progressive-web-apps-ilt-concepts/content/
Google. (s.f.). Angular Documentation. Obtenido de angular.io: https://angular.io/docs
Google. (s.f.). Progressive Web Apps. Obtenido de https://developers.google.com:
https://developers.google.com/web/progressive-web-apps/#reliable
53

Como Desarrollar Aplicaciones Web Progresivas Con Angular

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Como Desarrollar Aplicaciones Web Progresivas Con Angular

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

“COMO DESARROLLAR APLICACIONES WEB

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO

POSTULANTE : JULIO CESAR QUISPE SOLIZ

La presente monografía, está centrado en mejorar la experiencia del usuario cuando

Tomando en cuenta la necesidad de mejorar estos aspectos en las aplicaciones web

También se realizó un análisis de experiencia en base a una aplicación web Angular y

Como herramientas de desarrollo primordial se empleó Angular, CSS, librerías

El estado actual de las aplicaciones Web existentes, es el de servicios enfocados a

El empleo de los estándares y tecnologías para construir aplicaciones web progresivas

El enfoque que se empleará para la construcción de la aplicación web progresiva será

• Fundamentos de una aplicación web progresiva.

1.1. Antecedentes Generales

1.2. Antecedentes Específicos

Con el propósito de ofrecer mejores experiencias de las aplicaciones web en un entorno

Para el presente trabajo se utilizarán los siguientes métodos de investigación:

3.1.1. Características de una aplicación web progresiva

Las aplicaciones web progresivas tienen las siguientes características

El Manifiesto de la aplicación web permite controlar cómo aparece su aplicación y cómo

3.2. Tecnologías que aprovecha las aplicaciones web progresivas

3.2.1. Diseño Responsivo

3.2.1.1. Enfoque en diseño responsivo

3.2.2. Service Worker

• Los Service Worker hacen un uso extenso de las promesas en JavaScript.

3.2.2.1. Ciclo de vida de un Service Worker

Un Service Worker tiene un ciclo de vida completamente separado de su página web.

Normalmente, durante el paso de instalación, se almacenan en caché algunos

Los requerimientos necesarios para correr aplicaciones progresivas son:

Figura 2 Registro de un Service Worker.

Este código verifica si la API de trabajador de servicio está disponible, y si lo está, el

3.2.2.4. Instalar un Service Worker

Después de que una página controlada inicie el proceso de registro, cambiemos al

Figura 3 Registro de recursos en caché con un Service Worker.

Si todos los archivos se almacenan en la memoria caché, se instalará Service Worker. Si

Después de que se instala un Service Worker y el usuario navega a una página

Figura 4 Agregar un Listener para cacheo y retorno de peticiones.

Este método examina la solicitud y encuentra los resultados en caché de cualquiera

Si se tiene una respuesta coincidente, se devuelve el valor almacenado en caché, de

Si se quiere almacenar en caché nuevas solicitudes acumulativamente, se lo puede

Habrá un momento en el que el Service Worker necesitará una actualización. Cuando

1. Actualice el archivo JavaScript de Service Worker. Cuando el usuario navega

2. Se iniciará su nuevo Service Worker y se desencadenará el evento de

4. Cuando se cierren las páginas actualmente abiertas del sitio, se matará al

Una tarea común que se producirá en la devolución de llamada activada es la

3.2.3. El modelo de App Shell

El Shell de la aplicación es solo el mínimo de UI que necesita para mostrar algo al

Figura 5 Definición de las diferentes secciones de una aplicación.

• Rendimiento confiable y rápido en todo momento. Las visitas repetidas son

La aplicación idealmente deberá:

3.2.3.3. Compilar una App Shell

Figura 6 Ejemplo de una aplicación con Shell definida.

3.2.4. Manifiesto de la aplicación

Al usar estos metadatos, los agentes de usuario pueden proporcionar a los

Se puede dar al manifiesto el nombre que se desee. La mayoría de la gente

Figura 7 Ejemplo de archivo manifest.json.

Los componentes de una aplicación generalmente definen muchas vistas, organizadas

Figura 8 Arquitectura de una aplicación Angular.

A continuación, se desglosaron más los conceptos para los componentes principales de

Las aplicaciones son modulares y Angular tiene su propio sistema de modularidad

4.2.3. Componentes y plantillas

4.2.5. Enrutamiento y Navegación

En el desarrollo web, el enrutamiento significa dividir la aplicación en diferentes áreas

La definición de rutas en una aplicación es útil porque podemos: