Universidad Politécnica de Madrid - UPMoa.upm.es/64414/1/TFM_JORGE_FORCADA_SANZ.pdf · Frameworks...

Universidad Politécnicade Madrid

Escuela Técnica Superior deIngenieros Informáticos

Máster Universitario en Ingeniería Informática

Trabajo Fin de Máster

Frameworks para Desarrollo deAplicaciones Móviles Híbridas: AnálisisComparativo y Aplicación a Servicios de

Emergencia

Autor(a): Jorge Forcada SanzTutor(a): Francisco Javier Soriano Camino

Madrid, Junio 2020

Agradecimientos

Gracias a mis compañeros de trabajo por todo lo que aprendo de ellos y por ayu-darme con los problemas que me he podido encontrar durante la realización de estetrabajo.

A mi tutor, Francisco Javier Soriano, por haberme dado la oportunidad de realizareste proyecto.

A mi prometida, María Isabel Murillo, por aguantarme todos los días y animarmecuando lo necesito.

A mis amigos y compañeros por estar siempre ahí cuando necesito desconectar.

Y por último, pero no menos importante, a mi familia por estar siempre ahí yapoyarme siempre en todo.

Resumen

En la sociedad tecnológica en la que vivimos actualmente existe una gran cantidadde contenido disponible en internet. Este contenido es muy amplio y puede ofrecersey consumirse de distintas formas. La mayoría de los usuarios están acostumbradosa utilizar internet desde un ordenador o un desde un smartphone.

En los ordenadores se puede utilizar internet mediante programas, mientras queen los smartphones se puede utilizar mediante aplicaciones. Existe un tipo de pro-grama o de aplicación llamado navegador web que permite a los usuarios visualizarpáginas web, que es el modo de utilizar internet al que estamos más acostumbrados.

Cuando se quiere desarrollar un servicio para el mayor número de usuarios posi-ble, se debe intentar que se pueda utilizar dicho servicio en el mayor número posiblede plataformas. Por tanto hay que desarrollar aplicaciones para los smartphones másutilizados (Android e iOS), y para los ordenadores (Windows y MacOS).

Esto normalmente implica tener que desarrollar una aplicación para Android, unaaplicación para iOS y una página web, puesto que cada plataforma tiene sus pecu-liaridades. Además, cada aplicación debería estar escrita en diferentes lenguajes deprogramación, puesto que cada plataforma utiliza lenguajes de programación dife-rentes.

Resulta difícil que un mismo profesional pueda tener el mismo nivel de conoci-miento a la hora de desarrollar una aplicación para cada plataforma, lo que nor-malmente conlleva a tener que tener diferentes personas o diferentes equipos quedesarrollan y dan soporte a la aplicación de cada plataforma.

Las aplicaciones híbridas permiten crear aplicaciones multiplataforma, es decir,que con un mismo código, la aplicación pueda utilizarse en varias plataformas. Estopermite que una sola persona o un solo equipo de desarrollo puedan desarrollar ymantener una única aplicación que se utilice en todas las plataformas. De este modose pueden optimizar los costes y el tiempo de desarrollo de las aplicaciones.

Estas aplicaciones se crean mediante distintos frameworks que utilizan un mismolenguaje para crear la aplicación y exponen la forma de utilizar las características decada plataforma mediante librerías. Después el framework se encarga de compilar laaplicación y crear el paquete de instalación propio de cada plataforma.

A lo largo de este documento se va a realizar un análisis de los frameworks para eldesarrollo de aplicaciones híbridas que existen hoy en día. Además, se va a desarro-llar una aplicación que se podrá desplegar en todas las plataformas utilizando unode estos frameworks para demostrar su utilidad.

i

Abstract

In the technological society in which we live there is a large amount of contentavailable on the internet. This content is very broad and can be offered and consumedin different ways. Most users are used to navigate the internet from a computer orfrom a smartphone.

On computers internet can used through programs, while on smartphones it canused through applications. There is a type of program or application called web brow-ser that allows users to view web pages, which is the way of using the internet thatpeople are most used to.

When you want to develop a service for as many users as possible, you should tryto make that service compatible with as many platforms as possible. Therefore, it isnecessary to develop applications for the most used smartphones (Android and iOS),and for computers (Windows and MacOS).

This normally implies having to develop an Android application, an iOS applicationand a web page, since each platform has its peculiarities. Furthermore, each applica-tion should be written in different programming languages, since each platform usesdifferent programming languages.

It is difficult for the same professional to have the same level of knowledge whendeveloping an application for each platform, which usually entails having to havedifferent people or different teams that develop and support the application of eachplatform.

Hybrid applications allow developer to create cross-platform applications, that is,that with the same code, the application can be used on various platforms. Thisallows a single person or a single development team to develop and maintain a singleapplication that is used on all platforms. In this way the costs and the developmenttime of the applications can be optimized.

These applications are created through different frameworks that use the samelanguage to create the application and expose the way to use the features of eachplatform through libraries. Then the framework is responsible for compiling the ap-plication and creating the installation package for each platform.

Throughout this document, an analysis of the frameworks for the development ofhybrid applications that exist today will be made. In addition, an application thatcan be deployed on all platforms will be developed using one of these frameworks todemonstrate its usefulness.

iii

Índice general

1. Introducción 11.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.1. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.2. Análisis y comparativa de los frameworks . . . . . . . . . . . . . . 41.3.3. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.4. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Estado del arte 52.1. Servicios de emergencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1. Número de emergencias común . . . . . . . . . . . . . . . . . . . . 52.1.2. EENA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.2.1. AML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2.2. NG112 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2.3. PEMEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2. Tecnologías de desarrollo móvil . . . . . . . . . . . . . . . . . . . . . . . . 122.2.1. Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1.1. Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.1.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.2. iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.2.1. Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.2.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3. Tecnologías de desarrollo web . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.1. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.2. CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.3. JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.4. TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.5. NPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.6. JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.7. Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.8. React . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.3.9. Vue.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3.10.WordPress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.4. Protocolos de comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . 312.4.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.4.2. WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

v

ÍNDICE GENERAL

2.4.3. SSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.5. Comunicación en tiempo real . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.5.1. Mensajería Instantánea . . . . . . . . . . . . . . . . . . . . . . . . . 352.5.2. WebRTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.6. Control de versiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.6.1. GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.6.2. GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.6.3. Bitbucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.7. Conocimientos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.8. Conocimientos adquiridos . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3. Análisis y comparativa de los frameworks 413.1. PWA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2. Frameworks de desarrollo de aplicaciones híbridas . . . . . . . . . . . . . 42

3.2.1. Ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2.2. React Native . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2.3. Flutter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.3. Comparativa de funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . 463.4. Comparativa de rendimientos . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.4.1. Tiempo de compilación e instalación . . . . . . . . . . . . . . . . . 583.4.2. Live reload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4. Diseño 634.1. Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.1.1. Especificación de requisitos . . . . . . . . . . . . . . . . . . . . . . 644.2. Elección del framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.3. Diseño de la arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5. Desarrollo 695.1. Estado actual de GHALE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.1.1. Estado actual del protocolo . . . . . . . . . . . . . . . . . . . . . . . 695.1.1.1. Establecimiento de la llamada . . . . . . . . . . . . . . . . 695.1.1.2. Capacidades avanzadas . . . . . . . . . . . . . . . . . . . . 71

5.2. Desarrollo de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.2.1. Versión móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.2.2. Versión web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6. Conclusiones 876.1. Conclusiones técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.2. Conclusiones personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.3. Líneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Bibliografía 96

vi

Índice de figuras

1. Logo del 112 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52. Logo de EENA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63. Implementación de AML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74. Logo de PEMEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85. Arquitectura de PEMEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106. PEMEA Fase I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117. Cuota de mercado por sistema operativo móvil en todo el mundo . . . . 128. Logo de Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139. Versiones de Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1410. Logo de Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1511. Logo de Kotlin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1512. Logo de Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1613. Logo de Gradle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1714. Logo de Apple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1815. Lenguajes para iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1916. Logo de Xcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2017. Logo de TestFlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2118. Logo de HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2219. Logo de CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2320. Logo de JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2321. Logo de NPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2422. Logo de JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2523. Objeto JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2624. Matriz JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2625. Valor JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2626. String JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2727. Número JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2828. Espacios en blanco en JSON . . . . . . . . . . . . . . . . . . . . . . . . . . 2829. Logo de Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2930. Logo de React . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2931. Logo de Vue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3032. Logo de WordPress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3033. Logo de HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3134. Componentes de HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3235. Solicitud de enlace WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . 3336. Respuesta de enlace WebSocket . . . . . . . . . . . . . . . . . . . . . . . . 3337. Logo de WebRTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3538. Logo de GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

vii

ÍNDICE DE FIGURAS

39. GitLab todo en uno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3740. Logo de GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3841. Logo de Bitbucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

42. Logo de Ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4343. Logo de React Native . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4444. Componentes principales de React Native . . . . . . . . . . . . . . . . . . 4445. Componentes de React Native . . . . . . . . . . . . . . . . . . . . . . . . . 4546. Logo de Flutter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4547. Placa de aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4848. Hello World) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5449. Código de Ionic (Angular) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5550. Código de Ionic (React) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5651. Código de React Native . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5752. Código de Flutter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5853. Comparativa de rendimiento de live reload . . . . . . . . . . . . . . . . . . 6154. Comparativa de rendimiento de la primera compilación e instalación . . 6255. Comparativa de rendimiento de compilación e instalación . . . . . . . . . 62

56. Maquetación de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . 68

57. Paso de mensajes del evento SETUP . . . . . . . . . . . . . . . . . . . . . 7158. Paso de mensajes del evento CONTINUE . . . . . . . . . . . . . . . . . . . 7159. Paso de mensajes de la capacidad de location update . . . . . . . . . . . 7260. Paso de mensajes de la capacidad de chat . . . . . . . . . . . . . . . . . . 7361. Paso de mensajes de la capacidad de WebRTC . . . . . . . . . . . . . . . 7562. Página home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7763. Solicitud de permisos de usuario . . . . . . . . . . . . . . . . . . . . . . . 7764. Página de ajustes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7965. Página de llamada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8066. Página de chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8167. Página de WebRTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8268. Versión iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8469. Versión web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

70. Instalador para Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9071. Instalador para MacOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9072. Versión de Escritorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

viii

Capítulo 1

Introducción

Las personas, cuando se encuentran en una situación de emergencia, estás acos-tumbradas a utilizar su teléfono para llamar al 112 o a un número de teléfono especí-fico del servicio que necesitan mediante una llamada telefónica de voz. Este método esrápido y sencillo de entender para cualquier persona puesto que todos estamos habi-tuados a llamar por teléfono, pero tiene muchas carencias que se podrían solucionarcon las nuevas tecnologías.

Es aquí donde entran las aplicaciones que permiten llamar a emergencias, per-mitiendo no sólo llamar, si no que al ser una aplicación móvil, pueden enviar otrascosas como puede ser la ubicación del usuario. También son muy útiles para laspersonas discapacitadas que no pueden realizar una llamada telefónica normal peroque sí podrían comunicarse mediante un chat. El problema que tienen estas aplica-ciones es que funcionan únicamente en la región en la que se ha desarrollado dichaaplicación, puesto que se integran con los centros de emergencia de su región, perodicha aplicación no funcionaría si esa persona quiere llamar a emergencias en otraregión o en otro país.

Para solucionar dicho problema se creó el proyecto PEMEA (Pan-European MobileEmergency Application). Dicho proyecto se diseñó originalmente para permitir que lasaplicaciones de llamadas a los servicios de emergencia pudieran tener roaming a niveleuropeo. Dicho proyecto forma parte del proyecto europeo NEXES (NEXt generationEmergency Services), que pretende integrar las nuevas tecnologías en los servicios deemergencias a nivel europeo.

PEMEA define una red en la que cualquier aplicación móvil y cualquier PSAP (Pu-blic Safety Answering Point) que estén integrados con la red puedan operar en cual-quier lugar de Europa. Para ello definen una serie de estándares que debe cumplirla información que se transmite. Pero PEMEA sólo define cómo se va a tratar lainformación, no ofrece una implementación de dicho estándar, por ello la empresaDeveryware, que participó también en la definición del estándar, ha desarrollado unaimplementación de PEMEA llamada GHALE (GeoHub Advanced Location Element).Dicha implementación está formada por una serie de nodos que siguen el estándarPEMEA y se ofrece a los proveedores de aplicaciones móviles y a los PSAP que quierenintegrarse en PEMEA una serie de interfaces de programación de aplicaciones (API)que todos deben seguir para funcionar dentro de la red PEMEA.

Deveryware dispone de una aplicación de demostración nativa para Android que

1

1.1. Motivación

está integrada con GHALE, aunque hay un único profesional en el equipo que sa-be Android y que se encarga de actualizar la aplicación cuando se añaden nuevasfuncionalidades. Deveryware también dispone de una página web de demostraciónque simula lo que vería un PSAP, permitiendo ver las llamadas y atenderlas, y quetambién está integrada con GHALE.

Cada vez que se modifica o que se actualiza GHALE, se tienen que actualizar porun lado la aplicación Android y por otro lado la página web. Puesto que hay más deun programador web siempre se termina antes de actualizar la página web del PSAP yhay que esperar a la aplicación Android. Se comentó que estaría bien disponer de unaaplicación iOS, puesto que algunos usuarios de Deveryware no disponen de teléfonosAndroid y no pueden por tanto utilizar la aplicación móvil de GHALE para hacerdemostraciones. Así mismo también se quería que se implementara una versión webde la aplicación para que los desarrolladores pudieran realizar fácilmente llamadasal sistema para probar el funcionamiento del mismo y poder descubrir bugs si loshubiera tras alguna modificación.

Por estos motivos se planteó la posibilidad de migrar la aplicación móvil a unaaplicación híbrida que permitiría disponer de una aplicación móvil para Android,para iOS y también de una página web. Además, todas las aplicaciones se generaríana partir del mismo código, con lo que sería más fácil mantener la coherencia entre laaplicación de cada plataforma que si se hiciera una nativa para cada plataforma.

A la hora de investigar los distintos frameworks para el desarrollo de aplicacioneshíbridas se descubrió que no es fácil saber a priori qué framework se adapta mejora cada situación, y la elección del framework es una decisión que hay que tomarantes de haber desarrollado parte de la aplicación, porque tener que cambiar a otroframework en medio del desarrollo puede significar la pérdida de mucho tiempo quese podría haber evitado si a priori se hubiera sabido que el framework con el que seempezó a desarrollar no cumplía con alguna de las necesidades que se tenían.

Es por esto que se decidió realizar un análisis de los frameworks antes de empezarel desarrollo, para no perder tiempo en un futuro por una mala elección.

1.1. Motivación

A la hora de decidir si desarrollar una aplicación nativa o una híbrida, surgen unaserie de preguntas que a veces no es fácil contestar.

En primer lugar, hay que ver si el framework de desarrollo de aplicaciones híbridasque se va a utilizar ofrece todas las funcionalidades nativas que la aplicación va atener que utilizar. Esto es importante porque si se descubre en mitad del desarrolloque dicho framework no ofrece todavía una funcionalidad nativa que es necesariapodría haberse perdido casi todo el tiempo de desarrollo invertido y tener que cambiarel desarrollo de la aplicación a uno nativo o a utilizar otro framework que sí que tengadisponible dicha funcionalidad nativa.

En segundo lugar, hay que conocer con qué lenguajes tiene más experiencia elequipo de desarrollo que se va a encargar de desarrollar la aplicación. Esto es impor-tante porque si varios frameworks de desarrollo de aplicaciones híbridas satisfacentodas las necesidades de la aplicación, es importante tener en cuenta el tiempo deaprendizaje de dicho framework por parte del equipo de desarrollo.

2

Introducción

Si el equipo de desarrollo tiene experiencia utilizando los lenguajes y las herra-mientas de dicho framework, el tiempo de aprendizaje del framework será muchomás corto que si tienen que familiarizarse con todo. Si ya se dispone de un equipo dedesarrollo con mucha experiencia en desarrollo nativo de aplicaciones, puede ser máseficiente que el desarrollo de la aplicación se desarrolle de forma nativa simplementeporque el tiempo de aprendizaje de un framework de desarrollo de aplicaciones híbri-das puede llevar mucho más tiempo que desarrollar la aplicación en sí a un equipode dichas características.

Si todavía no se dispone de un equipo de desarrollo para la aplicación que se quieredesarrollar y se quiere que la aplicación sea multiplataforma, puede ser mucho máseficiente contratar perfiles que sepan manejar algún framework concreto de desarro-llo de aplicaciones híbridas o que, al menos, conozcan el lenguaje y las tecnologíasque va a utilizar dicho framework, antes que contratar profesionales con experienciaen cada tipo de plataforma, porque la aplicación será multiplataforma desde el inicioy no habrá que desarrollar una aplicación para cada plataforma, si no que la mismaaplicación podrá desplegarse en todas ellas.

En ocasiones es difícil saber exactamente si un framework ofrecerá todas las fun-cionalidades nativas que la aplicación va a necesitar, o incluso si dicho frameworkpermite desplegar la aplicación en todas las plataformas necesarias. Este problemase presentó a la hora de elegir un framework de desarrollo de aplicaciones híbridas,y por lo tanto se decidió realizar dicho análisis y comparativa en este proyecto antesde realizar el desarrollo de la aplicación para los servicios de emergencias.

1.2. Objetivos

El principal objetivo de este proyecto es llevar a cabo un análisis exhaustivo delos diferentes frameworks de desarrollo de aplicaciones híbridas que existen actual-mente y realizar una comparativa de dichos frameworks para que sea más sencilloidentificar qué framework es el más adecuado para la aplicación híbrida que se quieradesarrollar.

Esto facilitará la elección de un framework u otro sabiendo las ventajas y desven-tajas que presenta cada uno, y viendo todas las funcionalidades que ofrece y aquellasque no tiene disponibles.

Tras realizar esta comparativa, se va a desarrollar una aplicación híbrida parael proyecto GHALE, para mejorar la actual aplicación Android que existe, y poderutilizar dicha aplicación tanto en iOS como en navegadores web.

Esto permitirá que el desarrollo de una única aplicación se vea reflejado en todaslas plataformas, ahorrando tiempo de desarrollo y la necesidad de tener que tenerdistintas aplicaciones que coexistan al mismo tiempo.

1.3. Estructura del documento

La estructura del documento es la siguiente:

3

1.3. Estructura del documento

1.3.1. Estado del arte

En este capítulo se analiza el estado actual de las tecnologías existentes y quepueden ser necesarias para la realización de este proyecto.

1.3.2. Análisis y comparativa de los frameworks

Este capítulo analizará a fondo todo lo que ofrece cada framework y realizará unacomparativa entre los diferentes frameworks, para que sea fácil saber qué frameworkes el más adecuado a la hora de desarrollar una aplicación.

1.3.3. Diseño

Aquí se realizará el análisis de requisitos y el diseño de la arquitectura de la apli-cación que se va a desarrollar.

1.3.4. Desarrollo

En este capítulo se explicarán las decisiones tomadas durante el proceso de desa-rrollo, así como los problemas que se hayan encontrado durante dicho proceso y elresultado final.

1.3.5. Conclusiones

Por último se expondrán las conclusiones obtenidas de la realización de este pro-yecto, así como las líneas futuras que se podrían llevar a cabo en un futuro.

4

Capítulo 2

Estado del arte

Las tecnologías evolucionan a gran velocidad, es por ello que es importante conocerel estado actual de las tecnologías relevantes para el desarrollo de este proyecto.

En este capítulo se analiza qué tecnologías son relevantes y en qué estado seencuentran, explicando para qué sirven y por qué son relevantes.

2.1. Servicios de emergencia

Es importante saber cómo funcionan los servicios de emergencia actualmentepuesto que la aplicación que se va a transformar de nativa en Android a híbridamultiplataforma es para demostrar cómo se vería una aplicación de llamadas a losservicios de emergencias integrada con PEMEA.

2.1.1. Número de emergencias común

El número único de emergencias europeo fue adoptado por decisión del Consejoen julio de 1991 para permitir a los ciudadanos de la Unión Europea llamar a losservicios de emergencias utilizando un número único [1].

Figura 1: Logo del 112 [2]

Tener un número de emergencias único es importante porque mucha gente dentrode la Unión Europea se desplaza habitualmente por trabajo a otros países miembros.El 112 coexiste con los números de emergencia nacionales en la mayoría de los paísesmiembros, aunque algunos países lo han adoptado como número de emergenciasnacional.

Su funcionamiento es sencillo, cuando una persona desde un número fijo o móvilllama al 112, un operador de un PSAP (Public Safety Answering Point) atenderá sullamada. Dichos PSAPs son centros de llamadas que reciben llamadas de emergencias

5


como puede ser policía, bomberos, ambulancias, etc. No es necesario que el teléfonomóvil disponga de tarjeta SIM que lo identifique, los teléfonos móviles permiten lla-mar de manera especial a ciertos números que tienen guardados como números deemergencias incluso sin desbloquear el dispositivo.

Los miembros de la Unión Europea también deben procurar localizar la ubicacióndesde la que se realizó la llamada, esto es sencillo para los números de teléfono fijos,pero la ubicación de los teléfonos móviles puede ser muy imprecisa.

2.1.2. Asociación Europea de Números de Emergencia (EENA)

La Asociación Europea de Números de Emergencia (EENA por sus siglas en inglesEuropean Emergency Number Association) es una organización no gubernamentalque tiene como principal objetivo mejorar la seguridad de las personas en Europa.Se centra en mejorar los servicios de emergencias que existen hoy en día mediante eluso de las nuevas tecnologías.

Figura 2: Logo de EENA [3]

EENA está actualmente trabajando en diversos frentes para alcanzar su objetivo,entre estos frentes se encuentran [3]:

• Mejorar la precisión de la localización de las personas que necesitan ayuda.

• Probar y desarrollar la arquitectura NG112 para una mejor integración entre lasnuevas tecnologías y los servicios de emergencias.

• Utilizar la inteligencia artificial y el machine learning para mejorar el tratamientode los datos.

• Implementar PEMEA para mejorar las aplicaciones de emergencias.

• Utilizar drones para mejorar la seguridad y habilitar espacios para que los ser-vicios de emergencia aprendan unos de otros.

• Crear una red para juntar a expertos internacionales en el área de la cibersegu-ridad.

Las iniciativas que está promoviendo EENA más importantes actualmente sonAML, NG112 y PEMEA, a continuación se explicará en que punto está cada unahaciendo especial hincapié en PEMEA por ser la más relevante para el desarrollo deeste proyecto.

2.1.2.1. Advanced Mobile Location (AML)

Poder determinar la ubicación precisa de la persona que llama a los servicios deemergencia es una pieza clave de información que puede utilizar el PSAP que recibela llamada para enviar el servicio necesario a dónde se encuentra el llamante. Laubicación de la persona que llama puede ser perjudicial si no es lo suficientemente

6

Estado del arte

precisa, puesto que el servicio de emergencia, por ejemplo una ambulancia, puededirigirse a una ubicación errónea y no encontrar al llamante a tiempo.

Cuando un teléfono que dispone de AML realiza una llamada de emergencia, elteléfono envía automáticamente a los servicios de emergencia información de ubica-ción precisa de la persona que está realizando la llamada. AML enciende el serviciode localización y la wifi del teléfono durante dicha llamada de emergencia para obte-ner la mejor precisión disponible. La ubicación puede ser enviada a los servicios deemergencia mediante un SMS o mediante una petición POST utilizando el protocoloHTTP. Los servicios de emergencia de los países que han implementado AML recibenautomáticamente esta información.

Tienen AML integrado todos los teléfonos Android con versión 2.3.7 Gingerbread(lanzada en Diciembre de 2010) o posterior, y todos los teléfonos Apple con versión deiOS 11.3 (lanzada en Marzo de 2018) o posterior [4]. Desde enero de 2020, 19 paísesen todo el mundo ya tienen implementado AML [5].

Figura 3: Implementación de AML [5]

AML es un método sencillo de mejorar la ubicación de las llamadas realizadasdesde teléfonos móviles a los servicios de emergencias, pero tiene un inconvenienteprincipal, que los centros de emergencias tienen que integrarse con el servicio paraque funcione en cada país.

2.1.2.2. Next Generation 112 (NG112)

NG112 trata de integrar las nuevas tecnologías con los servicios de emergencias,de modo que se puedan utilizar funcionalidades que ofrecen los smartphones comopuede ser utilizar la ubicación precisa del teléfono, videollamadas, chats o envío dearchivos (como fotos o vídeos), lo que permitiría que las personas discapacitadasque no pueden realizar llamadas de voz puedan utilizar también los servicios deemergencias.

Esto requiere que se efectúen cambios no sólo en los teléfonos móviles, si no tam-bién en los PSAP, los servicios de respuesta y las redes móviles entre otros.

7


NG112 fue lanzado en la Conferencia EENA 2019 en Dubrovnik (Croacia), el nue-vo proyecto de EENA reunirá a un consorcio de socios (un consorcio por cada paísparticipante), para probar y desplegar la arquitectura técnica que permite NG112 endiferentes países europeos, con un enfoque en demostrar su uso en entornos de lavida real [6].

Las situaciones de prueba propuestas incluyen enrutamiento basado en la ubica-ción, vídeo y comunicaciones de texto en tiempo real, llamadas a través de objetosconectados y transmisión de mensajes de advertencia públicos a través de los alta-voces del hogar. Los casos de uso no son exhaustivos y se invita a los participantesinteresados a proponer situaciones de prueba adicionales [6].

Para solicitar el proyecto, los servicios de emergencia y las organizaciones privadasdeben crear un consorcio. Este consorcio debe asegurarse de que puedan probar unallamada NG112 completa entre el equipo del usuario y un PSAP basado en estándaresinternacionales. Cada consorcio debe involucrar al menos un PSAP [6].

2.1.2.3. Pan-European Mobile Emergency App (PEMEA)

Antes de que empezara el proyecto NG112, ya había algunas personas que ha-bían visto que seria muy beneficioso aplicar las nuevas tecnologías a los servicios deemergencias. Puesto que hoy en día la mayor parte de la población dispone de unteléfono inteligente (smartphone), hubo personas que tuvieron la idea de desarrollaraplicaciones que permitieran utilizar las ventajas de los smartphones.

Pero conseguir que una aplicación se integre con los servicios de emergencias escostoso, por ello las aplicaciones de emergencias que se han desarrollado se hanintegrado con el PSAP de su región, y solo funcionan si el usuario la utiliza dentro dedicha región. Cada aplicación tiene su forma particular de comunicarse con el PSAPde su región. El principal problema de estas aplicaciones es que cuando el usuariosale de su región ya no sirven, de modo que aunque esté acostumbrado a utilizarlacuando tiene una emergencia, si se encuentra de viaje no podrá usar la aplicación ytendrá que recurrir a otro método para contactar con los servicios de emergencias.

El objetivo de la arquitectura PEMEA es permitir que un usuario seleccione unaaplicación que satisfaga sus necesidades en función de la funcionalidad, el coste ylos niveles de comodidad, y pueda comunicarse en cualquier parte de Europa conlos servicios de emergencia proporcionando una ubicación precisa y otra informa-ción útil en un momento de necesidad con la configuración adecuada de seguridad yprivacidad [7].

Figura 4: Logo de PEMEA [7]

Un ejemplo de una aplicación de emergencias es My112, una aplicación que fun-ciona en la comunidad de Madrid. Dicha aplicación permite geolocalizar de formaprecisa al usuario durante una llamada. También puede notificar de desastres me-dioambientales a todos los usuarios que se encuentren dentro de su radio de acción.No obstante, no es posible utilizar la app My112 en toda España, pues solo está

8

Estado del arte

integrada los centros de emergencia de Madrid, Castilla-León, Baleares, Cataluña,Cantabria y Melilla [8].

My112 es un claro ejemplo de lo que sucede con las distintas aplicaciones de emer-gencias que existen en Europa, por ello, EENA puso en marcha un proyecto en 2016que buscaba que estas apps funcionaran en cualquier lugar de la Unión Europea.Dicho proyecto pretendía crear un estándar para que la integración de cualquier appcon cualquier PSAP se produjera de la misma manera para que si todas las aplicacio-nes y todos los PSAP de Europa siguieran dicho estándar, las aplicaciones pudierancomunicarse con el PSAP más cercano y funcionar correctamente.

Dicha búsqueda se llevo a cabo mediante el proyecto NEXES (NEXt generationEmergency Services). PEMEA fue concebido bajo el proyecto NEXES gracias a la cola-boración de EENA, Deveryware y Beta 80. PEMEA concibió una arquitectura median-te la cual, cualquier aplicación integrada podría comunicarse con el PSAP integradomás cercano, y, en caso de que éste no estuviera disponible, PEMEA buscara otroPSAP, de modo que la llamada siempre tuviera respuesta e intentando que fuerala mejor respuesta posible. Dicha arquitectura fue validada por la organización deestandarización ETSI (European Telecommunications Standards Institute).

La arquitectura de PEMEA consta de los siguientes componentes:

• AP: Un AP (Application Provider) es el nodo con el que se comunican las apli-caciones. Las aplicaciones que sigan el estándar definido por PEMEA se co-nectarán con el AP que tengan configurado y éste será su puesta de entrada enPEMEA. El AP convierte la llamada en una estructura llamada EDS (Emergency-DataSend) que será la estructura que navegue a través de los diferentes nodosde PEMEA.

• PEMEA-PSAP: Un PSAP de PEMEA (PEMEA Public Safety Answering Point) esun nodo con el que se comunican los PSAPs. Los PSAP que sigan el estándardefinido por PEMEA se conectan con el PEMEA-PSAP que tengan configurado ya partir de este nodo recibirán la información de los usuarios. Los PSAP recibenla información del usuario en forma de EDS, que tiene una estructura XML, ypueden elegir como atender la llamada.

• PSP: Un PSP (PSAP Service Provider) es un nodo que se encarga de enrutar lasllamas provenientes de un AP para enviárselas al PSAP más cercano. En caso deque no fuera posible entregar la llamada al PSAP por algún motivo (Por ejemploporque el PSAP esté saturado), el PSP enviará la llamada a un nodo ASP.

• ASP: Un ASP (Aggregation Service Provider) es un nodo que recibe llamadas queun PSP que no ha podido entregar y se las envía a otro PSP para que intenteentregarlas a otros PSAPs.

9


Figura 5: Arquitectura de PEMEA

EENA, junto con Beta 80, Deveryware y la Alianza de Desarrolladores (DevelopersAlliance), lanzó una convocatoria pan-europea para solicitudes de países y aplica-ciones de emergencia que quieran hacer historia de seguridad pública. El proyectoPEMEA se lanzó oficialmente el 11 de septiembre de 2018 en Madrid, España. A partirde entonces hay ciertas fases definidas para su implantación a nivel europeo [9].

PEMEA Fase I

Durante la conferencia EENA 2018 en Ljubljana, se anunció una iniciativa queinvita a los proveedores de aplicaciones de emergencia y PSAPw a participar en unproyecto PEMEA de dos fases que permitiría la interoperabilidad entre PSAP y apli-caciones de emergencia itinerantes por primera vez. Al concluir la conferencia EENA,el proyecto se abrió para muestras de interés. El proyecto recibió 28 muestras deinterés, incluidos proveedores de aplicaciones y PSAPs. El proyecto seleccionó las 12organizaciones enumeradas a continuación para participar en la primera fase [10]:

• 112 Suomi, Finland.

• 112 Where Are U, Italy.

• 5G Spin, Slovenia.

• SOS Deiak, Basque Country, Spain.

• 112 Región de Murcia, Murcia, Spain.

10

Estado del arte

• My 112, Spain.

• Omnitor App, Sweden.

• SOS Alarm, Sweden.

• 112 App NL, the Netherlands.

• The Zachranka App, Czech Republic.

• mySTART+ Systel, France.

• Smart 112 Mobile.

Durante el proyecto, algunos de los participantes decidieron posponer su integra-ción con la red PEMEA por varias razones. Los participantes seleccionados se reu-nieron en Madrid para una reunión de lanzamiento formal en septiembre de 2018.Durante esta reunión de lanzamiento se detalló la arquitectura del proyecto y cómose vincularían las aplicaciones y los PSAPs a través de uno de los dos proveedores deservicios de PEMEA, Beta 80 y Deveryware. Al final de la reunión inicial, se hicieronplanes entre cada uno de los participantes y uno o ambos proveedores de servicios dePEMEA para discusiones de seguimiento y pruebas de integración. La primera faseduró hasta finales de 2019 [10].

En la figura 6 se muestran las organizaciones que finalmente llevaron a cabo lafase I. A la izquierda se encuentran las que se conectaron a PEMEA a través deDeveryware y a la derecha las que lo hicieron a través de Beta 80.

Figura 6: PEMEA Fase I [10]

11

2.2. Tecnologías de desarrollo móvil

Durante la fase 1, las aplicaciones demostraron ser capaces de funcionar en cual-quier región, no solo en su región de origen, y también ser capaces de enviar laubicación precisa de los usuarios y diversa información como pueden ser los idiomasque entiende el usuario o datos médicos que pueden acelerar el tiempo de respuestade los servicios de emergencias.

PEMEA Fase II

El objetivo de la fase II es introducir servicios avanzados que comienzan con unservicio de chat o de mensajería instantánea. Los proveedores de PEMEA trabaja-rán para proporcionar una implementación interoperable que posteriormente puedapublicarse en un documento de extensiones de PEMEA validado por ETSI.

La fase II fue lanzada en Noviembre de 2019. Esta fase hace especial hincapié en elservicio de chat y en integrar numerosos PSAPs de Europa para que se interconectena través de PEMEA con las aplicaciones que se integraron durante la fase I.

Los resultados se iban a presentar en la conferencia EENA 2020 del 1 al 3 deabril en Riga, pero debido al COVID-19 este evento se ha retrasado y se producirá enprincipio los días 9-11 de Diciembre del 2020 [11].


Los teléfonos inteligentes o smartphones son, junto con internet, uno de los avan-ces tecnológicos recientes que se utilizan con mayor frecuencia. La mayoría de laspersonas de los países desarrollados tienen al menos un smartphone propio. Lossmartphones están tan integrados en nuestras vidas que incluso algunos bebés yniños pequeños los utilizan bajo la supervisión de sus padres.

Los principales sistemas operativos que utilizan los smartphones de hoy en díason Android e iOS como puede verse en la figura 7.

Figura 7: Cuota de mercado por sistema operativo móvil en todo el mundo [12]

12

Estado del arte

Existen otros sistemas operativos además de Android e iOS, pero apenas son uti-lizados. Microsoft intentó sacar su propio sistema operativo en 2015, Windows 10Mobile, pero no consiguió penetrar lo suficiente en el mercado y decidió dejar dedarle soporte en Enero de 2020 [13].

2.2.1. Android

Android es un sistema operativo móvil basado en una versión modificada del ker-nel de Linux y otro software de código abierto, diseñado principalmente para disposi-tivos móviles con pantalla táctil como teléfonos inteligentes y tabletas. Fue desarro-llado inicialmente por Android Inc., que Google compró en 2005, Android se presentóen 2007, con el primer dispositivo Android comercial lanzado en septiembre de 2008[14].

Figura 8: Logo de Android [14]

El código fuente principal de Android se conoce como Android Open Source Project(AOSP), que se licencia principalmente bajo la Licencia Apache. Android es desarro-llado por un consorcio de desarrolladores conocido como Open Handset Alliance, conel principal contribuyente y comercializador Google. Esto ha permitido desarrollar va-riantes de Android en una amplia gama de dispositivos electrónicos, como consolasde juegos, cámaras digitales, PCs y otros, cada uno conW una interfaz de usuario es-pecializada. Algunos derivados bien conocidos incluyen Android TV para televisoresy Wear OS para wearables, ambos desarrollados por Google [14].

La aplicación de demostración integrada con PEMEA que desarrolló Deverywareestá disponible únicamente para dispositivos Android. En un principio se estudió laposibilidad de desarrollar una aplicación equivalente para iOS pero se rechazó la ideaporque en Europa hay un mayor volumen de usuarios que utiliza Android frente aiOS.

Los dispositivos Android tienen dos tipos de aplicaciones, las de sistema y las deusuario. Las aplicaciones de sistema vienen preinstaladas en el teléfono por el fabri-cante y tienen que tener licencia de los fabricantes de dispositivos Android certifica-dos bajo los estándares de Google. Las aplicaciones de usuario pueden descargarsea través de la Play Store y pueden ser publicadas por cualquier desarrollador. Noobstante tienen que están firmadas con una firma reconocida por alguna autoridadde certificación. Los dispositivos Android son poco restrictivos en cuanto a los per-misos que dan al usuario, de modo que también se pueden instalar aplicaciones enel smartphone ejecutando un archivo con extensión .apk si se han habilitado lasopciones correspondientes en los ajustes del sistema operativo.

El sistema operativo android se encuentra actualmente en la versión 11, publicadael 19 de Febrero del 2020. Normalmente los fabricantes crean una capa de personali-zación que trabaja con el sistema operativo Android pero hace que la experiencia delusuario sea diferente en función de a qué fabricante se compra el smartphone. Estohace que algunos modelos de smartphone no se actualicen a las últimas versionesdisponibles de Android, especialmente si el modelo es algo antiguo.

13


Como se puede ver en la figura 9, las versiones que utilizan los dispositivos Androidson muy variadas. La mayoría utiliza versiones recientes, pero hay un porcentajesignificativo de smartphones que utilizan versiones inferiores.

Figura 9: Versiones de Android [15]

2.2.1.1. Lenguajes

Los principales lenguajes de programación que se utilizan a la hora de progra-mar aplicaciones para Android son Java y Kotlin, aunque también se pueden utilizarC/C++, C# o BASIC. Java es el lenguaje de referencia cuando se habla de desarrollaraplicaciones para Android, pero Kotlin está ganando fuerza desde que su primerarelease en 2016. Además Google anunció en 2019 que Kotlin es ahora su idiomapreferido para los desarrolladores de aplicaciones Android.

Java

Java es un lenguaje de programación de propósito general basado en clases, orien-tado a objetos y diseñado para tener la menor cantidad posible de dependencias deimplementación [16].

Su objetivo es permitir que los desarrolladores de aplicaciones escriban una vezy ejecuten en cualquier lugar (WORA), lo que significa que el código Java compiladopuede ejecutarse en todas las plataformas que admiten Java sin la necesidad derecompilación [16].

Las aplicaciones Java generalmente se compilan en bytecode que puede ejecutarseen cualquier máquina virtual Java (JVM) independientemente de la arquitectura de

14

Estado del arte

la computadora subyacente [16].

Figura 10: Logo de Java [16]

Java utiliza un recolector de basura automático para administrar la memoria enel ciclo de vida del objeto. El programador determina cuándo se crean los objetos,y el tiempo de ejecución de Java es responsable de recuperar la memoria una vezque los objetos ya no están en uso. Una vez que no quedan referencias a un objeto,la memoria inalcanzable se vuelve elegible para ser liberada automáticamente por elrecolector de basura. Aun así puede ocurrir algo similar a una pérdida de memoriasi el código de un programador contiene una referencia a un objeto que ya no senecesita, generalmente cuando los objetos que ya no se necesitan se almacenan encontenedores que todavía están en uso [16].

La aplicación Android de Deveryware está escrita en Java porque es el mismolenguaje en el que está escrita la implementación de PEMEA de Deveryware, de estemodo es más sencillo para los desarrolladores entender el código de ambas partes.

Kotlin

Kotlin es un lenguaje de programación multiplataforma, de tipo estático y de pro-pósito general con inferencia de tipos. Kotlin está diseñado para interoperar comple-tamente con Java, y la versión de la Java Virtual Machine de su biblioteca están-dar depende de la biblioteca de clases Java, pero la inferencia de tipos permite quesu sintaxis sea más concisa. JetBrains asume los costes de desarrollo del lenguaje,mientras que la fundación Kotlin protege la marca registrada Kotlin [17].

Figura 11: Logo de Kotlin [17]

El líder de desarrollo, Andrey Breslav, ha dicho que Kotlin está diseñado para serun lenguaje orientado a objetos de fuerza industrial y un ”mejor lenguaje” que Java,pero aún así ser completamente interoperable con el código Java, lo que permite alas empresas realizar una migración gradual de Java a Kotlin [17].

Las principales características que diferencian a Kotlin de Java son [17]:

• Los puntos y coma son opcionales como terminadores de enunciados. En lamayoría de los casos, una nueva línea es suficiente para que el compiladordeduzca que la declaración ha finalizado.

• Las declaraciones de variables de Kotlin y las listas de parámetros tienen el tipode datos después del nombre de la variable (con un separador de dos puntos),similar a Pascal y TypeScript.

15


• Las variables en Kotlin pueden ser de solo lectura, declaradas con la palabraclave val, o mutables, declaradas con la palabra clave var.

• Los miembros de la clase son públicos de forma predeterminada, y las clasesson finales de manera predeterminada, lo que significa que la creación de unaclase derivada está deshabilitada a menos que la clase base se declare con lapalabra clave open.

• Las funciones de Kotlin (y los constructores) admiten argumentos predetermi-nados, listas de argumentos de longitud variable, argumentos con nombre ysobrecarga.

2.2.1.2. Herramientas

Para desarrollar en Android se utilizan las siguientes herramientas:

Android Studio

Android Studio es el entorno oficial de desarrollo integrado (IDE) para el sistemaoperativo Android de Google, construido sobre el software IntelliJ IDEA de JetBrainsy diseñado específicamente para el desarrollo de aplicaciones Android [18].

Está disponible para descargar en sistemas operativos basados en Windows, ma-cOS y Linux y soporta los lenguajes Kotlin, Java y C++. También dispone de exten-siones que permiten utilizar el lenguaje GO. [18].

Figura 12: Logo de Android Studio [18]

La versión estable de Android Studio tiene las siguiente funcionalidades [18]:

• Soporte para construcción basada en Gradle.

• Refactorización específica de Android y arreglos rápidos.

• Herramientas Lint para detectar problemas de rendimiento, usabilidad, compa-tibilidad de versiones y otros problemas.

• Integración de ProGuard y funciones de firma de aplicaciones.

• Plantillas para crear diseños comunes de Android y otros componentes.

• Un editor de diseño enriquecido que permite a los usuarios arrastrar y soltarcomponentes de la interfaz de usuario.

• Soporte para programar aplicaciones para Android Wear.

• Soporte integrado para Google Cloud Platform, que permite la integración conFirebase Cloud Messaging (antes ’Google Cloud Messaging’) y Google App Engi-ne.

• Un dispositivo virtual de Android que se utiliza para ejecutar y probar aplicacio-nes.

16

Estado del arte

• Renderizado en tiempo real.

• Consola de desarrollador: consejos de optimización, ayuda para la traducción,estadísticas de uso.

Android Studio es el IDE utilizado por el equipo de desarrollo de Deveryware parael desarrollo de la aplicación Android.

Gradle

Gradle es un sistema de automatización de compilación de código abierto que sebasa en los conceptos de Apache Ant y Apache Maven e introduce un lenguaje espe-cífico de dominio (DSL) basado en Groovy en lugar del formulario XML utilizado porApache Maven para declarar la configuración del proyecto. Gradle utiliza un gráfi-co acíclico dirigido (”DAG”) para determinar el orden en que se pueden ejecutar lastareas [19].

Figura 13: Logo de Gradle [20]

Gradle fue diseñado para compilaciones de proyectos múltiples, que pueden llegara ser bastante grandes. Admite compilaciones incrementales al determinar de formainteligente qué partes del árbol de compilación están actualizadas; No es necesariovolver a ejecutar ninguna tarea que dependa solo de esas partes [19].

El sistema de construcción de Android compila los recursos y el código fuentede la aplicación, y los empaqueta en APKs que se pueden probar, desplegar, firmar ydistribuir. Android Studio utiliza Gradle para automatizar y administrar el proceso decompilación, también permite definir configuraciones de compilación personalizadasflexibles [21].

Cada configuración de compilación puede definir su propio conjunto de código yrecursos, mientras reutiliza las partes comunes a todas las versiones de tu aplicación.El plugin de Android para Gradle funciona con el kit de herramientas de construc-ción para proporcionar procesos y opciones configurables que son específicas paraconstruir y probar aplicaciones Android [21].

La aplicación Android de Deveryware utiliza Grade para construir la aplicación.

2.2.2. iOS

iOS (anteriormente conocido como iPhone OS) es un sistema operativo móvil crea-do y desarrollado por Apple Inc. exclusivamente para su hardware. Es el sistemaoperativo que actualmente alimenta muchos de los dispositivos móviles de la com-pañía, incluidos el iPhone y el iPod Touch. También alimentó el iPad antes de laintroducción de iPadOS en 2019. Es el segundo sistema operativo móvil más populara nivel mundial después de Android [22].

17


Figura 14: Logo de Apple [23]

Originalmente presentado en 2007 para el iPhone, iOS se ha extendido para admi-tir otros dispositivos Apple como el iPod Touch (septiembre de 2007) y el iPad (enerode 2010). En marzo de 2018, la tienda de aplicaciones de Apple contenía ya másde 2.1 millones de aplicaciones iOS, 1 millón de las cuales eran nativas para iPads.Estas aplicaciones móviles se han descargado más de 130 mil millones de veces [22].

La interfaz de usuario de iOS se basa en la manipulación directa, utilizando gestosmultitáctiles. Los elementos de control de la interfaz consisten en controles deslizan-tes, interruptores y botones. La interacción con el sistema operativo incluye gestoscomo deslizar, tocar, pellizcar, todos ellos tienen definiciones específicas dentro delcontexto del sistema operativo iOS y su interfaz multitáctil [22].

Algunas aplicaciones utilizan los acelerómetros internos para responder al movi-miento del dispositivo (un ejemplo común es el comando deshacer) o rotarlo en tresdimensiones (como cuando se cambia entre el modo vertical y horizontal). Apple hasido elogiado significativamente por incorporar funciones de accesibilidad exhausti-vas en iOS, lo que permite a los usuarios con discapacidades visuales y auditivasusar sus productos de manera adecuada [22].

Las principales versiones de iOS se lanzan anualmente. En todos los dispositivosiOS recientes, se verifica regularmente la disponibilidad de una actualización y, sihay una disponible, se solicitará al usuario que permita su instalación automática[22].

La versión actual, iOS 13, se lanzó al público el 19 de septiembre de 2019, presen-tando ajustes de la interfaz de usuario y un modo oscuro, junto con característicascomo una aplicación Recordatorios rediseñada, un teclado deslizante y una aplicaciónde fotos mejorada [22].

iOS 13 no es compatible con dispositivos con menos de 2 GB de RAM, incluidosel iPhone 5s, iPod Touch (6ta generación) y el iPhone 6 y iPhone 6 Plus, que aúnrepresentan más del 10 % de todos los dispositivos iOS. iOS 13 es exclusivamentepara iPhone y iPod touch, ya que la variante de iPad ahora se llama iPadOS [22].

Apple es mucho más restrictivo que Android con sus smartphones, esto se reflejaen que no permiten a ningún usuario realizar operaciones sobre el teléfono que re-quieran un cierto nivel de privilegios, es decir, que los usuarios solo pueden descargary utilizar las aplicaciones que aparecen en la App Store, que son aquellas que Appleha validado.

El proceso para poder publicar y distribuir una aplicación en la App Store estambién mucho más complejo que para hacerlo en la Play Store de Android.

2.2.2.1. Lenguajes

Cuando se trata de desarrollar aplicaciones iOS, en realidad solo se usan doslenguajes. Los lenguajes dominantes son Objective-C y Swift. Existen algunas alter-

18

Estado del arte

nativas pero estas requieren algunos procesos alternativos para funcionar que hacenque no merezca la pena [24].

Figura 15: Lenguajes para iOS [24]

Objective-C

Cuando comenzó a desarrollar aplicaciones iOS por primera vez, Apple eligió ellenguaje Objective-C. Fue licenciado por el cofundador de Apple Steve Jobs cuandocreó las computadoras NeXT en la década de 1980, y llevó el leguaje a Apple. Aligual que otros lenguajes de programación como C++ y C#, Objective-C se basa en ellenguaje C. Esto significa que la estructura básica y la sintaxis son similares a C, ymuchas de las características son familiares para los programadores que ya conocenC [24].

Sin embargo no es el lenguaje más utilizado hoy en día para el desarrollo de apli-caciones iOS, esto se debe a que en 2014 Apple lanzó su propio lenguaje de pro-gramación llamado Swift, y éste se ha convertido en el lenguaje por defecto de losdesarrolladores de aplicaciones iOS [24].

Swift

Swift es más fácil de usar que Objective-C, y es claramente el futuro del desarro-llo de aplicaciones iOS. Es el punto de partida de cualquier persona que desarrolleaplicaciones para iPhone o iPad [24].

Una de las mejores características de Swift es su facilidad de uso. Elimina muchasde las frases técnicas y la complicada sintaxis que hace que Objective-C sea intimi-dante para los principiantes. Dado que Swift fue diseñado para ser fácil de usar, hatenido bastante buena aceptación en la comunidad de desarrolladores [24].

Swift se desarrolla de forma abierta en Swift.org, con código fuente, un rastreadorde errores, foros y compilaciones de desarrollo regulares disponibles para todos. Estaamplia comunidad de desarrolladores, tanto dentro de Apple como cientos de cola-boradores externos, trabajan juntos para desarrollar y mantener Swift. Existe una

19


gama aún más amplia de blogs, podcasts, conferencias y reuniones donde los desa-rrolladores de la comunidad comparten sus experiencias sobre cómo utilizar Swift[25].

2.2.2.2. Herramientas

Para desarrollar aplicaciones de iOS utilizando las últimas tecnologías, es necesa-rio disponer de un Mac que ejecute la última versión de Xcode. Xcode incluye todaslas funcionalidades que se necesitan para diseñar, desarrollar y depurar aplicacionesiOS. También contiene el Kit de Desarrollo de Software (SDK) de iOS, que extiendeXcode para incluir las herramientas, compiladores y marcos de trabajo que se nece-sitan específicamente para el desarrollo de aplicaciones iOS [26].

Además, los smartphone que utilizan iOS no permiten instalar una aplicación apartir de un archivo ejecutable, al contrario que los que utilizan Android. Por ello esnecesario utilizar una aplicación de Apple llamada TestFlight que permite distribuiraplicaciones a otras personas para que las prueben antes de publicarlas en la AppStore.

Xcode

Xcode es un entorno de desarrollo integrado (IDE) para macOS desarrollado porApple que contiene un conjunto de herramientas de desarrollo de software para de-sarrollar software para macOS, iOS, iPadOS, watchOS y tvOS. Lanzado por primeravez en 2003, la última versión estable es la versión 11.3 y está disponible a través dela Mac App Store de forma gratuita para usuarios de macOS [27].

Figura 16: Logo de Xcode [27]

Los desarrolladores registrados pueden descargar versiones preliminares y ver-siones anteriores a través del sitio web de desarrolladores de Apple. Xcode incluyeherramientas de línea de comandos, que permiten el desarrollo al estilo UNIX a tra-vés de la aplicación Terminal de macOS [27].

TestFlight

TestFlight es un servicio en línea para la instalación y prueba inalámbrica deaplicaciones móviles, actualmente es propiedad de Apple Inc. y solo se ofrece a losdesarrolladores dentro del Programa de Desarrolladores de iOS [28].

Los desarrolladores se registran con el servicio para distribuir aplicaciones a betatesters internos o externos, que posteriormente pueden enviar comentarios sobre laaplicación a los desarrolladores. El SDK de TestFlight además permite a los desa-rrolladores recibir registros remotos, informes de fallos y comentarios de los testers[28].

20

Estado del arte

Figura 17: Logo de TestFlight [28]

TestFlight inicialmente admitió pruebas para aplicaciones Android e iOS, pero des-de marzo de 2014, Apple retiró la compatibilidad con Android. A partir de 2015, lasaplicaciones deben publicarse para TestFlight con Xcode, y los testers deben ser in-vitados con iTunes Connect [28].

Después de la invitación, hasta 25 testers internos (con hasta 10 dispositivos cadauno) y 10,000 beta testers externos pueden descargar y probar la compilación de laaplicación. Se pueden probar hasta 100 aplicaciones a la vez, interna o externamente[28].

Los testers se pueden agrupar y crear compilaciones separadas para cada gru-po. La aplicación TestFlight para iOS notifica a los evaluadores cuando hay nuevascompilaciones disponibles y permite el envío de comentarios [28].

2.3. Tecnologías de desarrollo web

Una página web es un conjunto de ficheros que devuelve un servidor como res-puesta a una petición GET de HTTP. Un navegador web es un programa en el cualse introduce una dirección URL y, al navegar a dicha dirección, el navegador realizaun GET a la URL seleccionada, recibe los ficheros que le devuelve el servidor y sabecomo interpretarlos para visualizar dicha página web.

Cuando se habla de página web hay que distinguir entre dos componentes funda-mentales: el front end y el back end. El front end es la página web en sí misma, sontodos los ficheros que devuelve el servidor y que permiten al usuario interactuar conel servidor mediante ciertos campos como pueden ser hipervínculos o formularios. Elback end es el servidor, se trata de un programa que escucha peticiones HTTP y lasresponde.

Esta distinción se produce porque en el momento en el que un usuario recibe to-dos los ficheros que forman la página web, es libre de modificarlos para cambiar sucomportamiento utilizando el navegador web. Esto se hace mediante las herramien-tas de desarrollador que, por ejemplo, en Google Chrome se abren pulsando F12.Normalmente se intenta hacer que estos ficheros sean difíciles de interpretar modifi-cando el código para que funcione igualmente pero no se puedan leer con facilidad,pero esto no impide que se puedan modificar.

Al disponer de libertad para modificar los ficheros, es importante que la páginaweb no tenga información sensible. Para obtener información sensible la página webtendrá que pedir dicha información al back end y éste decidirá si el usuario tiene lospermisos necesarios para obtener dicha información.

A continuación se explican los distintos tipos de ficheros que intervienen en elfuncionamiento de una página web, así como de los frameworks que existen para eldesarrollo de páginas web.

21


2.3.1. HyperText Markup Language (HTML)

HTML es el componente más básico de la web. Define el significado y la estructuradel contenido web. Se usa junto con otras tecnologías para describir la apariencia ypresentación (CSS) o la funcionalidad y el comportamiento (JavaScript) de una páginaweb [29].

”HyperText” se refiere a enlaces que conectan páginas web entre sí, ya sea dentrode un único sitio web o entre sitios web. Los enlaces son un aspecto fundamentalde la web. Al cargar contenido en internet y vincularlo a páginas creadas por otraspersonas, se convierte en un participante activo en la World Wide Web [29].

Figura 18: Logo de HTML [30]

HTML utiliza ”markup” para anotar texto, imágenes y otro contenido y mostrarloen un navegador web. El marcado HTML incluye ”elementos” especiales como <head>,<body>, <header>, <footer>y muchos otros [29].

Un elemento HTML se separa del resto del texto del documento mediante ”etique-tas”, que consisten en el nombre del elemento rodeado por ”<” y ”>”. El nombre deun elemento dentro de una etiqueta no distingue entre mayúsculas y minúsculas.Es decir, se puede escribir en mayúsculas, minúsculas o una mezcla. Por ejemplo,la etiqueta <title>se puede escribir como <Title>, <TITLE>o de cualquier otra forma[29].

Los navegadores web reciben todos los documentos necesarios para visualizar lapágina web de un servidor web. El documento HTML es el que el navegador comienzaa interpretar, y es en el HTML dónde se encuentran enlazados los demás documentos.

HTML5 fue la quinta y última versión principal de HTML por recomendación delWorld Wide Web Consortium (W3C). La especificación actual se conoce como HTMLLiving Standard y es mantenida por un consorcio de los principales proveedores denavegadores (Apple, Google, Mozilla y Microsoft). Sus objetivos eran mejorar el len-guaje con soporte para las últimas funciones multimedia para mantener el lenguajefácilmente legible por humanos y entendido por navegadores web, analizadores, etc.,sin la rigidez de XHTML y seguir siendo compatible con versiones de software anterior[30].

En la práctica HTML introduce nuevas etiquetas como <vídeo>o <audio>.

2.3.2. Cascading Style Sheets (CSS)

CSS es un lenguaje de hojas de estilo utilizado para describir la presentación deun documento escrito en HTML. Describe cómo deben representarse los elementos enla pantalla. Es uno de los idiomas principales de la web y está estandarizado en todoslos navegadores web de acuerdo con la especificación W3C. Desarrollado en niveles,CSS1 ahora está obsoleto, CSS2.1 es una recomendación y CSS3, ahora dividido enmódulos más pequeños, está progresando en la pista de estandarización [31].

22

Estado del arte

CSS está diseñado para permitir la separación de la presentación y el contenido,que incluye el diseño, los colores y las fuentes. Esta separación puede mejorar laaccesibilidad al contenido, proporcionar más flexibilidad y control en la especificaciónde las características de presentación, permitir que varias páginas web compartanel formato al especificar el CSS relevante en un archivo .css separado y reducir lacomplejidad y la repetición en el contenido estructural [32].

Figura 19: Logo de CSS [32]

CSS puede tener más potencia si se utiliza Sass.

Sass

Sass es un lenguaje de secuencias de comandos que se interpreta o compila enCSS. SassScript es el lenguaje de script en sí. Sass consta de dos sintaxis. Utilizasangría para separar bloques de código y caracteres de nueva línea para separarreglas. La sintaxis más reciente, ”SCSS” (Sassy CSS), utiliza un formato de bloquecomo el de CSS [33].

Utiliza llaves para denotar bloques de código y puntos y comas para separar lasreglas dentro de un bloque. La sintaxis con sangría y los archivos SCSS recibentradicionalmente las extensiones .sass y .scss, respectivamente [33].

Es especialmente útil porque permite definir variables en los ficheros de CSS quepueden reutilizarse, y así no tener que cambiar muchas líneas cuando se modificaun valor que se estuviera utilizando numerosas veces.

2.3.3. JavaScript

JavaScript (JS) es un lenguaje de programación ligero e interpretado. Si bien esmás conocido como el lenguaje de secuencias de comandos para páginas web, mu-chos entornos que no son del navegador web también lo usan, como Node.js, ApacheCouchDB y Adobe Acrobat. JavaScript es un lenguaje dinámico basado en proto-tipos, multi-paradigma, de un solo hilo, y que admite estilos orientados a objetos,imperativos y declarativos (por ejemplo, programación funcional) [34].

Figura 20: Logo de JavaScript [35]

El estándar para JavaScript es ECMAScript. A partir de 2012, todos los navega-dores modernos son totalmente compatibles con ECMAScript 5.1. El 17 de junio de

23


2015, ECMA International publicó la sexta versión principal de ECMAScript, que ofi-cialmente se llama ECMAScript 2015, y que inicialmente se denominó ECMAScript6 o ES6. Desde entonces, los estándares ECMAScript se lanzan anualmente. Actual-mente la última versión preliminar es ECMAScript 2020 [34].

2.3.4. TypeScript

TypeScript es un lenguaje de programación de código abierto desarrollado y man-tenido por Microsoft. Es un superconjunto sintáctico estricto de JavaScript y agregauna escritura estática opcional al lenguaje. TypeScript está diseñado para el desa-rrollo de grandes aplicaciones. Al ser un superconjunto de JavaScript, los programasque están escritos en JavaScript, también son programas válidos en TypeScript [36].

Como es un superconjunto de JavaScript, tiene los mismo usos que JavaScript,pero le añade ciertas características.

Admite archivos de definición que pueden contener información de tipado de bi-bliotecas JavaScript existentes, al igual que los archivos de encabezado de C++ pue-den describir la estructura de los archivos de objetos existentes. Esto permite queotros programas usen los valores definidos en los archivos como si fueran entidadesTypeScript escritas estáticamente. Hay archivos de encabezado de terceros para bi-bliotecas populares como jQuery o MongoDB. Los encabezados TypeScript para losmódulos básicos de Node.js también están disponibles, lo que permite que el desa-rrollo de programas Node.js con TypeScript sea sencillo [36].

Actualmente el framework Angular utiliza TypeScript como lenguaje aunque ini-cialmente utilizaba JavaScript. Esta decisión fue polémica porque la comunidad dedesarrolladores web conocía JavaScript pero era reticente a empezar a utilizar Ty-peScript. No obstante, conforme ha pasado el tiempo, TypeScript ha demostrado serun lenguaje muy potente y cada vez son más los desarrolladores web que prefierenutilizar TypeScript frente a JavaScript por sus numerosas ventajas.

2.3.5. Node Packet Manager (NPM)

Npm (Node Package Manager) es un administrador de paquetes para el lenguajede programación JavaScript. Es el administrador de paquetes predeterminado parael entorno de tiempo de ejecución de JavaScript Node.js. Consiste en un cliente delínea de comando, también llamado npm, y una base de datos en línea de paquetespúblicos y privados (de pago), llamado registro npm [37].

Se accede al registro a través del cliente, y los paquetes disponibles se pueden na-vegar y buscar a través del sitio web npm. El administrador de paquetes y el registroson administrados por npm, Inc. [37].

Figura 21: Logo de NPM [37]

Npm se incluye como una característica recomendada en el instalador de Node.js.Permite a los usuarios consumir y distribuir módulos JavaScript que están disponi-bles en el registro. Los paquetes en el registro están en formato CommonJS e incluyenun archivo de metadatos en formato JSON llamado package.json [37].

24

Estado del arte

Más de 477,000 paquetes están disponibles en el registro principal de npm. Npmse basa en informes de usuarios para eliminar paquetes si violan las políticas por serde baja calidad, inseguros o maliciosos. También expone estadísticas que incluyenel número de descargas y el número de paquetes dependientes para ayudar a losdesarrolladores a juzgar la calidad de los paquetes [37].

Es importante entender qué es npm porque es el gestor de paquetes de cualquierframework que utilice JavaScript o TypeScript para gestionar las versiones de susdependencies.

2.3.6. JavaScript Object Notation (JSON)

JSON (JavaScript Object Notation) es un formato ligero de intercambio de da-tos. Es fácil de leer y escribir para las personas. Es fácil de analizar y generar paralas máquinas. Se basa en un subconjunto del lenguaje de programación JavaScriptStandard ECMA-262 3rd Edition - December 1999 [38].

JSON es un formato de texto que es completamente independiente del lenguajepero utiliza convenciones que son familiares para los programadores de la familiade lenguajes C, incluido C, C++, C#, Java, JavaScript, Perl, Python y muchos otros.Estas propiedades hacen de JSON un lenguaje ideal para el intercambio de datos[38].

Figura 22: Logo de JSON [38]

JSON se compone de dos estructuras [38]:

• Una colección de pares nombre - valor. En varios idiomas, esto se conoce comoun objeto, registro, estructura, diccionario, tabla hash, lista con clave o matrizasociativa.

• Una lista ordenada de valores. En la mayoría de los idiomas, esto se realizacomo una matriz, vector, lista o secuencia.

25

Un objeto es un conjunto no ordenado de pares nombre - valor. Un objeto comienzacon ”” y termina con ””. Cada nombre es seguido por ”:” y los pares nombre - valorestán separados por ”,” [38].

Figura 23: Objeto JSON [38]

Una matriz (array) es una colección ordenada de valores. Una matriz comienza con”[” y termina con ”]”. Los valores están separados por ”,” [38].

Figura 24: Matriz JSON [38]

Un valor puede ser un string entre comillas dobles, un número, verdadero, falso,nulo, un objeto o una matriz. Estas estructuras pueden estar anidadas [38].

Figura 25: Valor JSON [38]

Un string es una secuencia de cero o más caracteres Unicode, entre comillas do-bles, usando escapes de barra invertida. Un carácter se representa como un stringúnico [38].

Figura 26: String JSON [38]

Un número es muy parecido a un número C o Java, excepto que los formatos octaly hexadecimal no se usan [38].

Figura 27: Número JSON [38]

Se puede insertar un espacio en blanco (Whitespace) entre cualquier par de tokens.Exceptuando algunos detalles de codificación, que describe completamente el idioma[38].

Figura 28: Espacios en blanco en JSON [38]

2.3.7. Angular

Angular es un framework de desarrollo web, es decir, ofrece un marco de trabajocon todos los elementos necesarios para desarrollar página web de forma rápida ycompleta.

Estado del arte

Normalmente se le conoce como Angular2 o Angular 2 y superiores, esto se debe aque originalmente se llamaba AngularJS y estaba escrito en JavaScript, pero desde laversión 2 en adelante adoptó TypeScript como lenguaje de programación y se rediseñoen gran medida.

Figura 29: Logo de Angular [39]

Angular se basa en el concepto de componentes, en el cual ciertas partes de códigose agrupan en un componente el cual tiene su HTML para definir los elementos,su CSS para definir cómo se ven y su TypeScript para definir su comportamiento.Un componente puede ser, por ejemplo, un botón de cierto tipo o el campo de unformulario.

Angular trabaja con herencia de componentes, de modo que un componente puedautilizar en su HTML otros componentes que serían hijos suyos. También define unaserie de Inputs y Outputs para que los componentes padre se comuniquen con loscomponentes hijo y viceversa.

2.3.8. React

React es una biblioteca en JavaScript para construir interfaces de usuario. Esmantenido por Facebook y por una comunidad de desarrolladores y empresas indivi-duales [40].

Figura 30: Logo de React [40]

React se puede utilizar como base en el desarrollo de aplicaciones de aplicacionesweb single-page. Sin embargo, a React solo le interesa procesar los datos en el DOM,por lo que la creación de aplicaciones React generalmente requiere el uso de biblio-tecas adicionales para la administración y el enrutamiento del estado. Redux y ReactRouter son ejemplos respectivos de tales bibliotecas [40].

El código de React está formado por entidades llamadas componentes. Los com-ponentes se pueden renderizar en un elemento particular en el DOM utilizando labiblioteca React DOM. Al representar un componente, uno puede pasar valores quese conocen como ’props’. Las dos formas principales de declarar componentes enReact son a través de componentes funcionales y de componentes basados en clases[40].

Los componentes basados en clases se declaran usando clases ES6. También seconocen como componentes ”con estado” porque su estado puede contener valores

29


en todo el componente y puede pasarse a componentes secundarios a través de ac-cesorios [40].

Una característica notable de React es el uso de un DOM virtual. React crea unacaché de estructura de datos en memoria, calcula las diferencias resultantes y luegoactualiza el DOM visualizado en navegador de manera eficiente. Esto permite al pro-gramador escribir código como si la página completa se procesara en cada cambio,mientras que las bibliotecas React solo representan subcomponentes que realmentecambian [40].

2.3.9. Vue.js

Vue.js es un framework en JavaScript, de código abierto y que utiliza Modelo-Vista-Controlador para construir interfaces de usuario y aplicaciones web single-page. Fuecreado por Evan You, y lo mantienen él y el resto de los miembros activos del equipocentral provenientes de varias compañías como Netlify y Netguru [41].

Figura 31: Logo de Vue [41]

Presenta una arquitectura incrementalmente adoptable que se enfoca en la re-presentación declarativa y la composición de componentes. Las funciones avanzadasrequeridas para aplicaciones complejas como enrutamiento, administración de esta-do y herramientas de compilación se ofrecen a través de bibliotecas y paquetes desoporte mantenidos oficialmente, con Nuxt.js como una de las soluciones más popu-lares [41].

Permite extender HTML con atributos HTML llamados directivas. Las directivasañaden funcionalidad al HTML y pueden ser directivas integradas o definidas por elusuario [41].

2.3.10. WordPress

WordPress es un sistema de gestión de contenido gratuito y de código abierto escri-to en PHP y emparejado con una base de datos MySQL o MariaDB. Las característicasincluyen una arquitectura de plugins y un sistema de plantillas, denominado dentrode WordPress como temas [42].

Figura 32: Logo de WordPress [42]

WordPress se creó originalmente como un sistema de publicación de blogs, peroha evolucionado para admitir otros tipos de contenido web, incluidas listas de correoelectrónico y foros más tradicionales, galerías multimedia, sistemas de gestión deaprendizaje y tiendas online [42].

30

Estado del arte

WordPress es utilizado por más de 60 millones de sitios web, incluyendo el 33.6 %de los 10 millones de sitios web principales a partir de abril de 2019, WordPress esuna de las soluciones de sistema de administración de contenido más populares enuso [42].

WordPress es tan utilizado porque no requiere conocimientos de programación nide desarrollo de páginas web. Ofrece plantillas que sirven para determinados proto-tipos de páginas web y permite editarlas visualmente. No obstante no es tan perso-nalizable como puede ser una página web desarrollada con uno de los frameworksmencionados previamente, por lo que los desarrolladores web no suelen utilizar Word-Press.

2.4. Protocolos de comunicación

En esta sección se explica brevemente el funcionamiento de los protocolos de co-municación que se utilizan durante la comunicación entre dispositivos a través deinternet. Esto incluye por ejemplo a la comunicación entre dos servidores, entre unservidor y un navegador o entre un servidor un una aplicación móvil.

2.4.1. Hypertext Transfer Protocol (HTTP)

HTTP es un protocolo de nivel de aplicación que sirve para transmitir documentoshipermedia, como HTML. Fue diseñado para la comunicación entre navegadores weby servidores web, pero también se puede utilizar para otros fines. HTTP sigue unmodelo clásico de cliente-servidor, con un cliente que abre una conexión para realizaruna solicitud y luego espera hasta que reciba una respuesta [43].

Figura 33: Logo de HTTP [44]

Es un protocolo sin estado, lo que significa que el servidor no mantiene ningúnestado entre dos solicitudes. Aunque a menudo se usa sobre TCP/IP, se puede usarsobre cualquier capa de nivel de transporte confiable, es decir, un protocolo que nopermita la pérdida de mensajes como hace UDP. RUDP, la actualización confiable deUDP, es una alternativa adecuada [43].

El cliente envía un mensaje de solicitud HTTP al servidor. El servidor, que pro-porciona recursos como archivos HTML y otro contenido, o realiza otras operacionesen nombre del cliente, devuelve un mensaje de respuesta al cliente. La respuestacontiene información sobre el estado de finalización de la solicitud y también puedecontener contenido, si procede, en el cuerpo del mensaje de respuesta [44].

Los recursos HTTP se identifican y localizan en internet por URLs (Uniform Re-source Locators), usando los esquemas URI (Uniform Resource Identifier) de HTTP.

Estos elementos permiten identificar a quién se realiza una petición HTTP, sobreque puerto y sobre que ruta, y si tiene argumentos adicionales.

HTTP define un conjunto de métodos de solicitud para indicar la acción que sedesea realizar para un recurso dado. Cada uno de ellos implementa una semántica

31

2.4. Protocolos de comunicación

Figura 34: Componentes de HTTP [44]

diferente, pero algunas características comunes son compartidas por un grupo deellos: e.g. un método de solicitud puede ser seguro, idempotente o almacenable encaché [45].

Los métodos de solicitud HTTP son los siguientes [45]:

• GET: El método GET solicita una representación del recurso especificado. Lassolicitudes que usan GET solo deben recuperar datos.

• HEAD: El método HEAD solicita una respuesta idéntica a la de una solicitudGET, pero sin el cuerpo de la respuesta.

• POST: El método POST se usa para enviar una entidad al recurso especificado,lo que a menudo causa un cambio en el estado o efectos secundarios en elservidor.

• PUT: El método PUT reemplaza todas las representaciones actuales del recursode destino con la carga útil de la solicitud.

• DELETE: El método DELETE elimina el recurso especificado.

• CONNECT: El método CONNECT establece un túnel para el servidor identificadopor el recurso de destino.

• OPTIONS: El método OPTIONS se usa para describir las opciones de comunica-ción para el recurso de destino.

• TRACE: El método TRACE realiza una prueba de bucle de mensajes a lo largode la ruta al recurso de destino.

• PATCH: El método PATCH se usa para aplicar modificaciones parciales a unrecurso.

Cuando introducimos una URL en un navegador web, éste realiza una peticiónHTTP con el método GET, a lo cual el servidor le responde con ciertos ficheros (HTML,CSS y JavaScript) que permiten que el navegador nos muestre lo que vemos.

2.4.2. WebSocket

Websocket es un protocolo de comunicaciones que proporciona canales de comu-nicación full-duplex a través de una única conexión TCP [46].

Esto quiere decir que cuando se establece un canal websocket entre un clientey un servidor tanto el cliente como el servidor pueden enviar mensajes a través dedicho canal indistintamente.

32

Estado del arte

El protocolo websocket fue estandarizado por el IETF como RFC 6455 en 2011, yla API websocket en web IDL está siendo estandarizada por el W3C [46].

Websocket es distinto a HTTP, pero ambos protocolos están ubicados en el nivelde. Aunque son diferentes, RFC 6455 establece que websocket ”está diseñado parafuncionar sobre los puertos HTTP 80 y 443, así como para admitir proxies e interme-diarios HTTP”, por lo que es compatible con el protocolo HTTP. Para lograr la com-patibilidad, el protocolo de enlace websocket utiliza el encabezado de actualizaciónHTTP para cambiar del protocolo HTTP al protocolo websocket [46].

Para establecer una conexión websocket, el cliente envía una solicitud de enlacewebsocket, para la cual el servidor devuelve una respuesta de enlace websocket, comose muestra en el ejemplo a continuación [46].

Figura 35: Solicitud de enlace WebSocket [46]

Figura 36: Respuesta de enlace WebSocket [46]

Cuando un cliente websocket intenta establecer una conexión tendrá que escucharuna serie de eventos, estos eventos son:

• open: El evento open se produce cuando la conexión websocket se establececorrectamente.

• error: El evento error se produce cuando hay algún tipo de error, tanto si seproduce al intentar abrir la conexión como si se produce durante una conexiónestablecida.

• close: El evento close se produce cuando se cierra la conexión. Este cierre puedeproducirse porque alguno de los dos extremos la ha cerrado intencionadamenteo porque se ha producido un error. En caso se ser por un error, primero seproduce el evento de error y luego el evento de close. El evento de close tiene uncódigo asociado que indica por qué se produjo el cierre de la conexión.

• message: El evento message sólo puede producirse durante una conexión esta-blecida correctamente. Se produce cuando el participante del otro extremo envíaun mensaje a través de la conexión.

33

2.5. Comunicación en tiempo real

Puesto que los mensajes a través de websocket se envían mediante el evento mes-sage, no sigue los mismo principios de HTTP que tiene distintos métodos para ciertasoperaciones. Por eso se suele definir un protocolo de intercambio de mensajes y aña-dir a los mensajes algún distintivo, como por ejemplo un cambio ”tipo”.

Los mensajes que se envían a través de una conexión websocket son texto plano,por lo que si se utiliza alguna estructura de mensajes como JSON o XML, estos debe-rán serializados para convertiros a texto antes de ser enviados y ser de-serializadosal recibirlos para convertirlos de texto plano a la estructura que se esté utilizando.

2.4.3. Server-Sent Events (SSE)

La conexión debe ser abierta por un cliente, y dicho cliente escucha eventos simi-lares a los que se utilizan en el protocolo de websocket.

La principal diferencia entre websocket y sse es que websocket es un protocoloque permite que los dos extremos envíen y reciban información, mientras que enserver side events el único que recibe información es el cliente y el único que envíainformación es el servidor.

En sse existen ciertos eventos parecidos a los del protocolo websocket:

• open: El evento open cuando se establece el canal de comunicación entre elcliente y el servidor

• error: se produce cuando se pierde la comunicación con el servidor, pero pordefecto los navegadores web intentan reconectar cada 3 segundos.

• no existe evento close: El evento close de websocket no existe, pues el servidorno puede cerrar una conexión de este tipo. Es el cliente el que decide cuandodejar de escuchar los eventos que envía el servidor.

• message: El evento message se produce cuando el servidor envía un mensajesin especificar el tipo de mensaje.

• event: Se pueden producir otros eventos personalizados, cuando el servidorenvía el evento deberá enviar por un lado el nombre del evento y por otro ladolos datos del evento.

En resumen, sse es útil cuando un servidor quiere enviar eventos a los clientespero no recibir información a través del canal. Es más eficiente que el clásico polling,en el cual el cliente tiene que estar haciendo peticiones periódicas al servidor paraver si se han producido cambios.

2.5. Comunicación en tiempo real

La comunicación en tiempo real es aquella en la que todos los participantes recibenla información del resto sin retraso.

Existen distintos formas de lograr una comunicación en tiempo real, pero en estasección se van a explicar aquellas que son especialmente relevantes para el desarrollode este proyecto porque son las que se están desarrollando actualmente en el proyectoPEMEA.

34

Estado del arte

2.5.1. Mensajería Instantánea

La mensajería instantánea es una forma de comunicación en la que dos usuariosse envían información en forma de mensajes sin retraso en su recepción.

Un ejemplo de un servicio de mensajería instantánea es un chat. Cuando unapersona envía un mensaje en un chat, este se recibe inmediatamente salvo que fallela conectividad de alguno de los miembros con el servidor.

Un chat puede ser entre dos personas o entre más de dos personas si se tratade una sala de chat. En este segundo caso los mensajes que envía una persona sonrecibidos por todos los demás usuarios que se encuentran en esa sala.

Si pensamos en cómo debería comportarse un servidor de chat a nivel de protocolo,se trata de un servidor que va a recibir muchos mensajes y que tiene que redirigirlos alas personas correspondientes rápidamente. El protocolo que mejor se adapta a estasnecesidades es sin duda el protocolo websocket, mediante el cual los integrantes dela sala tendrán una conexión websocket abierta con el servidor de chat, y cuandoenvíen un mensaje a través de la conexión websocket, los demás usuarios recibiránel mensaje como un evento message a través de la conexión websocket.

No obstante el servidor utilizará websocket únicamente para el flujo de mensajes,pero el resto de operaciones puede realizarse mediante HTTP, e.g. identificar a unusuario, editar información del usuario, etc.

2.5.2. Web Real-Time Communication (WebRTC)

WebRTC es una tecnología que permite a las aplicaciones y sitios web capturary transmitir audio y/o video, así como intercambiar datos arbitrarios entre navega-dores sin necesidad de un intermediario. El conjunto de estándares que comprendeWebRTC permite compartir datos y realizar teleconferencias punto a punto, sin re-querir que el usuario instale complementos o cualquier otro software de terceros [48].

WebRTC consta de una API en JavaScript que implementan todos los navegadoresweb modernos, mientras que los back end suelen tener librerías que se encargan delcomportamiento de WebRTC en el servidor.

Figura 37: Logo de WebRTC [49]

WebRTC junto con la API de Media Capture y Streams brindan potentes capaci-dades multimedia a la web, que incluyen soporte para conferencias de audio y video,intercambio de archivos, uso compartido de pantalla, gestión de identidad e interfazcon sistemas telefónicos heredados, incluido soporte para enviar DTMF (touch-tonedialing). Las conexiones entre extremos se pueden hacer sin necesidad de controla-dores o complementos especiales, y a menudo se pueden hacer sin ningún servidorintermediario [48].

No obstante, no todos los navegadores utilizan la misma codificación para el audioy el vídeo, de modo que a veces debe existir un servidor multimedia intermedio quepermita la compatibilidad total.

35

2.6. Control de versiones

También hay que tener en cuenta que los dispositivos de los usuarios normalmentese encuentran detrás de NATs, lo que impide que se produzca un flujo de informaciónUDP entre los usuarios. Esto se resuelve utilizando servidores con IP pública quehacen de intermediarios entre los dos usuarios. Pueden ser servidores STUN o TURN.


Cualquier desarrollador de software conoce la importancia de disponer de un con-trol de versiones cuando se escribe código de cualquier tipo. La utilidad del controlde versiones no se aplica solo al código, también puede aplicarse a documentos queno sean únicamente texto.

Un sistema de control de versiones permite guardar ficheros en el estado en elque se encuentran en cierto momento, de modo que si se han modificado, se puedahacer que vuelvan a ser como eran en el instante en el que se guardaron. Es, por asídecirlo, una especie de guardar ficheros.

También es importante que entre cada vez que se guardan cambios se pueda veren qué se modificaron los ficheros para poder tener un registro de los cambios. Encaso de ficheros complejos puede ser difícil conseguir esto, pero cuando hablamos decódigo, que es mayormente texto plano, sólo hay que comparar línea por línea si sehan añadido, eliminado o modificado cosas.

El sistema de control de versiones más utilizado por los desarrolladores de softwa-re es Git.

Git tiene un sistema de ramas, que permite partir de un cierto estado de los fi-cheros, crear una rama diferente a en la que se encontraban los ficheros, y empezara realizar cambios sin afectar a la rama original para que en el momento en quelas funcionalidades añadidas se hayan probado y funcionen, puedan aplicarse sobrela rama original. Esto permite que varios desarrolladores trabajen con el código delmismo proyecto colaborativamente.

Partiendo de Git como base, se han creado distintos proyectos que añaden o mo-difican algunas de las funcionalidades que ofrece Git. Los más relevantes son que semencionan a continuación.

2.6.1. GitLab

GitLab es una herramienta de ciclo de vida DevOps (Desarrollo y Operaciones) ba-sada en la web que proporciona un administrador de repositorio Git que proporcio-na características wiki, seguimiento de bugs e integración continua/implementacióncontinua, utilizando una licencia de código abierto, desarrollada por GitLab Inc [51].

Figura 38: Logo de GitLab [50]

Permite asignar permisos a las ramas de Git, cosa que no permite GitHub. Estopermite que se puede trabajar mejor colaborativamente entre miembros de un equipo

36

Estado del arte

de desarrollo al poder proteger las ramas principales y que sólo los miembros con másexperiencia y responsabilidad del equipo puedan aceptar fusiones de ramas de otrosusuarios en las ramas protegidas.

Ofrece también una cadena de herramientas completa de Integración Continua/En-trega Continua (CI/CD) en una sola aplicación [51].

Figura 39: GitLab todo en uno [51]

En la práctica, GitLab termina teniendo todo lo que ofrece GitHub pero tiene bas-tantes funcionalidades añadidas.

La principal fuerza de GitHub es la resistencia de la gente al cambio. GitHub selanzó en 2008 y fue llenándose de proyectos, mientras que GitLab se lanzó en 2014,por lo que GitHub tuvo 6 años para atraer a la mayor parte de los desarrolladores. Eslo mismo que pasa entre WhatsApp y Telegram, aunque telegram ofrece más funcio-nalidades que WhatsApp, los usuarios son fieles a WhatsApp porque tienen a todossus contactos utilizando WhatsApp, hay una gran resistencia al cambio.

2.6.2. GitHub

GitHub, Inc. es una compañía global con sede en los Estados Unidos que ofrecealojamiento para el control de versiones de desarrollo de software utilizando Git. Ofre-ce el control de versiones distribuidas y la funcionalidad de gestión de código fuentede Git, además de sus propias características. Proporciona control de acceso y variasfunciones de colaboración, como seguimiento de errores, solicitudes de funciones,gestión de tareas y wikis para cada proyecto [52].

37


Figura 40: Logo de GitLab [52]

Los proyectos en GitHub pueden ser accedidos y manipulados utilizando la inter-faz de línea de comandos estándar de Git y acepta todos los comandos estándar deGit. GitHub también permite a los usuarios registrados y no registrados navegar porrepositorios públicos. Múltiples clientes de escritorio y complementos de Git tambiénhan sido creados por GitHub y otros terceros que se integran con la plataforma [52].

Proporciona funciones similares a las redes sociales, como feeds, seguidores, wikisy un gráfico de red social para mostrar cómo los desarrolladores trabajan en susversiones (”forks”) de un repositorio y qué rama es la más nueva [52].

Un usuario debe crear una cuenta para contribuir con contenido, pero cualquierpersona puede navegar y descargar repositorios públicos. Con una cuenta de usuarioregistrada, los usuarios pueden tener discusiones, administrar repositorios, enviarcontribuciones a los repositorios de otros y revisar los cambios al código. GitHubcomenzó a ofrecer repositorios privados ilimitados sin costo en enero de 2019. Ante-riormente, solo los repositorios públicos eran gratuitos [52].

El 14 de abril de 2020, GitHub hizo ”todas las funcionalidades principales deGitHub” gratuitas para todos, incluidos ”repositorios privados con colaboradores ili-mitados” [52].

Además de alojar el código fuente, GitHub admite los siguientes formatos y carac-terísticas [52]:

• Documentación, incluidos los archivos README renderizados automáticamenteen una variedad de formatos de archivo tipo Markdown.

• Seguimiento de problemas (issues) con etiquetas, hitos, posibilidad de asignar-las a personas y un motor de búsqueda.

• Wikis.

• Pull requests con revisión de código y comentarios.

• GitHub Actions, que permite construir una integración continua y pipelines deimplementación continua para probar, lanzar e implementar software sin el usode sitios web/plataformas de terceros.

• Historial de commits.

• Gráficos: contribuyentes, confirmaciones, frecuencia de código, red, miembros.

• Diferenciaciones de código unificadas y divididas.

• Notificaciones por correo electrónico.

• Opción de suscribir a alguien a las notificaciones mencionándole con @.

• Emojis.

38

Estado del arte

• Páginas de GitHub: se pueden alojar pequeños sitios web desde repositoriospúblicos en GitHub. El formato de URL es https://username.github.io.

• Listas de tareas anidadas dentro de archivos.

• Visualización de datos geoespaciales.

• Archivos de renderizado 3D que se pueden previsualizar utilizando un nuevovisor de archivos STL integrado que muestra los archivos en un ”canvas 3D”. Elvisor funciona con WebGL y Three.js.

• El formato PSD nativo de Photoshop se puede previsualizar y comparar conversiones anteriores del mismo archivo.

• Visor de documentos PDF.

• Alertas de seguridad de vulnerabilidades y exposiciones comunes conocidas endiferentes paquetes.

El 4 de junio de 2018, Microsoft anunció su intención de adquirir GitHub por7,5 mil millones de dólares, y el acuerdo se cerró el 26 de octubre de 2018. SegúnMicrosoft, GitHub continuará operando independientemente como comunidad, plata-forma y negocio. Microsoft se había convertido en un usuario importante de GitHub,usándolo para alojar proyectos de código abierto y herramientas de desarrollo co-mo Chakra Core, PowerShell, Visual Studio Code y Windows Terminal. También harespaldado otros proyectos de código abierto como Linux, y desarrolló Virtual FileSystem para Git, que es una extensión de Git para administrar repositorios a granescala que ha sido adoptada por GitHub) [52].

2.6.3. Bitbucket

Bitbucket es un servicio de alojamiento de repositorio de control de versiones ba-sado en web propiedad de Atlassian, para código fuente y proyectos de desarrollo queutilizan sistemas de control de revisión Mercurial (desde el lanzamiento hasta el 1 dejunio de 2020) o Git (desde octubre de 2011) [53].

Bitbucket ofrece planes comerciales y cuentas gratuitas. Ofrece cuentas gratui-tas con un número ilimitado de repositorios privados (que pueden tener hasta cincousuarios en el caso de cuentas gratuitas) a partir de septiembre de 2010. Bitbucketse integra con otro software de Atlassian como Jira, HipChat, Confluence y Bamboo[53].

Figura 41: Logo de Bitbucket [54]

Es similar a GitHub, que utiliza principalmente Git. Bitbucket ha comercializadotradicionalmente sus servicios a desarrolladores profesionales con código de softwareprivado, especialmente desde que fue adquirido por Atlassian en 2010. En febrerode 2017, Bitbucket anunció que había alcanzado 6 millones de desarrolladores y 1millón de equipos en su plataforma. En abril de 2019, Atlassian anunció que Bitbuc-ket alcanzó 10 millones de usuarios registrados y más de 28 millones de repositorios[53].

39

2.7. Conocimientos previos

2.7. Conocimientos previos

Previamente al desarrollo de este proyecto, disponía de conocimientos adquiridosdurante el estudio del Grado en Ingeniería Informática de la Universidad Politécnicade Madrid, durante el estudio del Máster Universitario en Ingeniería Informática dela Universidad Politécnica de Madrid y durante el tiempo trascurrido trabajando conDeveryware que comenzó en Febrero de 2018.

De modo que disponía un buen nivel de conocimientos de las siguientes tecnolo-gías relevantes para el desarrollo de este proyecto:

• HTML.

• CSS.

• JavaScript.

• TypeScript.

• NPM.

• JSON.

• Angular.

• HTTP.

• WebSocket.

• Mensajería instantánea.

• WebRTC.

• Git.

2.8. Conocimientos adquiridos

Después del desarrollo de este proyecto, he obtenido principalmente un buen nivelde conocimiento en Ionic al haber realizado el desarrollo de la aplicación con dichoframework. También he mejorado el nivel de conocimiento de algunas de las tecnolo-gías que ya conocía previamente.

He obtenido también cierto conocimiento de las siguientes tecnologías:

• React.

• React Native.

• Xcode.

• TestFlight.

• Android.

• iOS.

40

Capítulo 3

Análisis y comparativa de losframeworks

Cuando se quiere desarrollar una aplicación móvil es conveniente dedicar tiempoa pensar qué dirección tomar antes de iniciar el desarrollo.

Lo más común es pensar en realizar una aplicación para iOS y otra para Android,pero esto tiene algunos problemas que deben considerarse. Esta solución implicatener que realizar el desarrollo de una aplicación Android y el desarrollo de unaaplicación iOS nativas, puesto que cada sistema operativo se comporta de maneradiferente y cada uno tiene sus particularidades.

También hay que pensar si se quiere disponer también de una aplicación web,no sólo de una aplicación móvil. Una aplicación web puede ser una buena opciónsi se quiere que los usuarios puedan utilizar también la aplicación desde ordenado-res con Windows, MacOS o Linux, puesto que todos podrían usarla a través de susnavegadores web.

Otro aspecto a considerar es el tipo de empresa y de qué equipo se dispone parael desarrollo de la aplicación:

• Para una empresa que disponga de un equipo de desarrollo de aplicacionesmóviles nativas y que quiera desarrollar una aplicación Android y una aplica-ción iOS, la mejor opción será desarrollar la aplicación como nativa porque losdesarrolladores ya tienen experiencia y conocimiento de esa tecnología.

• Para una empresa que disponga de un equipo de desarrollo de aplicacionesweb pero no disponga de desarrolladores de aplicaciones nativas, será muchomás eficiente que el equipo desarrolle una aplicación híbrida que pueda desarro-llarse usando HTML, CSS y JavaScript, puesto que ya tienen experiencia en esetipo de tecnologías y la empresa no necesitará contratar nuevos desarrolladorespara ese proyecto.

• Para una empresa que no disponga de un equipo de desarrollo todavía y quevaya a tener que contratar personal para desarrollar la aplicación, lo primero espensar en que dispositivos se necesita que funcione la aplicación. Si se quiereque sea sólo en los dispositivos móviles se podría contratar un equipo de desa-rrollo de aplicaciones nativas Android y otro para iOS. Pero se podría contratar

41

3.1. PWA

un único equipo de desarrollo de aplicaciones híbridas que desarrollara tanto laaplicación Android como la aplicación iOS con un único código común. Comoañadido, si se usa un framework que funcione con tecnologías web (HTML, CSSy JavaScript), podrían generar una aplicación web con el mismo código.

El desarrollo de aplicaciones móviles nativas está fuera del ámbito de este proyectopero se va a analizar cómo se desarrollan las aplicaciones híbridas.

Una aplicación híbrida es una aplicación que se programa una única vez y sepuede desplegar tanto en smartphones como en navegadores web.

3.1. Progressive Web Applications (PWAs)

Google ideó las Progressive Web Applications (PWAs) para intentar que las aplica-ciones web se comporten como aplicaciones móviles nativas.

Para ello es necesario que se utilicen de la misma forma, es decir, como una apli-cación en el menú home del smartphone. Se diseñó una API que permite que la apli-cación web se instale en el smartphone, para ello deberá abrirse la aplicación desdeel navegador web del smartphone, y dicha aplicación web puede sugerirle al usua-rio que la instale como aplicación del smartphone. Cuando se ejecute la aplicación,se abrirá una WebView con la aplicación web como si se tratara de una aplicaciónnativa.

Sin embargo las PWAs tienen dificultades a la hora de acceder a los elementos delpropio dispositivo (como puede ser NFC, utilizar el sistema de ficheros, acceder a lawifi, interactuar con la barra de estado, etc.). Las PWAs están añadiendo librerías yherramientas que permiten que la aplicación funcione offline (cacheando contenido) yque utilicen notificaciones push del smartphone, pero todavía tienen mucho caminopor recorrer para poder utilizar funcionalidades más avanzadas de los dispositivosmóviles.

3.2. Frameworks de desarrollo de aplicaciones híbridas

Un framework es un marco de trabajo que ofrece ciertas herramientas para fa-cilitar y agilizar el trabajo, es decir, ofrece herramientas muy potentes para que losdesarrolladoras las utilicen en lugar de tener que dedicar una gran cantidad de tiem-po a construirlas.

Cuando se quiere utilizar un determinado framework, es importante saber si setrata de un framework fiable, con un buen mantenimiento y actualizaciones perió-dicas. También es preferible que haya una amplia comunidad utilizando dicho fra-mework, pues esto ayuda a encontrar bugs o carencias del framework de cara a irperfeccionándolo.

Un framework de aplicaciones híbridas ofrece las herramientas necesarias paradesarrollar aplicaciones híbridas de forma rápida y eficiente, permitiendo desarrollartanto las funcionalidades de la aplicación como el estilo visual. También ofrece he-rramientas para compilarla la aplicación y construir paquetes que puedan utilizarseen distintos dispositivos.

42

Análisis y comparativa de los frameworks

El hecho de que desde el principio las páginas web se hayan podido utilizar tan-to en ordenadores como en dispositivos móviles a través de los navegadores web haderivado en que existan muchos profesionales que han trabajado con páginas o apli-caciones web. Estos profesionales normalmente prefieren, si es posible, poder utilizarlas mismas herramientas que ya conocen para desarrollar aplicaciones móviles en vezde tener que aprender las tecnologías necesarias para el desarrollo nativo.

Por ello, los frameworks de desarrollo de aplicaciones híbridas suelen preferir tra-bajar con tecnologías similares a las de desarrollo de aplicaciones web (HTML, CSS,JavaScript), y construir tanto las aplicaciones web, como las aplicaciones Android eiOS nativas a partir de dicho código.

A continuación se va a realizar un análisis de los principales frameworks de desa-rrollo de aplicaciones híbridas.

3.2.1. Ionic

Ionic es un framework de código abierto para el desarrollo de aplicaciones móvileshíbridas creado en 2013. La versión original fue lanzada en 2013 y construida sobreApache Cordova y AngularJS (La primera versión del framework Angular que utilizabaJavaScript en vez de TypeScript) [55].

Figura 42: Logo de Ionic [55]

Ionic utiliza Cordova y Capacitor para montar la aplicación web como un elementoWebView nativo en el dispositivo. Para utilizar las funciones nativa existen pluginspara Cordova y Capacitor, y si la funcionalidad deseada no tiene todavía un plu-gin disponible, siempre se puede crear uno con código nativo de cada plataforma yañadirlo al proyecto. Actualmente Córdova tiene más plugins y mejor soporte queCapacitor.

En la versión 2, Ionic adoptó la nueva versión de Angular, usando a partir de en-tonces TypeScript. En la versión 4 se reconstruyó como un conjunto de componentesweb, lo que permite al usuario elegir diferentes frameworks de desarrollo web pa-ra realizar la interfaz de usuario. Actualmente soporta Angular, React y Vue.js [55],aunque a Vue.js todavía no le está dando soporte oficial. No obstante React no fun-ciona con Cordova ni se le pretende dar soporte, está obligado a utilizar Capacitor,que actualmente tiene menos plugins que Córdova.

También permite el uso de componentes de Ionic sin ningún marco de interfazde usuario. Ionic proporciona herramientas y servicios para desarrollar aplicacionesweb, móviles, de escritorio y progresivas (PWA) basadas en tecnologías y prácticasmodernas de desarrollo web, utilizando tecnologías web como HTML, CSS y Sass.Las aplicaciones móviles creadas con Ionic pueden construirse con estas tecnologíasweb y luego distribuirse a través de tiendas de aplicaciones nativas para instalarseen dispositivos utilizando Cordova o Capacitor [55].

43

3.2. Frameworks de desarrollo de aplicaciones híbridas

3.2.2. React Native

React Native es un framework de desarrollo de aplicaciones híbridas de códigoabierto creado por Facebook. Se utiliza para desarrollar aplicaciones para Android,iOS y web al permitir a los desarrolladores usar React junto con las capacidades dela plataforma nativa [56].

Figura 43: Logo de React Native [56]

Los principios de funcionamiento de React Native son prácticamente idénticos aReact, excepto que React Native no manipula el DOM a través del DOM virtual. Seejecuta en un proceso en segundo plano (que interpreta el JavaScript escrito por losdesarrolladores) directamente en el dispositivo final y se comunica con la plataformanativa a través de un puente serializado, asíncrono y por lotes [56].

React Native intenta seguir pareciendo HTML como hace React, pero añade unaserie de componentes propios que después convierte a elementos nativos. Estos com-ponentes se llaman componentes principales (Core Components). Por lo demás elfuncionamiento es bastante similar al de una aplicación web hecha con React.

En la figura 44 se pueden ver los componentes principales y sus análogos compo-nentes web y nativos.

Figura 44: Componentes principales de React Native [57]

En la figura 45 se puede ver la diferencia entre los distintos tipos de componentesde React y React Native.

44


Figura 45: Componentes de React Native [57]

React Native no usa HTML ni CSS. En su lugar, los mensajes del hilo de JavaScriptse utilizan para manipular las vistas nativas. También permite a los desarrolladoresescribir código nativo en lenguajes como Java para Android y Objective-C o Swift paraiOS que lo hacen aún más flexible [56].

3.2.3. Flutter

Flutter es un framework para el desarrollo de aplicaciones híbridas que se uti-liza para desarrollar aplicaciones para Android, iOS, Windows, Mac, Linux, GoogleFuchsia y la web [58].

Figura 46: Logo de Flutter [58]

La primera versión de Flutter se conocía como nombre en clave ”Sky” y se ejecuta-ba en el sistema operativo Android. Fue presentado en la cumbre de desarrolladoresde Dart de 2015. El 4 de diciembre de 2018, se lanzó Flutter 1.0 en el evento FlutterLive, que denota la primera versión ”estable” del framework. El 11 de diciembre de2019, se lanzó Flutter 1.12 en el evento Flutter Interactive [58].

Está formado por los siguientes componentes[58]:

• Plataforma Dart: Las aplicaciones Flutter están escritas en el idioma Dart yhacen uso de muchas de las funciones más avanzadas del idioma.

Las releases de las aplicaciones de Flutter se compilan con una compilación

45

3.3. Comparativa de funcionalidades

anticipada (AOT) tanto en Android como en iOS, haciendo posible el alto rendi-miento de Flutter en dispositivos móviles.

• Motor Flutter: El motor de Flutter, escrito principalmente en C++, proporcionasoporte de renderizado de bajo nivel utilizando la biblioteca de gráficos Skiade Google. Además, interactúa con SDK específicos de la plataforma, como losproporcionados por Android e iOS.

Implementa las bibliotecas principales de Flutter, que incluyen animación y grá-ficos, Entada/Salida de archivos y redes, soporte de accesibilidad, arquitecturade complementos y una cadena de herramientas de compilación y ejecución deDart. La mayoría de los desarrolladores interactúan con Flutter a través de Flut-ter Framework, que proporciona un marco de trabajo moderno y reactivo, y unrico conjunto de Widgets de plataforma, diseño y base.

• Biblioteca de la fundación: La biblioteca de fundación, escrita en Dart, pro-porciona clases y funciones básicas que se utilizan para construir aplicacionesusando Flutter, como las API para comunicarse con el motor.

El diseño de la interfaz de usuario en Flutter implica el uso de la composiciónpara crear ”Widgets” de otros Widgets. El truco para comprender esto es darsecuenta de que cualquier árbol de componentes (Widgets) que se ensambla bajoun solo método build() también se conoce como un único Widget. Esto se debe aque esos Widgets más pequeños también están formados por Widgets aún máspequeños, y cada uno tiene su propio método build(). Así es como Flutter haceuso de la composición.

• Widgets específicos de diseño: Flutter contiene dos conjuntos de Widgets quese ajustan a lenguajes de diseño específicos. Los Widgets de diseño de materialesimplementan el lenguaje de diseño de Google del mismo nombre, y los Widgetsde Cupertino implementan las pautas de la interfaz humana iOS de Apple.


Esta sección analiza las diferentes funcionalidades que tienen disponibles de for-ma nativa los smartphones, explicando para qué sirven y qué frameworks tienendisponible dicha funcionalidad.

Se va a reconoces que soportan las funcionalidades tanto si se soportan con elnúcleo del framework como si se soportan mediante plugins externos soportadosoficialmente por el framework o por la comunidad.

También se analizan las principales funcionalidades intrínsecas de los frameworksde desarrollo de aplicaciones híbridas para comprobar la potencia que tiene cadaframework y su grado de madurez.

Multiplataforma

Es importante saber en qué plataformas se puede desplegar la aplicación con elframework. Las más importantes son Android, iOS y web, pero también se ha estu-diado si se permite instalar la aplicación como aplicación de escritorio.

1. Ionic: Sí.

46


2. React Native: Sí, pero no por defecto. Para ejecutar la aplicación en un navega-dor web hace falta utilizar dependencias externas que transformen el código pa-ra cambiar los componentes principales de React Native a componentes HTML,además de adaptar las funcionalidades nativas para que funcionen en la web.Actualmente hay formas de desplegar un proyecto hecho con React Native en laweb, pero no disponen del 100 % de las funcionalidades de React Native.

3. Flutter: Sí, pero la versión que permite crear aplicaciones web no viene pordefecto y está en fase beta.

Detección de plataforma

En ocasiones es necesario que la aplicación haga unas operaciones diferentes enfunción de en qué plataforma esté funcionando (iOS, Android o web), por ello esimportante que el framework ofrezca alguna forma de detectar en qué plataforma seestá ejecutando la instancia actual de la aplicación.

1. Ionic: Sí.

2. React Native: Sí.

3. Flutter: Sí.

Live reload

Cuando se está desarrollando una aplicación, especialmente cuando se están mo-dificando elementos visuales, es interesante poder ver cómo se reflejan en la aplica-ción los cambios en el código. Cuánto más rápido se produzca esa actualización másrápido podrá probarse cada modificación en el código.

Existe una funcionalidad llamada live reload, que consiste en levantar un servidorque está activamente escuchando si se producen modificaciones en los ficheros decódigo de la aplicación para que, cuando detecte una modificación en un fichero, seinicie un proceso de actualización de la interfaz de la aplicación para poder ver comoafectan las modificaciones del código a como se ve realmente la aplicación.

1. Ionic: Sí.


3. Flutter: Sí, pero no en web, en web hay que pulsar la tecla ”r” en el terminal.

Permisos

Las aplicaciones móviles tienen que tener definidos qué permisos del usuario van anecesitar para acceder a determinados recursos del dispositivo, de modo que, cuandose vaya a acceder al recurso durante la ejecución, se le pida permiso al usuario.

1. Ionic: Sí.


3. Flutter: Sí.

47


Placa de notificaciones

Las aplicaciones pueden mostrar un número sobre el icono de la aplicación paramostrar que tienen algún tipo de notificación. La figura 47 muestra un ejemplo.

Figura 47: Placa de aplicación [59]

1. Ionic: Sí.


3. Flutter: Sí.

Calendar

Los dispositivos móviles tienen un calendario con el que las aplicaciones puedeninteractuar. Las API nativas permiten añadir, modificar y borrar entradas en dichocalendario.

1. Ionic: Sí.


3. Flutter: Sí.

Cámara

Los smartphone tienen una o varias cámaras, es importante que el frameworkpermita interactuar con la cámara del dispositivo.

1. Ionic: Sí.


3. Flutter: Sí.

Portapapeles

Permite copiar el texto seleccionado y pegarlo en otra parte.

1. Ionic: Sí.


3. Flutter: Sí.

Contactos

Los dispositivos móviles tienen una lista de contactos (una agenda) con la que lasaplicaciones pueden interactuar. Las API nativas permiten añadir, modificar y borrarentradas en dicho calendario.

48


1. Ionic: Sí.


3. Flutter: Sí.

Deeplinks

Los deeplinks permiten a los especialistas en marketing enviar a los usuarios auna página específica dentro de una aplicación, y les permite moverse entre la web ylas aplicaciones sin problemas.

1. Ionic: Sí.


3. Flutter: Sí.

Enviar correo electrónico

Permite enviar correos electrónicos.

1. Ionic: Sí.


3. Flutter: Sí.

Sistema de archivos

Si se les da permiso, las aplicaciones móviles pueden acceder al sistema de archi-vos del dispositivo.

1. Ionic: Sí.


3. Flutter: Sí.

Geolocalización

Los smartphones tienen GPS, las aplicaciones móviles pueden utilizarlo para ob-tener la ubicación del usuario de forma precisa.

1. Ionic: Sí.


3. Flutter: Sí.

Idioma de usuario

Permite identificar en qué idioma tiene configurado el smartphone el usuario.

1. Ionic: Sí.


3. Flutter: Sí.

49


Abrir una página web

Permite abrir una página web dentro de la aplicación e interactuar con ella. En losdispositivos nativos esto se consigue mediante un elemento llamado WebView.

1. Ionic: Sí.


3. Flutter: Sí.

Teclado

Permite modificar el comportamiento del teclado del smartphone, como puede serelegir cuando mostrarlo o cuando esconderlo.

1. Ionic: Sí.


3. Flutter: Sí.

Reproducir vídeo

Permite reproducir vídeos en la aplicación, tanto desde una URL cómo almacena-dos en el dispositivo.

1. Ionic: Sí.


3. Flutter: Sí.

Grabar audio

Permite grabar audio con el micrófono del smartphone.

1. Ionic: Sí.


3. Flutter: Sí.

Wifi

Permite acceder a la información de la wifi del dispositivo. Esto incluye poderver a qué wifi está conectado el usuario, poder activar o desactivar el wifi o poderconectarse a una determinada wifi.

1. Ionic: Sí.


3. Flutter: Sí, pero sólo para Android, en iOS es posible acceder a la informaciónde la Wifi pero no modificarla.

50


Bloquear la orientación de la pantalla

Permite impedir y permitir (según se quiera) que la aplicación gire cuando se girael smartphone.

1. Ionic: Sí.


3. Flutter: Sí.

Compartir con otras aplicaciones

Los dispositivos móviles permiten compartir archivos con otras aplicaciones queestén configuradas para recibirlos.

1. Ionic: Sí.


3. Flutter: Sí.

Splash screen

Permite modificar la página que se carga cuando se inicia por primera vez la apli-cación.

1. Ionic: Sí.


3. Flutter: Sí.

Barra de estado

Permite modificar e interactuar con la barra de estado del smartphone.

1. Ionic: Sí.


3. Flutter: Sí.

Vibración

Permite hacer vibrar al dispositivo.

1. Ionic: Sí.


3. Flutter: Sí.

OAuth

OAuth es un sistema que permite que otras entidades reconozcan al usuario paraacreditar que es quien dice ser. Algunos ejemplos son Google o Facebook.

51


1. Ionic: Sí.


3. Flutter: Sí.

Huella dactilar

Permite utilizar el sensor de huella dactilar del smartphone en caso de disponerde él.

1. Ionic: Sí.


3. Flutter: Sí.

Reconocimiento facial

Permite utilizar la cámara frontal y el sistema de reconocimiento facial del smartpho-ne en caso de disponer de él.

1. Ionic: Sí.


3. Flutter: Sí.

Accesibilidad

Permite detectar si el usuario tiene activadas las opciones de accesibilidad y tomarmedidas en consecuencia.

1. Ionic: Sí.


3. Flutter: Sí.

Tienda nativa

Permite interactuar con la Play Store en los dispositivos Android y con la AppStore en los dispositivos iOS. Por ejemplo, realizar compras de contenido añadidodesde dentro de la aplicación.

1. Ionic: Sí.


3. Flutter: Sí.

Notificaciones push

Las aplicaciones nativas pueden escuchar notificaciones aunque no se estén utili-zando llamadas notificaciones push.

1. Ionic: Sí.

52



3. Flutter: Sí.

Pantalla dividida

El sistema operativo de los smartphone permite desde ciertas versionas utilizardos aplicaciones al mismo tiempo dividiendo la pantalla.

1. Ionic: Sí.


3. Flutter: Sí.

Giroscopio

El Giroscopio permite al smartphone conocer su orientación en un determinadoinstante de tiempo y si ésta cambia, permitiendo saber si el usuario está girando omoviendo el smartphone.

1. Ionic: Sí.


3. Flutter: Sí.

3.4. Comparativa de rendimientos

En esta sección se va a crear una aplicación híbrida simple que muestre unavista que tenga escrito ”Hello World” y se van a comparar los tiempos que tardanen compilarla cada framework para Android, iOS y web y, en caso de disponer delive reload, cuánto tiempo tarda en refrescarse la aplicación tras guardar algunamodificación.

Las pruebas han sido llevada a cabo en los siguientes dispositivos:

1. Android: Las pruebas han sido realizadas desde un portátil Lenovo Legion Y520con Ubuntu 18.04 que las pruebas web y sobre un Xiaomi Redmi Note 5 conAndroid versión 9.

2. iOS: Las pruebas han sido realizadas desde un MacBook Pro con macOS HighSierra (versión 10.13.6) sobre un iPhone 5s con iOS versión 12.4.5.

3. Web: Las pruebas han sido realizadas desde el mismo portátil que las pruebasde Android sobre Google Chrome versión 81.0.4044.113.

Se han utilizado las siguientes versiones:

1. Ionic (Angular): Angular versión 5.0.7.

• Ionic versión 5.0.7.

• Córdova versión 9.0.0.

• Angular versión 8.2.14.

2. Ionic (React):

53

3.4. Comparativa de rendimientos

• Ionic versión 5.0.7.

• Capacitor versión 1.2.1.

• React versión 16.13.0.

3. React Native:

• React Native versión 0.62.2.

• React versión 16.11.0.

• Expo versión 3.19.2.

4. Flutter:

• Flutter versión 1.12.13+hotfix.9

La aplicación Hello World consta únicamente de una página en la que pone HelloWorld y se ve como se muestra en la figura 48

(a) Modo vertical (b) Modo horizontal

Figura 48: Hello World)

54

El código utilizado para desarrollar la aplicación Hello World con Ionic y Angularse puede ver en la figura 49.

1 import { Component } from ’@angular/core’;2 import { StatusBar } from ’@ionic-native/status-bar/ngx’;34 @Component({5 selector: ’app-home’,6 styles: [‘7 .container {8 background-color: greenyellow;9 display: flex;

10 align-items: center;11 justify-content: center;12 flex: 113 }14 .hello {15 font-size: 30px;16 font-weight: bold;17 }18 ‘],19 template: ‘20 <div class="container">21 <p class="hello">Hello World</p>22 </div>23 ‘24 })25 export class HomePage {2627 constructor(28 private readonly statusBar: StatusBar29 ) {}3031 ionViewWillEnter() {32 this.statusBar.styleLightContent();33 }34 }

Figura 49: Código de Ionic (Angular)

El código utilizado para desarrollar la aplicación Hello World con Ionic y React sepuede ver en la figura 50.

1 import React from ’react’;2 import { IonApp } from ’@ionic/react’;3 import ’@ionic/react/css/core.css’;45 const App: React.FC = () => {6 return (7 <IonApp>8 <div style={styles.container}>9 <p style={styles.hello}>Hello World</p>

10 </div>11 </IonApp>12 )13 };1415 const styles = {16 container: {17 backgroundColor: ’greenyellow’,18 display: ’flex’,19 alignItems: ’center’,20 justifyContent: ’center’,21 flex: 122 },23 hello: {24 fontSize: ’30px’,25 fontWeight: ’bold’ as "bold"26 }27 };2829 export default App;

Figura 50: Código de Ionic (React)

El código utilizado para desarrollar la aplicación Hello World con React Native sepuede ver en la figura 51.

1 /**2 * @format3 * @flow strict-local4 */56 import React from ’react’;7 import { StatusBar, StyleSheet, View, Text } from ’react-native’89 const App: () => React$Node = () => {

10 return (11 <>12 <StatusBar backgroundColor="black" barStyle="light-content" />13 <View style={styles.container}>14 <Text style={styles.hello}>Hello World</Text>15 </View>16 </>17 );18 };1920 const styles = StyleSheet.create({21 container: {22 backgroundColor: ’greenyellow’,23 display: ’flex’,24 alignItems: ’center’,25 justifyContent: ’center’,26 flex: 127 },28 hello: {29 fontSize: 30,30 fontWeight: ’bold’31 }32 });3334 export default App;

Figura 51: Código de React Native

El código utilizado para desarrollar la aplicación Hello World con Flutter se puedever en la figura 52.

1 import ’package:flutter/material.dart’;2 import ’package:flutter/services.dart’;34 class MyScaffold extends StatelessWidget {5 @override6 Widget build(BuildContext context) {7 return Material(8 color: Color.fromARGB(0xFF, 0xAD, 0xFF, 0x2F),9 child: Center(

10 child: Text(11 ’Hello World’,12 style: TextStyle(13 fontSize: 30,14 fontWeight: FontWeight.bold15 )16 ),17 )18 );19 }20 }2122 void main() {23 SystemChrome.setSystemUIOverlayStyle(SystemUiOverlayStyle(24 systemNavigationBarColor: Colors.white, // navigation bar color25 statusBarColor: Colors.black, // status bar color26 ));27 runApp(MaterialApp(28 debugShowCheckedModeBanner: false,29 title: ’My app’,30 home: MyScaffold(),31 ));32 }

Figura 52: Código de Flutter

A continuación se va a comparar el rendimiento de cara a el proceso de desarrollo,no a el rendimiento de una aplicación compleja de cara a la experiencia de usuario.

3.4.1. Tiempo de compilación e instalación

El procedimiento llevado a cabo para realizar estas pruebas es el siguiente:

1. Instalar las dependencias necesarias para utilizar el framework

2. Crear el proyecto

3. Modificar la aplicación para que muestre ”Hello World”

4. Modificar la configuración necesaria para su correcto funcionamiento

Tras realizar estos pasos se lanza la aplicación al dispositivo correspondiente, te-niendo que compilarse el código, instalarse y ejecutarse.

Ionic (Angular)

1. Android: Al arrancar la aplicación mediante ionic cordova run android, el tiempoque tarda en compilarse, instalarse y ejecutarse en el dispositivo es de aproxima-damente 58 segundos si es la primera vez que se compila, y de aproximadamente27 segundos si no es la primera vez que se compila.

2. iOS: Al arrancar la aplicación mediante ionic cordova run ios, el tiempo que tardaen compilarse, instalarse y ejecutarse en el dispositivo es de aproximadamente1 minuto y 30 segundos si es la primera vez que se compila, y tarda lo mismo sino es la primera vez que se compila.


3. Web: El tiempo que tarda la aplicación en compilarse y ejecutarse en el nave-gador web es el tiempo que tarda el framework de desarrollo web que se estéutilizando. En el caso de Angular, son aproximadamente 37 segundos.

Ionic (React)

1. Android: Al arrancar la aplicación mediante ionic capacitor run android, el tiem-po que tarda en compilarse, instalarse y ejecutarse en el dispositivo es de apro-ximadamente 1 minuto y 40 segundos si es la primera vez que se compila, yde aproximadamente 1 minuto y 13 segundos si no es la primera vez que secompila.

2. iOS: Al arrancar la aplicación mediante ionic capacitor run ios, el tiempo quetarda en compilarse, instalarse y ejecutarse en el dispositivo es de aproxima-damente 1 minuto y 32 segundos si es la primera vez que se compila, y deaproximadamente 36 segundos si no es la primera vez que se compila.

3. Web: El tiempo que tarda la aplicación en compilarse y ejecutarse en el nave-gador web es el tiempo que tarda el framework de desarrollo web que se estéutilizando. En el caso de React, es de aproximadamente 20 segundos si es laprimera vez que se compila, y de aproximadamente 6 segundos si no es la pri-mera vez que se compila.

React Native

1. Android: Al arrancar la aplicación mediante npx react-native run-android, eltiempo que tarda en compilarse, instalarse y ejecutarse en el dispositivo es deaproximadamente 42 segundos si es la primera vez que se compila, y de aproxi-madamente 12 segundos si no es la primera vez que se compila.

2. iOS: Al arrancar la aplicación mediante npx react-native run-iOS –device, el tiem-po que tarda en compilarse, instalarse y ejecutarse en el dispositivo es de apro-ximadamente 5 minutos y 8 segundos si es la primera vez que se compila, y deaproximadamente 47 segundos si no es la primera vez que se compila.

3. Web: Usando Expo y el comando expo start –web, la aplicación tarda aproxima-damente 15 segundos en compilarse, y ejecutarse en el navegador web.

Flutter

1. Android: Al arrancar la aplicación mediante flutter run, el tiempo que tarda encompilarse, instalarse y ejecutarse en el dispositivo es de aproximadamente 1minuto y 47 segundos si es la primera vez que se compila, y de aproximadamen-te 22 segundos si no es la primera vez que se compila.

2. iOS: Al arrancar la aplicación mediante flutter run, el tiempo que tarda en com-pilarse, instalarse y ejecutarse en el dispositivo es de aproximadamente 3 minu-tos y 50 segundos si es la primera vez que se compila, y de aproximadamente 2minutos y 6 segundos si no es la primera vez que se compila.

3. Web: Usando el comando flutter run -d chrome, la aplicación tarda aproximada-mente 16 segundos en compilarse, y ejecutarse en el navegador web.

59

3.5. Conclusiones

3.4.2. Live reload

Estas pruebas se realizan una vez que la aplicación está conectada en modo desa-rrollo con live reload activado.

Se mide el tiempo que pasa entre que se guarda un fichero con modificacioneshasta que este cambio se refleja en la aplicación que el dispositivo está corriendo.

Ionic (con Angular)

1. Android: Aproximadamente 2 segundos.

2. iOS: Aproximadamente 6 segundos.

3. Web: Aproximadamente 1 segundos.

Ionic (con React)

1. Android: Aproximadamente 2 segundos.

2. iOS: Aproximadamente 4 segundos.

3. Web: Aproximadamente 1 segundos.

React Native

1. Android: Inferior a 1 segundo.

2. iOS: Inferior a 1 segundo.

3. Web: Aproximadamente 1 segundo.

Flutter

1. Android: Aproximadamente 1 segundo.

2. iOS: Aproximadamente 1 segundo.

3. Web: No soportado. (Pulsando r en la terminal es de aproximadamente 1 segun-do)

3.5. Conclusiones

Existen diferentes frameworks con diferentes características, se han analizado lascaracterísticas más relevantes a la hora de elegir un framework de desarrollo, dán-dole prioridad a que cumplan con los requisitos funcionales que se necesiten y a lavelocidad de desarrollo de cada uno.

Lo cierto es que los frameworks están completamente actualizados en cuanto a po-der utilizar las últimas funcionalidades que ofrecen los sistemas operativos Androide iOS. Esto es así porque permiten integrar plugins en el framework, de modo que, siel framework no soporta con su funcionalidad base alguna característica, un usuariopuede crear un plugin que, mediante código nativo, utilice dicha característica.

60


Además, al existir una gran comunidad interesada en estos frameworks, algunosplugins se comparten entre usuarios. Incluso los propios frameworks recomiendanlos más útiles y, en ocasiones, los absorben dentro de las funcionalidades básicas delframework.

En cuanto a rendimientos se ha visto que casi todos los frameworks soportan livereload en todas las plataformas para agilizar el desarrollo en mayor o menor medida,y que los tiempos entre que se guarda un cambio en el código y que se muestra enel dispositivo es de aproximadamente un segundo. El tiempo de compilación tambiénes importante, por que a veces hay algunos tipos de cambios que no se pueden ac-tualizar con el live reload y que requieren parar y rearrancar la aplicación, y cuantomenos sea el tiempo de compilación e instalación, menos tiempo hay que esperar aque la aplicación arranque.

La tabla 53 muestra los resultados de la comparativa de rendimientos de la carac-terística de live reload.

Figura 53: Comparativa de rendimiento de live reload

61

La tabla 54 muestra los resultados de la comparativa de rendimientos al compilare instalar la aplicación por primera vez.

Figura 54: Comparativa de rendimiento de la primera compilación e instalación

La tabla 55 muestra los resultados de la comparativa de rendimientos al compilare instalar la aplicación después de la primera vez.

Figura 55: Comparativa de rendimiento de compilación e instalación

Capítulo 4

Diseño

Este capítulo lleva a cabo los análisis necesarios antes de iniciar un proceso dedesarrollo de software. Realizar una fase de diseño es importante para evitar futurosproblemas que pudieran haberse evitado de antemano y que conllevarían una pér-dida añadida de tiempo si requieren modificar partes de la aplicación que ya se hanrealizado.

La aplicación debe poder interactuar con el sistema GHALE, para lo cual deberáenviar y recibir información a través del AP. El intercambio de información se realiza-rá mediante websockets en vez de mediante peticiones HTTP tradicionales porque hayque enviar y recibir información bidireccionalmente y porque, al ser una aplicaciónorientada a emergencias, necesita funcionar con la mayor velocidad posible.

Deberá poder interactuar con GHALE a través de todas las capacidades avanzadasque tiene disponibles actualmente, estas son:

• Location Update: La capacidad de location update permite a las aplicacionesque utilizan GHALE enviar actualizaciones de la posición del llamante en tiemporeal.

• Chat: La capacidad de chat permite establecer una comunicación con un ope-rador mediante el servicio de chat de GHALE.

• WebRTC: La capacidad de WebRTC permite establecer una vídeo llamada conun operador.

4.1. Análisis de requisitos

Los requisitos que se muestran a continuación son el resultado de una fase deanálisis de requisitos dónde se han recopilado todos los los requisitos que debe sa-tisfacer la aplicación.

El formato es el siguiente:

• En primer lugar se mostrará si se trata de un requisito funcional (RF), de unrequisito no funcional (RNF) o de un requisito de interfaz (RI). Los requisitosfuncionales indican qué servicios debe ofrecer la aplicación, los requisitos nofuncionales hacen referencia a propiedades que debe tener el sistema como pue-

63

4.1. Análisis de requisitos

den ser la fiabilidad o el tiempo de respuesta, y los requisitos de interfaz definencómo debe mostrarse la información a los usuarios.

• En segundo lugar se mostrará un número identificativo para poder diferenciarposteriormente cada requisito.

4.1.1. Especificación de requisitos

RF.1: La aplicación debe poder establecer una comunicación con el AP de GHALEutilizando el protocolo websocket que tiene definido.

RF.2: La aplicación debe poder reestablecer una llamada si la conexión websocketse cierra inesperadamente.

RF.3: La aplicación debe poder enviar información del usuario según el estándarPEMEA.

RF.4: La aplicación debe poder obtener la ubicación del usuario.

RF.5: La aplicación debe poder enviar actualizaciones de la ubicación del usuarioutilizando la capacidad de location update de PEMEA, deberá permitir tanto enviaractualizaciones periódicas obteniendo la ubicación del usuario como elegir la ubica-ción que se envíe para poder realizar demostraciones de cómo funciona la capacidadde location update.

RF.6: La aplicación debe poder utilizar el protocolo de chat de GHALE y estableceruna comunicación mediante dicho protocolo cuando un PSAP invoque dicha capaci-dad.

RF.7: La aplicación debe poder acceder a la cámara del usuario.

RF.8: La aplicación debe poder acceder al micrófono del usuario.

RF.9: La aplicación debe poder utilizar el protocolo estándar de WebRTC.

RF.10: La aplicación debe poder utilizar la capacidad de WebRTC de GHALE y es-tablecer una comunicación mediante dicho protocolo cuando un PSAP invoque dichacapacidad.

RF.11: La aplicación debe poder cambiar entre capacidades abiertas, es decir, debepoder tener abierta una videollamada y un chat simultáneamente.

RF.12: La aplicación debe poder utilizarse en smartphones con sistema operativoAndroid e iOS y en los navegadores web más populares, al menos en Google Chrome,Firefox, Safari y Microsoft Edge.

RF.13: Si el AP tarda mucho en responder, se debe dejar de esperar y mostrar unerror al usuario.

RF.14: Se deben mostrar al usuario los errores que puedan darse durante el usode la aplicación para que pueda saber por qué algo no funciona. Por ejemplo, si el APestá caído.

RNF.15: La aplicación debe funcionar sin fallos como mínimo en las historias deusuario que se vayan a mostrar a los posibles clientes. Éstas historias de usuariomínimas son las siguientes:

64

Diseño

1. Llamada básica: Un usuario realiza una llamada y se ve en el interfaz del PSAPde GHALE cómo se recibe dicha llamada habiendo pasado a través de todos losnodos de PEMEA.

2. Capacidades avanzadas: Un usuario realiza una llamada a GHALE que se reci-be en la interfaz del PSAP de GHALE.

A continuación se cambia la ubicación que envía la aplicación para mostrarcómo vería un PSAP la actualización de la ubicación del usuario a través de lacapacidad de location update.

Luego el PSAP invoca la capacidad de chat de GHALE y se establece una sesiónde chat entre el PSAP y la aplicación, en dicha sesión de chat se muestran lasfuncionalidades del protocolo de chat de GHALE que incluyen las traduccionesautomáticas de los mensajes.

Por último el PSAP invoca la capacidad de WebRTC y se establece una videolla-mada entre el PSAP y la aplicación.

RNF.16: La navegación por las páginas de la aplicación debe ser fluida para mos-trar una buena experiencia de usuario.

RI.17: La aplicación debe solicitar los permisos para utilizar las funcionalidadesdel smartphone como si se tratara de una aplicación nativa.

RI.18: La aplicación debe utilizar elementos que den al usuario la sensación deque se está llevando a cabo una operación para que espere y no intente hacer máscosas al mismo tiempo. Esto se puede conseguir, por ejemplo, con spinners que giranmientras se está esperando.

RI.19: La aplicación debe mostrar un sistema de ”tabs” para cambiar entre lasdistintas capacidades.

RI.20: Para introducir la información de usuario que se envía durante la llamada,se realizará un formulario dónde el usuario pueda modificar la información antes derealizar una llamada, pero no mientras se encuentra dentro de una.

RI.21: Cuando se muestre la videollamada de la capacidad de WebRTC, la apli-cación debe intentar utilizar la mayor cantidad de pantalla del smartphone que seaposible, siendo preferible utilizar el 100 % de la pantalla.

RI.22: La interfaz del chat debe ser amigable para el usuario, teniendo elementosen común con alguna de las aplicaciones de chat comunes como WhatsApp, Insta-gram, Telegram o Slack.

4.2. Elección del framework

El principal requisito que debe cumplir el framework es que la aplicación puedasatisfacer todos los requisitos. Después del análisis de los principales frameworksllevado a cabo, se puede concluir que todos ellos están en un estado muy avanzadoy que cualquiera de ellos permitirá que la aplicación cumpla con todos los requisitosnecesarios.

Todos ellos cuentan también con una gran comunidad de usuarios que permitiráencontrar información sobre posibles errores que puedan producirse.

65

4.3. Diseño de la arquitectura

Por tanto, el factor determinante a la hora de elegir el framework es el tiempode desarrollo, que dependerá sobre todo del tiempo de aprendizaje y adaptación delequipo de desarrollo a dicho framework.

Se tiene experiencia en tecnologías de desarrollo web en general (JavaScript, HTML,CSS) y se tiene mucha experiencia con el framework de desarrollo de aplicaciones webAngular, que utiliza TypeScript como lenguaje. No se tiene experiencia previa ni endesarrollo de aplicaciones móviles ni en ninguno de los frameworks de desarrollo deaplicaciones híbridas.

Flutter queda descartado porque utiliza Dart, un lenguaje con el que no se tieneninguna experiencia y que supondría una curva enorme de aprendizaje respecto alos otros frameworks.

Puesto que no se tiene experiencia en React, también existiría una elevada curvade aprendizaje para aprender a utilizar React Native.

Sin embargo, Ionic puede utilizarse junto con Angular, lo que hace que la curvade aprendizaje sea menor que la de los otros frameworks. Además, en el análisis detiempos de compilación llevado a cabo en el apartado 3.4, los tiempos de compilaciónde ionic con Angular son competitivos respecto a los otros frameworks y cuenta conla funcionalidad de live reload.

4.3. Diseño de la arquitectura

En Ionic llaman páginas a las vistas entre las que el usuario va navegando cuandoutiliza la aplicación y que van superponiéndose visualmente unas sobre otras con-forme se transita entre ellas.

La aplicación tendrá una página de ajustes dónde el usuario podrá configurar lainformación que va a enviarse a través de GHALE. También permitirá configurar laURL del AP con el que tiene que contactar y el token de autenticación que necesitarápara que el AP autentique a la aplicación.

Dispondrá también de una página principal desde la que realizará la llamada. Elusuario sólo podrá navegar hacia esta página principal si se han introducido en lapágina de ajustes al menos los datos mínimos obligatorios necesarios para poderllamar a través de GHALE.

La página principal permitirá transitar a la página de ajustes para modificar lainformación antes de realizar una llamada. También mostrará un mapa para que elusuario seleccione desde dónde desea realizar la llamada, pudiendo dejar que dichaposición sea obtenida del GPS del smartphone o permitiendo indicar una ubicaciónfalsa. Esto es importante porque en algunas demostraciones se necesita mostrar loque pasa si dicha aplicación llamase desde otra región.

El cliente de websocket que realiza la llamada al AP deberá encargarse de recibiry transmitir los mensajes que están definidos en la especificación del AP de GHALE,y deberá intentar reconectarse automáticamente hasta en 3 ocasiones si la conexiónwebsocket se corta por algún error en la red. La aplicación también deberá comprobarsi la última vez que se ejecutó se encontraba en una llamada que no llegó a colgar, eintentará reestablecer automáticamente esa llamada.

66

Diseño

Durante una llamada se mostrará una página que tendrá cada capacidad activacomo ”tabs”. Por defecto se mostrará un mapa con la ubicación que el usuario haenviado a GHALE, pudiendo elegir obtener la ubicación del GPS del smartphone opulsar en el mapa para enviar la localización falsa que se desee. Como el usuarioya se encuentra una llamada activa, las actualizaciones de la ubicación se envíansiguiendo el protocolo especificado en la capacidad de location update, y el PSAPpodrá ver en un mapa como el usuario se va desplazando.

Cuando un PSAP invoque la capacidad de Chat o de WebRTC, se mostrará la sub-página de la capacidad invocada y aparecerá en la barra de ”tabs” dicha funcionalidadpara poder cambiar entre las capacidades activas.

La página de chat permitirá enviar y recibir mensajes utilizando el protocolo dechat estándar de PEMEA aprobado por el ETSI. También mostrará los usuarios quese encuentran en la sala y permitirá traducir de forma automática los mensajes alidioma del usuario tal y cómo permite el chat implementado por GHALE. El idiomadel usuario será obtenido de los ajustes del smartphone o del que tenga configuradoel usuario en el navegador web.

La página de WebRTC permitirá ver el vídeo del propio usuario y el de los demásintegrantes de la llamada. El usuario podrá también decidir dejar de enviar audioo vídeo en cualquier momento de la llamada. También se podrá cambiar entre lascámaras trasera y frontal del smartphone. Además, el usuario podrá elegir qué inte-grantes de la llamada desea mostrar en grande pudiendo minimizar a otros usuarios.

En la figura 56 se puede ver el diseño inicial de las páginas y la transición entreellas.

67

Figura 56: Maquetación de la aplicación

Capítulo 5

Desarrollo

Este capítulo explican las decisiones llevadas a cabo durante el desarrollo de laaplicación.

Antes de comenzar con el desarrollo se realizó un análisis del estado actual de laaplicación nativa Android de GHALE para tener en cuanta cómo estaban implemen-tadas de manera nativa las principales características de dicha aplicación de cara aobtener información que pudiera ser aplicada al desarrollo de la aplicación nativa.

5.1. Estado actual de GHALE

La aplicación Android implementaba las funcionalidades desarrolladas hasta lafecha en GHALE.

El uso de las funcionalidades de GHALE es estándar para que todos los proveedo-res de aplicaciones trabajen de manera interoperable y permitir que sus aplicacionespuedan utilizarse allá dónde GHALE esté disponible, haciendo que sean interopera-bles más allá de su región de origen.

Por tanto la interacción entre la aplicación híbrida y GHALE debe ser la mismaque la que lleva a cabo entre la aplicación nativa Android y GHALE.

5.1.1. Estado actual del protocolo

GHALE es una implementación de PEMEA, y el protocolo que se debe utilizar parainteractuar con PEMEA está estandarizado por el ETSI. La aplicación interactúa conun nodo AP de GHALE, por lo que necesitará comunicarse con dicho nodo siguiendoel protocolo estándar.

5.1.1.1. Establecimiento de la llamada

El establecimiento de la llamada se lleva a cabo mediante una conexión websocketentre la aplicación y el AP.

Dicha conexión websocket debe abrirse contra wss://’apUrl’/mobile/ws/call, ydebe contener una cabecera de autenticación para que el AP autentique a la aplica-ción. Este token se puede editar en la configuración de la aplicación.

69


Añadir cabeceras personalizadas al abrir una conexión websocket no es posible enel cliente de websocket de los navegadores web. Esto no es ningún problema a la horade realizar una aplicación móvil puesto que los clientes de websocket nativos si quepermiten añadir cabeceras personalizadas, pero es un problema a la hora de poderutilizar una versión web de la aplicación, que es uno de los requisitos funcionales.

Para solucionarlo se añadió en el AP la posibilidad de autenticación mediante coo-kie, de modo que una aplicación puede añadir su token de autenticación como cookieen el establecimiento de la sesión de websocket o como cabecera personalizada, es-tando permitidas ambas opciones.

Una vez abierta la conexión de websocket, el AP espera que la aplicación envíe unmensaje de SETUP en el cual la aplicación envía la información del usuario que seha configurado previamente. Esta información se envía en un mensaje de tipo SETUPcon una propiedad llamada ’callData’. El callData tiene las capacidades de GHALEque la aplicación tiene implementadas (Chat, Location Update, WebRTC, ...), la in-formación del smartphone del usuario que se obtiene de su tarjeta SIM, la ubicacióndesde dónde se está realizando la llamada y la información personal que el usuariohaya rellenado en el formulario de la página de ajustes.

Cuando se envía el evento SETUP, la aplicación debe esperar un evento de tipoESTABLISHED. Este evento tendrá una propiedad llamada result que podrá contener’SUCCESS’ o ’FAIL’, en caso de ser ’SUCCESS’ incluirá el identificador de sesiónque la aplicación podrá utilizar más adelante si se pierde la comunicación con elAP para intentar reanudar la llamada en curso. El evento de tipo ESTABLISHEDindica si el SETUP que ha enviado la aplicación es correcto y si el AP lo ha procesadocorrectamente.

A continuación deberá esperarse otro mensaje que notifica si la llamada ha pasa-do correctamente a través de GHALE y ha sido entregada a un PSAP. Dicho mensajepodrá ser un evento de tipo DELIVERY_FAIL si no se ha podido entregar a ningúnPSAP o de tipo DELIVERY_SUCCESS si se ha entregado con éxito a un PSAP. Unevento de tipo DELIVERY_FAIL puede producirse si se ha dado algún fallo en GHA-LE al enrutar la llamada, por ejemplo, si se llamada desde una ubicación que noha sido configurada. Un evento de tipo DELIVERY_SUCCESS contendrá una propie-dad llamada capabilities dónde se incluirán las capacidades que tienen en común laaplicación y el PSAP que ha recibido la llamada.

Una vez recibido el evento de DELIVERY_SUCCESS la aplicación y el PSAP yaestán conectados a través de GHALE, de modo que el PSAP podrá visualizar los datosque la aplicación ha enviado e invocar las capacidades que la aplicación y el PSAPtengan disponibles.

Si se pierde la comunicación con el AP, se utilizará el id de sesión que se recibió conel evento de tipo ESTABLISHED para enviar, en lugar de un evento de tipo SETUP,un evento de tipo CONTINUE, que es idéntico al de tipo SETUP, solo que tiene unapropiedad añadida llamada sessionId, que debe tener el valor del id de la sesión.Los eventos que se deben esperar después de enviar un evento de tipo CONTINUEson los mismos que se deben esperar después de un evento SETUP excepto que eltipo ESTABLISHED es sustituido por uno de tipo REESTABLISHED que no contieneid de sesión. Si la propiedad result del evento REESTABLISHED es ’FAIL’ en vez de’SUCCESS’ la llamada no ha podido ser reestablecida y se deberá realizar una nueva

70

Desarrollo

llamada.

Figura 57: Paso de mensajes del evento SETUP

Figura 58: Paso de mensajes del evento CONTINUE

5.1.1.2. Capacidades avanzadas

Las capacidades avanzadas que tiene implementadas GHALE actualmente son:Location Update, Chat y WebRTC.

Location Update

Esta capacidad permite enviar actualizaciones de la posición del usuario para queel PSAP pueda ver la ubicación real del usuario si este se desplaza durante la llamada.

La aplicación puede enviar eventos de tipo LOCATION_UPDATE a través del web-socket del AP con la propiedad ”position”. Dicha propiedad contiene una ubicacióncon el formato que se muestra en la figura 59. Dichos eventos permiten que el PSAPconozca en tiempo real la ubicación del usuario durante una llamada de emergencia.

71


Figura 59: Paso de mensajes de la capacidad de location update

Chat

Esta capacidad permite que la aplicación y el PSAP envíen y reciban mensajes detexto, de este modo las personas discapacitadas que no pueden comunicarse median-te una llamada telefónica normal, también pueden ser atendidas.

Si un PSAP invoca la capacidad de chat, el AP se lo notificará a la aplicaciónenviando un evento de tipo IM (Instant Messaging). Al recibir dicho mensaje, la apli-cación sabe que debe iniciar el protocolo de chat estándar de GHALE. Los mensajesdel protocolo de chat se envían como se muestra en la figura 60 y pasan siempre através del AP, que hace de intermediario.

En primer lugar se envía un evento JOIN para indicar que se quiere entrar alchat, indicando el nombre del usuario y los idiomas que conoce. Después de enviarel evento JOIN se recibirá un evento USER_LIST que contiene a todos los usuarios dela sala de chat con los idiomas que conocen. El evento USER_LIST volverá a recibirsecada vez que un usuario salga o entre en la sala, de modo que los usuarios que seencuentran en la sala en cada comento corresponderán a los que contenga el últimoevento USER_LIST recibido.

Una vez en la sala se pueden recibir 3 tipos de mensaje:

TEXT_MESSAGE: Este evento representa un mensaje de texto, incluye la pro-piedad ”id” para identificar el mensaje, la propiedad ”user” para saber quiénenvió el mensaje y también incluye el idioma en el que se ha enviado el mensaje.

REPLY: Este evento representa una respuesta a otro mensaje. Además de loscampos de un evento TEXT_MESSAGE, también incluye la propiedad ”referen-ce”, que es igual a la propiedad ”id” del mensaje al que esta respondiendo.

TRANSLATION: Este evento contiene las traducciones a un mensaje de la sala.Contiene la propiedad ”reference”, que es igual a la propiedad ”id” del mensajeal que haga referencia.

72

Figura 60: Paso de mensajes de la capacidad de chat


Las propiedades ”timestamp”, ”room”, ”id” y ”user” son añadidas por el servidor,para evitar que un usuario pueda enviar mensajes en el futuro y que no existanidentificadores repetidos.

Los usuarios reciben los mensajes que envían al servidor una vez han sido recibi-dos por el servidor y enviados a los demás usuarios.

WebRTC

Esta capacidad permite establecer una videollamada entre la aplicación y el PSAP,de modo que el PSAP pueda ver y oír lo que el usuario está viendo y oyendo en tiemporeal. También permite al PSAP añadir a otras personas a la sala como pueden ser porejemplo un traductor o un intérprete de signos.

Si un PSAP invoca la capacidad de WebRTC, el AP se lo notificará a la aplicaciónenviando un evento de tipo AUDIO_VIDEO/WEBRTC_NATIVE que contendrá la URLdel servidor de WebRTC. Una vez recibida la URL la aplicación podrá comunicarsecon dicho servidor siguiendo el protocolo estándar de PEMEA que se muestra en lafigura 61.

En primer lugar la aplicación abre una conexión websocket contra el servidor deWebRTC de GHALE y envía un evento de tipo JOIN para indicar que quiere iniciar unavideollamada. El servidor de WebRTC le responderá con un evento de tipo USER_LISTque contiene a todos los usuarios de la sala de WebRTC.

Para cada uno de los usuarios recibidos en la USER_LIST, la aplicación debe rea-lizar el siguiente procedimiento:

1. Recibir un evento de tipo RTC_SESSION_NEGOTIATION, que incluye la infor-mación del servidor TURN o STUN que se debe utilizar para comunicarse condicho usuario.

2. Enviar un evento de tipo RTC_SESSION_DESCRIPTION de tipo ”offer” dónde seincluya la SDP (Session Description) del flujo de vídeo generado por la aplica-ción.

3. Recibir un evento de tipo RTC_SESSION_DESCRIPTION de tipo ”answer” con lainformación del vídeo del otro usuario.

4. Enviar eventos de tipo RTC_ICE_CANDIDATE que se generen para dicha cone-xión según el estándar de WebRTC.

5. Recibir eventos de tipo RTC_ICE_CANDIDATE por parte del servidor de WebRTCy añadirlos a dicha conexión.

Estos pasos son los pasos que normalmente hacen falta a la hora de establecercomunicaciones utilizando el estándar de WebRTC.

74

Figura 61: Paso de mensajes de la capacidad de WebRTC

5.2. Desarrollo de la aplicación


Después de analizar el funcionamiento de la aplicación nativa Android y de leer ladocumentación de Ionic se inicia el proceso de desarrollo.

En una primera fase se desarrolla la aplicación probando su funcionamiento enun dispositivo Android. Una vez desarrolladas todas las funcionalidades requeridaspara este dispositivo, se prueban en un dispositivo iOS y por último en navegadoresweb.

5.2.1. Versión móvil

En primer lugar se desarrollan las páginas previas a realizar una llamada a GHA-LE, que son la página de ajustes y la página home, a continuación el establecimientode la llamada y la comunicación con el AP, y por último las capacidades avanzadas.

La página home es una página en la que se muestra un mapa de Google Maps.Por defecto intenta obtener la ubicación del usuario, para lo cual pedirá los permisosnecesarios como puede verse en la figura 63a y, si es posible, pedirá al usuario queencienda el GPS como puede verse en la figura 63c. Únicamente se solicitarán lospermisos una vez, para no frustrar al usuario si no quiere dar los permisos y porqueen iOS no está permitido pedir repetidamente los mismos permisos si el usuario losrechaza, en su lugar se ofrecerá ir a los ajustes del smartphone para modificarlos allímanualmente como puede verse en la figura 63b.

76

Figura 62: Página home

(a) Solicitud para obtener laubicación

(b) Mensaje si se han rechaza-do previamente los permisos

(c) Solicitud para activar elGPS

Figura 63: Solicitud de permisos de usuario

La página home permite cambiar la ubicación desde la que se desea realizar unallamada, navegar a la página de ajustes e iniciar una llamada.

Desde la página home se puede navegar a la página de ajustes con el botón su-perior derecho. En la página de ajustes, se puede modificar la información personaldel usuario que se enviará cuando se llame. Los campos obligatorios se resaltan conasteriscos y no se puede transitar a la página home si no se han rellenado al menostodos los campos obligatorios. El formulario está dispuesto en varios tabs entre losque puede transitarse haciendo click en el icono del tab correspondiente o deslizandolateralmente la zona del formulario. Para guardar los ajustes y navegar a la páginahome se debe pulsar el botón superior derecho.

El formulario se desarrolló utilizando las herramientas que ofrece Angular pararealizar formularios pero integrándolos con las vistas y transiciones de Ionic. Si algúncampo no cumple algún validador, al intentar guardar el formulario dicho campo seresalta en rojo y se informa al usuario del problema. También se mostrará sobre elicono del tab un número con el número de errores de validación que hay en dichotab para que el usuario pueda saber dónde se encuentra el error si éste se produceen un tab distinto del que se encuentra actualmente el usuario.

También se muestra la versión actual de la aplicación, para que los miembros delequipo puedan saber si deben actualizar la aplicación que tengan instalada en sudispositivo si no se trata de la última que se ha desplegado y para poder informar deerrores en determinadas versiones, no sólo de la aplicación, si no también de GHALE.

Figura 64: Página de ajustes


Cuando se realiza una llamada contra el AP y se reciben los eventos que indi-can que todo ha ido bien, se navega a la página de llamada. La página de llamadamuestra por defecto la capacidad de location update, que es obligatorio como mínimoactualmente en GHALE. La capacidad de location update permite ver la ubicaciónque la aplicación está enviando al PSAP y permite modificarla si se hace click enel mapa, para mostrar el funcionamiento visual de la capacidad de location update.Cuando el PSAP invoca otras capacidades, aparecerán unos tabs en la parte inferiorque permitirán cambiar entre capacidades.

(a) Recién establecida la lla-mada

(b) Cambiando la ubicacióndel usuario

(c) Con varias capacidades in-vocadas simultáneamente

Figura 65: Página de llamada

Si la aplicación recibe del AP el evento que indica que el PSAP ha invocado lacapacidad de chat o de WebRTC, la aplicación habilitará dicho tab y transitará a lapágina correspondiente.

La página de chat permite enviar y recibir mensajes de texto. Los mensajes delusuario se muestran a la derecha y los de los demás se muestran a la izquierda parafacilitar su diferenciación visualmente. El usuario puede mantener el dedo pulsadosobre un mensaje y éste aparecerá resaltado, mostrando dos nuevas opciones queson copiar el contenido del mensaje, o responder a dicho mensaje. También se puedepulsar en el botón superior derecho para traducir automáticamente los mensajesal idioma del usuario. Todas estas funcionalidades las ofrece el servicio de chat deGHALE y la aplicación está integrada con dicho servicio.

80

(a) Recién abierto (b) Recibiendo mensajes

(c) Traduciendo mensajes (d) Respondiendo a mensajes

Figura 66: Página de chat


La página de WebRTC permite establecer una videollamada entre el PSAP y elusuario. Durante dicha llamada el PSAP puede añadir a más personas, lo cual es útilporque podría añadir por ejemplo traductores o intérpretes del lenguaje de signos ala llamada. La aplicación muestra el vídeo de la cámara del usuario en pequeño en laparte superior izquierda, y reparte el espacio de toda la pantalla entre los vídeos delos demás integrantes de la videollamada.

Cuando se hace click en la pantalla, se muestran diversas opciones durante unossegundos, y si no se hace click pasado un tiempo, las opciones se ocultan para que lavideollamada pueda obtener el máximo espacio posible, que es uno de los requisitosde interfaz especificados. Las opciones incluyen dejar de transmitir audio o vídeo,reiniciar la llamada por si falla el flujo de datos, colgar la videollamada y ver a losdemás integrantes para poder elegir si mostrar u ocultar sus vídeos. También sepuede cambiar entre la cámara frontal y trasera.

Figura 67: Página de WebRTC

Una vez terminada la aplicación y probado su correcto funcionamiento en dispo-sitivos Android, se procede a probar en dispositivos iOS. La mayor parte de la apli-cación funciona sin ningún problema, pero hay que adaptar algunas partes para quefuncionen correctamente en iOS, manteniendo siempre intacto su funcionamiento enAndroid.

El mayor inconveniente es WebRTC, pues el navegador web que utiliza Ionic endispositivos iOS no implementa WebRTC de forma nativa y hay que utilizar un pluginque implementa WebRTC utilizando elementos nativos del smartphone y adaptarlopara que el funcionamiento sea tan bueno como el obtenido en Android.

82

Desarrollo

Particularidades de Android

Puesto que la versión Android fue la primera en desarrollarse, no se detectaronproblemas específicos una vez terminado el desarrollo para Android.

Se podría mencionar que el comportamiento del teclado es diferente al de iOS,siendo más permisivo su uso en Android y estando más limitado en iOS.

También se debe tener en cuenta que en Android existe el botón de ir hacia atrásmientras que en iOS no existe, de modo que se ha implementado su funcionalidadpara que únicamente funcione en la versión Android pero para que no sea impres-cindible usarlo, ya que si no la aplicación iOS no podría funcionar completamente.

La generación de instalables es muy sencilla en Android, simplemente hay queejecutar un comando de Ionic y este se encarga de generar el archivo .apk que poste-riormente se puede distribuir e instalar libremente en dispositivos Android. Algunosdispositivos requieren que la aplicación esté firmada, lo cual se puede hacer concertificados válidos y reconocidos que se generaron exprofeso.

Además se ha integrado la generación de nuevas versiones de la aplicación en elciclo de integración continua, de modo que cada vez que se actualiza la aplicación,se genera una nueva versión, se firma y se publica en el artifactory de Deveryware,dónde están accesibles todas las versiones de la aplicación.

Particularidades de iOS

Cuando se desarrolló la versión para iOS hubo que refactorizar la gestión de per-misos porque en iOS es más restrictiva, de modo que se preparó la aplicación parafuncionar con el sistema de permisos de iOS y de este modo queda consistente tantoen iOS como en Android, pues iOS tiene mejores prácticas en este aspecto.

El sistema de firmar y desplegar aplicaciones iOS requirió bastante tiempo, puesno es nada sencillo para alguien que nunca haya trabajado con ello. Fue necesariopagar una cuenta de desarrollador de apple para poder firmar la aplicación y compi-larla desde un Mac.

También se configuró el entorno de despliegue de versiones de Apple, que es elpunto previo a sacar la aplicación en la App Store. Esto fue necesario porque unaaplicación iOS no puede distribuirse tan fácilmente como una aplicación Android,iOS no permite instalar aplicaciones desde un archivo, debe hacerse siempre desde suApp Store, de modo que para distribuir versiones de prueba se utiliza una aplicaciónllamada TestFlight, que permite descargar versiones de la aplicación que todavía nose han publicado en la App Store. De este modo se pudo distribuir la aplicación iOSpara ser utilizada en los iPhone y los iPad de los demás miembros del equipo.

Se puede ver en la figura 68 que la versión de iOS es ligeramente diferente enalgunos aspectos a la versión de Android como por ejemplo en como se muestranalgunos iconos.

83

Figura 68: Versión iOS

5.2.2. Versión web

La versión web se desarrolló utilizando Google Chrome. La mayoría del códigofuncionó correctamente, pero hubo que realizar un tratamiento especial en algunaspartes debido a plugins que se utilizaban que están disponibles para las versionesmóviles pero no para la versión de navegador web.

También hubo que añadir la autenticación mediante cookies en el AP porque losnavegadores web no permiten añadir cabeceras personalizadas cuando se estableceuna sesión de websocket.

Una vez que la versión web funcionaba al 100 % en Google Chrome se probó enotros navegadores web.

En Firefox hubo problemas de permisos con la API KEY de google maps, de modoque se implementó que la aplicación pudiera funcionar sin obtener los permisos delusuario en dicho caso, obligando al usuario a elegir un punto en el mapa desde elque llamar antes de poder realizar una llamada.

En Safari y en Edge hubo problemas con WebRTC debido a que implementan algu-nos aspectos de forma ligeramente distinta que Chrome, de modo que se añadió unadapter que estandariza los métodos para todos los navegadores y WebRTC funcionócorrectamente en todos los navegadores.

(a) Chrome(b) Firefox

(c) Safari

Figura 69: Versión web

Capítulo 6

Conclusiones

Durante la elaboración de este Trabajo de Fin de Máster se han analizado losprincipales frameworks de desarrollo de aplicaciones híbridas y se ha desarrolladouna aplicación usando uno de ellos.

A continuación se recogen las conclusiones técnicas, que son consecuencia de lasdecisiones tomadas y del aprendizaje adquirido durante el desarrollo del proyecto.

Se incluyen también las conclusiones personales sobre el trabajo realizado y algu-nas posibles líneas de trabajo futuro.

6.1. Conclusiones técnicas

Antes de comenzar a realizar este proyecto, se desconocía el grado de madurezen el que se encuentran actualmente las tecnologías para el desarrollo híbrido deaplicaciones.

Después de realizar un análisis de los principales frameworks, se puede concluirque todos se encuentran en un grado de madurez bastante avanzado y que permitenutilizar todas las funcionalidades de los dispositivos móviles del mismo modo que lohacen las aplicaciones nativas.

Cómo a veces no pueden actualizarse al mismo ritmo al que lo hacen todos lossistemas operativos de los smartphones, permiten que los desarrolladores integrensus propias partes de código nativo mediante plugins para permitir que una aplica-ción pueda disponer de las mismas funcionalidades de las que tendría si se hubieradesarrollado de forma nativa.

Además, la gran comunidad de usuarios que poseen se encarga de publicar pluginsde forma pública para que toda la comunidad pueda contribuir y mantenerlos, siendoalgunos finalmente integrados en el núcleo deo framework y mantenidos por el equipode desarrollo del framework.

En cuanto a rendimiento, la aplicación realizada utilizando Ionic y Angular no pa-rece tener ningún problema de rendimiento respecto a la versión nativa Android quetenía GHALE previamente. Teniendo en cuenta que utiliza algunas funcionalidadesmuy exigentes para el dispositivo como es WebRTC, se podría pensar que inclusoaplicaciones que necesiten muchos recursos pueden desarrollarse de forma híbrida

87

6.2. Conclusiones personales

y ser igual de competitivas. No obstante no se puede afirmar con total certeza porquealgún elemento concreto que no se ha necesitado para el desarrollo de la aplicaciónpodría problemas de rendimiento que no se habrían detectado.

6.2. Conclusiones personales

Haber podido adquirir las habilidades que se han obtenido con la elaboración deeste proyecto aporta mucha fuerza al perfil que tenía previamente.

Un perfil de desarrollador Full-Stack indica que se tienen conocimientos tanto decómo funcionan los servicios y las tecnologías de back end como de cómo funcio-nan las tecnologías de front end. Pudiendo cubrir por completo el ciclo de vida deldesarrollo de un producto que vaya a ser proporcionado a clientes finales.

Al comienzo los conocimientos de front end que tenía eran de desarrollo web, perotras la elaboración de este proyecto he adquirido conocimientos del desarrollo deaplicaciones móviles, algo muy buscado hoy en día por las empresas.

6.3. Líneas futuras

Rendimiento de una aplicación compleja

Una línea futura de trabajo sería desarrollar una aplicación compleja y que utilicecasi todas las herramientas disponibles por los smartphones utilizando los diferentesframeworks de desarrollo de aplicaciones híbridas. Con dicha aplicación se podríacomparar los tiempos de respuesta de la aplicación para comprobar la experiencia deusuario. Si además se desarrollara dicha aplicación de forma nativa permitiría com-parar el rendimiento del desarrollo nativo y del desarrollo híbrido en una aplicacióncompleja real.

Esto requeriría una gran cantidad de tiempo de aprendizaje y de desarrollo, puesconllevaría aprender a utilizar casi todas las funcionalidades que ofrece cada frame-work, además de las que ofrece el desarrollo nativo.

Pruebas

Las pruebas son muy importantes a la hora de desarrollar un producto porquepermiten asegurarse que todo lo que se ha desarrollado funciona correctamente ypuede comprobarse rápidamente si realizar una modificación en la aplicación resultaen que alguna otra parte comience a fallar.

Lo más óptimo sería desarrollar pruebas automáticas que realicen los pasos quetendría que hacer un usuario para asegurar el cumplimiento de las historias de usua-rio que se explicaron en la especificación de requisitos. No obstante, al tratarse deuna aplicación de demostración y no de un producto que vaya a ser distribuido a losclientes, no se le dio mucha importancia al desarrollo de pruebas automáticas, pre-miando el desarrollo de nuevas funcionalidades o mejorar la experiencia de usuariopara que la aplicación fuese más fluida.

No obstante, una mejora a futuro si al final se decidiese convertir esta aplicación enun producto sería sin duda el desarrollo de pruebas automáticas que le aportarían

88

Conclusiones

más robustez y que acelerarían el proceso de añadir nuevas funcionalidades al notener que estar probando manualmente si la aplicación sigue funcionando sin fallospara las historias de usuario descritas.

Versión de escritorio

Durante el desarrollo de la aplicación no fue un requisito que pudiera desplegarsecomo una aplicación de escritorio, pero una vez terminado el trabajo se propuso sobrela mesa la idea.

Una aplicación de escritorio es una aplicación que se instala en un ordenador deescritorio, con sistema operativo Windows, MacOS o Linux. Requiere de un procesode instalación y se crea un acceso rápido en el menú de inicio (Windows) o en eldirectorio de aplicaciones.

Electron es una tecnología que permite crear aplicaciones de escritorio compatiblescon los distintos sistemas operativos a partir de una página web. Utiliza el lenguajede programación nodejs para interactuar con las opciones típicas que ofrece unaaplicación de escritorio, como puede ser crear un menú desplegable de opciones quenormalmente se ve en la parte superior izquierda de una aplicación de escritorio.

Se ha desarrollado actualmente una versión de escritorio de la aplicación comoprueba de concepto. Lo que se ha hecho para sacar esta versión tan rápido ha sidocrear una ventana con electron que cargue la página web dónde se encuentra desple-gada la versión web de la aplicación, de modo que electron utiliza su navegador webembebido para mostrar la web en una ventana de escritorio. La versión de escritoriofunciona correctamente en Windows, MacOS y Linux.

Se utilizaron diversas dependencias para mejorar los instaladores de Windows yde MacOS y finalmente se han creado archivos de instalación para Windows, MacOSy Debian (Linux).

89

Figura 70: Instalador para Windows

Figura 71: Instalador para MacOS

(a) Windows (b) MacOS

Figura 72: Versión de Escritorio

Traducción a diferentes idiomas

Aunque la aplicación sólo se quería en Inglés inicialmente, algunos clientes pre-guntaron si sería posible sacar una versión en otros idiomas.

Cuando se desarrolló la demostración de un PSAP de GHALE, ya surgió esta idea,y se investigó cómo conseguir esta funcionalidad. Dicha demostración fue desarro-llada utilizando Angular, el mismo framework de desarrollo web que se ha utilizadopara el desarrollo de la aplicación híbrida, por lo que el desarrollo de esta nuevafuncionalidad fue rápido y sencillo.

En este caso la aplicación móvil obtiene el idioma del usuario del idioma queel usuario tenga configurado en los ajustes de su smartphone, de modo que si lomodifica, la aplicación se reinicia y obtiene el nuevo idioma.

El funcionamiento es sencillo, por defecto los textos de la aplicación están escritosen Inglés, y si la aplicación detecta que el idioma del smartphone del usuario está enun idioma diferente, busca un archivo de traducciones para dicho idioma, en caso deno encontrarlo utiliza Inglés por defecto. De este modo, para añadir un nuevo idiomasolo hay que entregar al cliente el archivo de traducciones para que lo rellene con elidioma que desea añadir y la aplicación traduce automáticamente todos los textos.

Bibliografía

[1] European Commission, ”112, the single European emergency number: Fre-quently Asked Questions”, European Commission Press Corner, 2009. [Onli-ne]. Disponible: https://ec.europa.eu/commission/presscorner/detail/en/MEMO_09_60 [Accedida Abr. 25, 2020].

[2] Logotipo de la llamada de emergencia europea 112, 2016. [Online].Disponible: https://en.wikipedia.org/wiki/112_(emergency_telephone_number)#/media/File:Logo-notruf-112-europaweit.svg [Accedida Abr.25, 2020].

[3] EENA, European Emergency Number Association, 2019. [Online]. Disponible:https://eena.org/ [Accedida Abr. 25, 2020].

[4] Advanced Mobile Location, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Advanced_Mobile_Location [Accedida Abr. 25, 2020].

[5] EENA, Advanced Mobile Location, 2019. [Online]. Disponible: https://eena.org/advanced-mobile-location/ [Accedida Abr. 25, 2020].

[6] EENA, NEXT GENERATION 112, 2019. [Online]. Disponible: https://eena.org/next-generation-112/ [Accedida Abr. 25, 2020].

[7] Pan-European Mobile Emergency Application, 2019. [Online]. Disponible:https://www.pemea.help/ [Accedida Abr. 25, 2020].

[8] F. Rodella, ”Los obstáculos para llamar al 112 con una app si no estás cer-ca de tu casa”, El País, Jul. 10, 2019. [Online]. Disponible: https://elpais.com/tecnologia/2018/07/04/actualidad/1530718772_718151.html [Acce-dida Abr. 25, 2020].

[9] EENA, EMERGENCY APPS, 2019. [Online]. Disponible: https://eena.org/pemea/ [Accedida Abr. 25, 2020].

[10] J. Winterbottom, J. Cabas, B. Casse, C. Lumbreras and L. Bergonzi, ”PE-MEA Project Phase I. Project Report,” EENA, May. 7, 2019. [Online]. Disponi-ble: https://eena.org/document/pemea-project-phase-i-report/ [Acce-dida Abr. 25, 2020].

[11] EENA, EENA Conference postponement, 2020. [Online]. Disponible: https://eenaconference.org/postponement-eena2020/ [Accedida Abr. 25, 2020].

[12] StatCounter, Mobile Operating System Market Share Worldwide, 2020. [On-line]. Disponible: https://gs.statcounter.com/os-market-share/mobile/worldwide [Accedida Abr. 25, 2020].

93

BIBLIOGRAFÍA

[13] Wikipedia, Windows 10 Mobile, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Windows_10_Mobile [Accedida Abr. 25, 2020].

[14] Wikipedia, Android (operating system), 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Android_(operating_system) [Accedida Abr. 25,2020].

[15] StatCounter, Android Version Market Share Worldwide, 2020. [Online]. Disponi-ble: https://gs.statcounter.com/android-version-market-share [Acce-dida Abr. 25, 2020].

[16] Wikipedia, Java (programming language), 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Java_(programming_language) [Accedida Abr. 25,2020].

[17] Wikipedia, Kotlin (programming language), 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Kotlin_(programming_language) [Accedida Abr.25, 2020].

[18] Wikipedia, Android Studio, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Android_Studio [Accedida Abr. 25, 2020].

[19] Wikipedia, Gradle, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Gradle [Accedida Abr. 25, 2020].

[20] Gradle Inc., Branding Guidelines, 2020. [Online]. Disponible: https://gradle.com/brand/ [Accedida Abr. 25, 2020].

[21] Google Developers, Configure your build, 2020. [Online]. Disponible: https://developer.android.com/studio/build [Accedida Abr. 25, 2020].

[22] Wikipedia, iOS, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/IOS [Accedida Abr. 25, 2020].

[23] Wikimedia, Apple logo black, 2020. [Online]. Disponible: https://commons.wikimedia.org/wiki/File:Apple_logo_black.svg [Accedida Abr. 25, 2020].

[24] BuildFire, What’s The Best Language To Learn To Build IOSApps, 2019. [Online]. Disponible: https://buildfire.com/programming-languages-ios-app/ [Accedida Abr. 25, 2020].

[25] Apple Inc., Swift. The powerful programming language that is also easy to learn,2020. [Online]. Disponible: https://developer.apple.com/swift/ [AccedidaAbr. 25, 2020].

[26] Apple Inc., Start Developing iOS Apps (Swift), 2016. [Online]. Disponi-ble: https://developer.apple.com/library/archive/referencelibrary/GettingStarted/DevelopiOSAppsSwift/ [Accedida Abr. 25, 2020].

[27] Wikipedia, Xcode, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Xcode [Accedida Abr. 25, 2020].

[28] Wikipedia, TestFlight, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/TestFlight [Accedida Abr. 25, 2020].

94

BIBLIOGRAFÍA

[29] MDN contributors, HTML: Hypertext Markup Language, 2020. [Online]. Disponi-ble: https://developer.mozilla.org/en-US/docs/Web/HTML [Accedida Abr.25, 2020].

[30] Wikipedia, HTML5, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/HTML5 [Accedida Abr. 25, 2020].

[31] MDN contributors, CSS: Cascading Style Sheets, 2020. [Online]. Disponible:https://developer.mozilla.org/en-US/docs/Web/CSS [Accedida Abr. 25,2020].

[32] Wikipedia, Cascading Style Sheets, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Cascading_Style_Sheets [Accedida Abr. 25, 2020].

[33] Wikipedia, Sass (stylesheet language), 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Sass_(stylesheet_language) [Accedida Abr. 25,2020].

[34] MDN contributors, JavaScript, 2020. [Online]. Disponible: https://developer.mozilla.org/en-US/docs/Web/JavaScript [Accedida Abr.25, 2020].

[35] Wikipedia, JavaScript, 2020. [Online]. Disponible: https://es.wikipedia.org/wiki/JavaScript [Accedida Abr. 25, 2020].

[36] Wikipedia, TypeScript, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/TypeScript [Accedida Abr. 25, 2020].

[37] Wikipedia, npm (software), 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Npm_(software) [Accedida Abr. 25, 2020].

[38] Json.org, Introducing JSON, 2003. [Online]. Disponible: https://www.json.org/json-en.html [Accedida Abr. 25, 2020].

[39] Angular, One framework. Mobile & desktop., 2020. [Online]. Disponible: https://angular.io/ [Accedida Abr. 25, 2020].

[40] Wikipedia, React (web framework), 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/React_(web_framework) [Accedida Abr. 25, 2020].

[41] Wikipedia, Vue.js, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Vue.js [Accedida Abr. 25, 2020].

[42] Wikipedia, WordPress, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/WordPress [Accedida Abr. 25, 2020].

[43] MDN contributors, HTTP, 2020. [Online]. Disponible: https://developer.mozilla.org/en-US/docs/Web/HTTP [Accedida Abr. 25, 2020].

[44] Wikipedia, Hypertext Transfer Protocol, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol [Accedida Abr. 25,2020].

[45] MDN contributors, HTTP request methods, 2020. [Online]. Disponible: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods [Accedida Abr. 25,2020].

95

BIBLIOGRAFÍA

[46] Wikipedia, WebSocket, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/WebSocket [Accedida Abr. 25, 2020].

[47] MDN contributors, Using server-sent events, 2020. [Online]. Disponi-ble: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events [Accedida Abr. 25, 2020].

[48] MDN contributors, WebRTC API, 2020. [Online]. Disponible: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API [Accedida Abr.25, 2020].

[49] Wikipedia, WebRTC, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/WebRTC [Accedida Abr. 25, 2020].

[50] Wikipedia, GitLab, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/GitLab [Accedida Abr. 25, 2020].

[51] GitLab, Empower your team to thrive remotely, 2020. [Online]. Disponible:https://about.gitlab.com/ [Accedida Abr. 25, 2020].

[52] Wikipedia, GitHub, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/GitHub [Accedida Abr. 25, 2020].

[53] Wikipedia, Bitbucket, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Bitbucket [Accedida Abr. 25, 2020].

[54] Atlassian, Built for professional teams, 2020. [Online]. Disponible: https://bitbucket.org/product [Accedida Abr. 25, 2020].

[55] Wikipedia, Ionic (mobile app framework), 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Ionic_(mobile_app_framework) [Accedida Abr. 25,2020].

[56] Wikipedia, React Native, 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/React_Native [Accedida Abr. 25, 2020].

[57] Facebook Inc., Core Components and Native Components, 2020. [Online]. Dispo-nible: https://reactnative.dev/docs/intro-react-native-components[Accedida Abr. 26, 2020].

[58] Wikipedia, Flutter (software), 2020. [Online]. Disponible: https://en.wikipedia.org/wiki/Flutter_(software) [Accedida Abr. 26, 2020].

[59] P. Horowitz, Disable the Red Notification Badge on App Icons on iPho-ne or iPad, 2012. [Online]. Disponible: https://osxdaily.com/2012/01/09/remove-red-badge-icons-from-apps-ios/ [Accedida Abr. 25, 2020].

96

Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,

C=ES

Fecha/Hora Tue Jun 16 23:46:37 CEST 2020

Emisor delCertificado

[email protected], CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES

Numero de Serie 630

Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (AdobeSignature)

Universidad Politécnica de Madrid - UPMoa.upm.es/64414/1/TFM_JORGE_FORCADA_SANZ.pdf · Frameworks...

Documents

Transcript of Universidad Politécnica de Madrid - UPMoa.upm.es/64414/1/TFM_JORGE_FORCADA_SANZ.pdf · Frameworks...