TRABAJO FIN DE GRADO INGENIERÍA DE TECNOLOGÍAS DE TELECOMUNICACIÓN

Sistema de notificación inteligente basado en tecnologías móviles que actúa por el

usuario para evitar distracciones al volante

Autor Clemente Javier Irigaray Castellón

Director

Oresti Baños Legrán

Departamento de Arquitectura y tecnología de computadores

Escuela Técnica Superior de Ingenierías Informática y de Telecomunicación

— Granada, noviembre de 2019

Sistema de notificación inteligente basado en tecnologías móviles que actúa por el usuario

para evitar distracciones al volante

Autor Clemente Javier Irigaray Castellón

Director

Oresti Baños Legrán

Sistema de notificación inteligente basado en tecnologías móviles que actúa por el usuario para evitar distracciones al

volante

Clemente Javier Irigaray Castellón

Palabras clave: s i s t e m a p r o a c t i v i d a d c o n t e x t o d i s t r a c c i ó n a c c i d e n t e t r á f i c o

Resumen

En este proyecto se realizará un análisis sobre las distracciones que la tecnología causa a la hora de conducir y como estas influyen en los accidentes de tráfico.

Seguidamente se aportará una solución desarrollando un sistema inteligente basado en tecnologías móviles capaz de actuar por el usuario en determinadas ocasiones con el fin de ayudar a disminuir estas distracciones. Este sistema es capaz de recoger información contextual sobre el usuario, accediendo a su calendario, su localización y servidores externos que aportan información complementaria. Una vez recogida esta información, el sistema debe ser capaz de procesarla para detectar las situaciones en las que el usuario llega tarde a un evento pero no puede utilizar el teléfono móvil por estar conduciendo, y actuar en consecuencia de forma autónoma avisando a los participantes del evento del retraso del usuario sin que este tenga que detenerse a coger el teléfono móvil mientras conduce. De esta forma se pretende conseguir una reducción del riesgo de que ocurra un accidente de tráfico.

Para ello a lo largo del proyecto se propondrá un diseño de la arquitectura necesaria para llevar a la práctica este sistema y se realizará una implementación para dispositivos Android.

Posteriormente, se realizará una evaluación de esta implementación, tanto en un entorno simulado como ante usuarios reales, y se sacarán conclusiones que permitirán establecer las bases a sistemas futuros que tengan como objetivo evitar las distracciones al volante.

Sistema de notificación inteligente basado en tecnología móviles que actúa por el usuario para evitar distracciones al

volante

Clemente Javier Irigaray Castellón

Keywords: s y s t e m p r o a c t i v e c o n t e x t d i s t r a c t i o n a c c i d e n t t r a f f i c

Abstract

This project will analyze the distractions that technology causes while driving and how they influence traffic accidents.

Next, a solution will be provided by developing a smart system based on mobile technologies capable of acting by the user on certain occasions in order to try to reduce these distractions. This system is capable of collecting contextual information about the user, accessing its calendar, its location and external servers that provide complementary information. Once this information has been collected, the system must be able to process it to detect the situations in which the user is late for an event but cannot use the mobile phone because he is driving, and act accordingly, notifying the participants of the event the user’s delay without the user having to stop to pick up the mobile phone while driving. This intended to reduce the risk of a traffic accident.

To achieve this, a design of the architecture necessary to implement this system will be proposed and an implementation for Android devices will be carried out.

Finally, an evaluation of this implementation will be carried out both in a simulated environment and with real users, and conclusions will be drawn to allow establishing the basis for future systems that aim to avoid distractions while driving.

Yo, Clemente Irigaray Castellón, alumno de la titulacion GRADO EN INGENIERÍA DE TECNOLOGÍAS DE TELECOMUNICACIÓN de la Escuela Tecnica Superior de Ingenierıas Informatica y de Telecomunicacion de la Universidad de Granada, con DNI 77560884P, autorizo la ubicación de la siguiente copia de mi Trabajo Fin de Grado en la biblioteca del centro para que pueda ser consultada por las personas que lo deseen.

Fdo: Clemente Javier Irigaray Castellón

Granada a 10 de Noviembre de 2019.

D. Oresti Baños Legrán, Profesor del Área de xxx del

Departamento de Arquitectura y Tecnologías de computadores.

Informa:

Que el presente trabajo, titulado Sistema de notificación inteligente

basado en tecnología móviles que actúa por el usuario para evitar

distracciones al volante, ha sido realizado bajo su supervision por

Clemente Javier Irigaray Castellón, y autoriza la defensa de dicho

trabajo ante el tribunal que corresponda.

Y para que conste, expide y firma el presente informe en Granada a

14 de mes de 2019.

El director:

Oresti Baños Legrán

Agradecimientos

Gracias a mis familiares y amigos, en especial a los compañeros de la carrera que me han acompañado en estos cuatro años de trabajo y sin los cuales nada sería igual. Gracias a mi padre, mi madre y mi hermano por su apoyo incondicional. Gracias a mi director, D. Oresti Baños, por su tiempo y disponibilidad a lo largo del desarrollo del proyecto. Gracias a los que se han ido pero me acompañan siempre, porque me hicieron ser lo que ahora soy.

Índice General

1. Introducción ........................................................................................................................ 19

1.1. Presentación de la problemática................................................................................. 19

1.1.1. Proactive Computing ........................................................................................... 21

1.1.2. Context Awareness .............................................................................................. 22

1.2. Objetivos ..................................................................................................................... 23

1.2.1. Objetivo General ................................................................................................. 23

1.2.2. Objetivos Específicos ........................................................................................... 23

1.3. Fases de Desarrollo ..................................................................................................... 24

1.4. Estructura de la memoria ............................................................................................ 24

2. Estado del Arte .................................................................................................................... 25

2.1. Estudios ....................................................................................................................... 25

2.2. Patentes ...................................................................................................................... 25

2.3. Ejemplos de Aplicaciones ............................................................................................ 26

2.3.1. Mutting ................................................................................................................ 28

2.3.2. SilentMeet ........................................................................................................... 29

3. Diseño .................................................................................................................................. 30

3.1. Requisitos .................................................................................................................... 30

3.2. Arquitectura del sistema ............................................................................................. 31

4. Implementación .................................................................................................................. 35

4.1. Software utilizado ....................................................................................................... 35

4.1.1. Java ...................................................................................................................... 35

4.1.2. XML ...................................................................................................................... 36

4.1.3. Android Studio..................................................................................................... 37

4.1.4. Realm ................................................................................................................... 39

4.1.5. Interfaces de Programación de Aplicaciones (APIs) ........................................... 40

4.2. Clases y métodos ......................................................................................................... 47

4.2.1. Main Activity ....................................................................................................... 47

4.2.2. DisplayContactsActivity ....................................................................................... 47

4.2.3. Clase Evento ........................................................................................................ 48

4.2.4. Clase EventAdapter ............................................................................................. 50

4.2.5. Clase ContactAdapter .......................................................................................... 51

4.2.7. Clase FetchCalendarDataJobService ................................................................... 53

4.2.8. Clase CheckAndNotifyJobService ........................................................................ 54

4.2.9. Clase NotificationsUtils ....................................................................................... 54

4.2.10. Clase ScheduleUtilities ........................................................................................ 55

4.2.11. Clases HTTPClient, Response, AndroidHelper, OnHttpRequestComplete, DownloadImageTask ........................................................................................................... 55

4.3. Descripción de algunas funcionalidades a través de fragmentos de código. ............. 56

4.3.1. Calcular la hora de salida..................................................................................... 56

4.3.2. Cargar los datos del calendario ........................................................................... 58

4.3.3. Comprobar la hora y actuar en consecuencia ..................................................... 61

5. Evaluación ........................................................................................................................... 62

5.1. Descripción experimental ........................................................................................... 62

5.2. Usabilidad del sistema................................................................................................. 68

5.3. Interpretación de los resultados ................................................................................. 71

5.4. Limitaciones ................................................................................................................ 71

6. Conclusiones y vías futuras ................................................................................................. 72

6.1. Grado de consecución de los objetivos iniciales ......................................................... 72

6.2. Contribuciones del trabajo .......................................................................................... 73

6.3. Vías futuras .................................................................................................................. 74

7. Referencias bibliográficas ................................................................................................... 75

Índice de figuras

Fig 1 Principales causas de distracción al volante. Fuente: (Sondea, 2019) ............................... 19

Fig 2 Ejemplo gráfico de distracción por mensaje de texto. Fuente: (Fernandéz, 2019) ............ 20

Fig 3 Ejemplo de Regla. ............................................................................................................... 21

Fig 4 Context awareness. Fuente: (slashgear.com, 2016) .......................................................... 22

Fig 5 Diagrama de Gantt de las fases del proyecto ..................................................................... 24

Fig 6 Interfaz de Mutting. Fuente: (mutting, 2018) .................................................................... 28

Fig 7 Dispositivos probando la app SilentMeet. .......................................................................... 29

Fig 8 Arquitectura del sistema. ................................................................................................... 31

Fig 9 Árbol de decisión. ............................................................................................................... 34

Fig 10 Fichero XML del layout de DisplayContactsActivity. ........................................................ 36

Fig 11 Diagrama de las distintas etapas para la realización de aplicaciones en Android Studio. Fuente: (Android Developers, 2017) ........................................................................................... 38

Fig 12 esquema de Realm Platform. Fuente: (Realm, 2017) ....................................................... 39

Fig 13 Fragmento de la respuesta JSON ...................................................................................... 41

Fig 14 Ejemplo de respuesta de un mapa estático. .................................................................... 42

Fig 15 Modelo de datos del proveedor de calendario. Fuente: (Android Developers, 2017) .... 43

Fig 16 Creación de un nuevo proyecto. ....................................................................................... 44

Fig 17 Busqueda de las APIs a utilizar. ........................................................................................ 44

Fig 18 Habilitar API. ..................................................................................................................... 44

Fig 19 Seleccionar credenciales. .................................................................................................. 45

Fig 20 Seleccionar clave API. ....................................................................................................... 45

Fig 21 Clave API. .......................................................................................................................... 46

Fig 22 Restricciones de clave. ...................................................................................................... 46

Fig 23 Diagrama UML del proyeto............................................................................................... 47

Fig 24 Montar la url para realizar la petición .............................................................................. 56

Fig 25 Extraemos la información de la respuesta en JSON ......................................................... 57

Fig 26 Fragmento de la respuesta JSON. ..................................................................................... 57

Fig 27 Ejecutamos el cliente. ....................................................................................................... 57

Fig 28 Creamos un array con los identificadores y asignamos los índices. ................................. 58

Fig 29 Especificamos un rango de tiempo para realizar la búsqueda. ........................................ 58

Fig 30 Construcción de la petición. ............................................................................................. 58

Fig 31 Asignamos la respuesta a un cursor. ................................................................................ 59

Fig 32 Creamos un array de eventos y otro con los datos de la existencia de invitados en los

eventos. ....................................................................................................................................... 59

Fig 33 Bucle que extrae la información del calendario. .............................................................. 59

Fig 34 Añadir Ubicación inicial a los eventos. ............................................................................. 60

Fig 35 Añadir participantes a los eventos. .................................................................................. 60

Fig 36 Actualización de la base de datos local. ........................................................................... 60

Fig 37 Extracción del primer evento de la base de datos. .......................................................... 61

Fig 38 Calculo de fechaNotificar y FechaEmail. ........................................................................... 61

Fig 39 Reglas para definir la forma de actuar de la aplicación. ................................................... 61

Fig 40 Añadir eventos al calendario. ........................................................................................... 63

Fig 41 Pantalla principal SmartSender. ....................................................................................... 63

Fig 42 Pantallas resultantes al hacer click en los mapas. ............................................................ 64

Fig 43 Pantalla de invitados. ........................................................................................................ 64

Fig 44 Notificación al usuario del Evento1. ................................................................................. 65

Fig 45 Pantalla principal una vez completado el Evento 1. ......................................................... 65

Fig 46 Notificación Evento 2. ....................................................................................................... 66

Fig 47 Correo enviado por la Aplicación. ..................................................................................... 66

Fig 48 Cuestionario realizado según el método SUS. .................................................................. 69

Fig 49 Puntuación de las preguntas por cada uno de los encuestados. ..................................... 70

Índice de tablas

Tabla 1 Requisitos del sistema para instalar Android Studio v3. ................................................ 38

Tabla 2 Media de los resultados de cada pregunta. ................................................................... 70

19

Capítulo 1

1. Introducción

1.1. Presentación de la problemática Según la DGT (Dirección General de Tráfico) más de un millón de personas mueren todos los años como consecuencia de los accidentes de tráfico y otro medio centenar de millones sufren traumatismos por este motivo (DGT, 2019). Los accidentes mortales en carretera se deben a muchas causas, pero la principal son las distracciones al volante. En 2018, un 33% de los accidentes fueron causados porque el conductor iba distraído, esta cifra supera ya al 29% de los accidentes causados por el exceso de velocidad (CEA, 2018). Esto nos lleva a hacernos la siguiente pregunta: ¿cuál es la principal causa de distracciones al volate?

Según el periódico El País, nueve de cada diez distracciones al volante están relacionadas con el uso del teléfono móvil (Fernandéz, 2019). De estas distracciones, más del 80% de los conductores reconocen que dejan de prestar atención a la carretera para escribir mensajes o buscar información en el teléfono. En la Fig 1 se pueden ver representadas las principales causas de distracción al volante.

Fig 1 Principales causas de distracción al volante. Fuente: (Sondea, 2019)

Conducir es una actividad que exige una concentración completa que debe mantenerse en tres planos:

Visual: Mantener la vista en la carretera.

Manual: Mantener las manos en el volante.

Cognitivo: Mantener la mente en la conducción.

El envío de mensajes de texto por el teléfono móvil multiplica por 23 las posibilidades de accidente ya que implica los tres tipos de distracción; visual (mientras los ojos van leyendo la pantalla); cognitiva (la mente está ocupada elaborando el mensaje) y manual (los dedos van tecleando las letras o botones) (Fundación Mapfre, 2018).

20

Pongamos como ejemplo la siguiente situación:

Un sujeto debe asistir a dos eventos A y B que tienen lugar en distintas localizaciones. Para ir de un evento a otro utiliza el coche como medio de transporte. Puede suceder por diversas causas, que el sujeto se retrase y no llegue a tiempo al evento B (el evento A no termina a la hora esperada, hay más tráfico de lo normal, el sujeto pensaba que salía con suficiente antelación, etc). Cuando el sujeto toma consciencia de esta situación decide avisar de su retraso a los participantes del evento B, cogiendo el móvil para enviar un mensaje de texto mientras conduce por la autovía como vemos reflejado en la Fig 2.

En el estudio “Españoles al volante: distracciones y uso del móvil”, se realiza una encuesta en la que los participantes consideran que pueden estar un tiempo medio de 2,37 segundos sin prestar atención a la carretera mirando el móvil, ascendiendo en el caso de los jóvenes entre 18 y 24 años hasta los 3,55 segundos (Sondea, 2019). A una velocidad de 120 kilómetros por hora, tres segundos y medio son suficientes para recorrer una distancia de 120 metros en los cuales nuestro sujeto no tiene consciencia alguna de lo que está pasando a su alrededor, aumentando gravemente el riesgo de tener un accidente. El estudio anteriormente citado recoge, además, que el 84% de personas que conducen creen que los accidentes se reducirían a la mitad si la tecnología impidiera utilizar el móvil al volante.

Fig 2 Ejemplo gráfico de distracción por mensaje de texto. Fuente: (Fernandéz, 2019)

Es por ello, que intentando solventar esta problemática, en este proyecto se desarrollará un sistema proactivo que recoja información contextual sobre el usuario, accediendo a los eventos planificados en su calendario, a su localización mediante GPS y determinando el tiempo que necesita para llegar desde su posición a la ubicación donde tiene lugar el evento. Una vez recogida esta información, el sistema debe ser capaz de procesarla para detectar este tipo de situaciones, y actuar en consecuencia de forma autónoma avisando a los participantes del evento del retraso del usuario sin que este tenga que detenerse a coger el teléfono móvil mientras conduce, reduciendo así considerablemente el riesgo de accidente.

A continuación introduciremos dos términos importantes que componen las bases conceptuales el desarrollo del proyecto: Proactive Computing y Context Awareness.

21

1.1.1. Proactive Computing

Tradicionalmente se ha colocado al ser humano como centro neurálgico en todo proceso computacional involucrándolo totalmente (Tennenhouse, 2000). A esto se le llama computación interactiva o centrada en el ser humano. Sin embargo, en un contexto en el que el número de datos a manejar aumenta exponencialmente y prima la búsqueda de tiempos de reacción cada vez más bajos, se ha hecho necesario el paso a un nuevo modelo en el cual el sistema sea capaz de interactuar con el medio y tomar decisiones por sí mismo, sin necesidad de preguntar al usuario. Llamamos computación proactiva al modelo en el cual el ser humano pasa de ser el centro del proceso a estar por encima de él (como supervisor, pero no como parte activa).

El comportamiento proactivo tiene la intención de provocar cambios en lugar de solo reaccionar ante ellos. Como describen Salovaraa y Oulasvirta (Salovaara & Oulasvirta, 2004), los sistemas proactivos se adhieren a dos premisas:

Trabajar en nombre del usuario, o en su beneficio.

Actuar por iniciativa propia, sin la orden explícita del usuario.

En la universidad de Luxemburgo, Zampunieris y su equipo desarrolló una implementación de un sistema proactivo basado en reglas (Zampunieris, 2006). De este modo se crea un escenario en el que un conjunto dinámico de reglas se ejecutan determinando una ruta de operación.

Una regla es un elemento básico que puede ser subdividido en 5 estados:

1. Data acquisition (Adquisición de datos): En este estado se recopila toda la

información necesaria para proceder a la ejecución de los siguientes estados.

2. Activation guard (Activación): Estado que actúa como un disparador (trigger) de los

siguientes estados.

3. Conditions (Condiciones): El propósito de este estado es el de ofrecer la posibilidad de

realizar comprobaciones más exhaustivas sobre el contexto.

4. Actions (Acciones): Acciones llevadas a cabo por el sistema si las condiciones

anteriores se cumplen.

5. Rule Generation (Generación de regla): Con este paso se concluye la ejecución de la

regla y permite la creación de otras reglas o la clonación de la misma para permanecer

en el sistema.

Data acquisition

es = get_user(S)

cc = get_course(C)

date = get_date()

Activation guard

Date>(…startDate+7days)

Conditions

es.numberOfConnections(cc.forum)==0

Actions

sendEmail(to = es.name, subject=”Warning”, data =”e-student”+es.name+”did not use the forum after one week”);

Rule Generation

If (active==fase) the cloneRule(self)

Fig 3 Ejemplo de Regla.

22

1.1.2. Context Awareness

Como se ha visto anteriormente, un sistema proactivo tiene como objetivo actuar en nombre del usuario o en su beneficio, pero siempre por iniciativa propia (sin la orden explicita del usuario).

Para llevar a cabo esta meta, el sistema debe tener la habilidad de extraer y analizar información del medio que le rodea y adaptar su comportamiento en consecuencia. En otras palabras, el sistema debe ser consciente del contexto que lo rodea. A esto se le llama Context Awareness (consciencia de contexto).

Fig 4 Context awareness. Fuente: (slashgear.com, 2016)

El contexto incluye cualquier información que sea relevante para una entidad dada (ya sea una persona, un dispositivo o una aplicación). Por tanto la información contextual abarca una amplia gama de categorías como localización, fecha y hora, dispositivo, identidad, usuario, rol, nivel de privilegio, actividad, dispositivos cercanos, etc. Los navegadores Web, cámaras, micrófonos, GPS, receptores o sensores son fuentes potenciales de información contextual (Fig 4).

Un sistema dotado de consciencia de contexto debe recoger datos mediante estas y otras fuentes y actuar acorde unas normas o reglas preestablecidas, basando sus respuestas en suposiciones sobre el contexto. Para las aplicaciones usuarias, el conocimiento del contexto puede guiar los servicios y permitir experiencias mejoradas como la realidad aumentada, entrega de información relevante del contexto, marketing contextual, etc.

23

1.2. Objetivos

1.2.1. Objetivo General

o Desarrollar un sistema proactivo de notificación automática de indisponibilidad durante la conducción basado en información de contexto.

Este sistema recogerá información contextual sobre el usuario, accediendo a los eventos planificados en su calendario, a su localización mediante GPS y determinando el tiempo que necesita para llegar desde su posición a la ubicación donde tiene lugar el siguiente evento de su calendario. Una vez recogida esta información, el sistema debe ser capaz de procesarla para detectar las situaciones en las que el usuario llega tarde a un evento pero no puede utilizar el teléfono móvil por estar conduciendo, y actuar en consecuencia de forma autónoma avisando a los participantes del evento del retraso del usuario sin que este tenga que detenerse a coger el teléfono móvil mientras conduce. De esta forma se pretende conseguir una reducción del riesgo de que ocurra un accidente de tráfico.

1.2.2. Objetivos Específicos

o Diseñar la arquitectura necesaria del sistema, así como los servicios utilizados.

o Implementar el sistema a través de una aplicación móvil para dispositivos Android. Esta aplicación debe ser capaz de acceder tanto al calendario del usuario como a las distintas APIs de Google para recibir la información necesaria, y tras esto notificar al usuario a qué hora debe salir para llegar a tiempo a un evento, y en caso de que este llegue tarde, notificar a los invitados del evento al que se dirige.

o Evaluar la implementación realizada en entornos simulados y realizar encuestas a usuarios para medir su nivel de satisfacción. Medir los resultados obtenidos y sacar conclusiones.

24

1.3. Fases de Desarrollo

El desarrollo de este proyecto ha tenido lugar durante aproximadamente 3 meses y medio, desde agosto hasta mediados de noviembre de 2019. En la Fig 5 se muestra un diagrama que ilustra la evolución de las fases del proyecto a lo largo del tiempo.

1.4. Estructura de la memoria

A continuación se procede a describir la estructura general que sigue la memoria con la intención de dar una visión global al lector:

Introducción: presentación de la problemática encontrada y de la solución propuesta, introducción a los conceptos básicos “proactive computing” y “context awareness”, definición de los objetivos del proyecto, descripción en el tiempo de las fases de desarrollo del proyecto y estructura de la memoria.

Estado del arte: trabajos y estudios realizados hasta el momento, relacionados con el proyecto, y que utilizan calendario y localización como principal fuente de información de contexto, así como ejemplos de aplicaciones similares.

Diseño: definición de los requisitos del sistema desarrollado, así como el diseño de su arquitectura.

Implementación: exposición del software utilizado para realizar la implementación del sistema, presentación de las clases, así como los métodos más importantes de la aplicación y ejemplos de código que ilustran las funcionalidades más destacadas.

Evaluación: puesta a prueba de la aplicación en un entorno controlado y recopilación de las opiniones de usuarios encuestados

Conclusiones y vías futuras: recopilación de las conclusiones más importantes a las que ha llegado este proyecto así como potenciales vías de trabajo futuro.

Fig 5 Diagrama de Gantt de las fases del proyecto

25

Capítulo 2

2. Estado del Arte

En este trabajo se utilizarán calendario y localización como principales fuentes de información contextual. Es por ello por lo que en el siguiente apartado se nombrarán y describirán estudios, patentes y ejemplos de aplicaciones que utilizan estas fuentes de información de contexto y que han resultado de interés a la hora de desarrollar este proyecto.

2.1. Estudios

Aunque el calendario es una buena fuente de información de contexto, la información útil se esconde entre eventos que no llegan a realizarse. Combinando el calendario con otra información de contexto (por ejemplo la localización) podremos tener una representación más fiel de los eventos que ocurren en realidad.

En 2001 se presentó “Ambush”, un calendario probabilístico que proporcionaba predicciones acerca de la asistencia del usuario a futuros eventos. Para ello se creó un modelo Bayesiano sobre los hábitos de asistencia del usuario a los diferentes eventos (Mynatt & Tullio, 2001).

En un estudio posterior (O’Neill, Lovett, Irwin, & Pollington, 2010) se cuestiona la validez del calendario como único sensor para detectar si un evento se está llevando a cabo (ya que es imposible separar los eventos que figuran en el calendario y se llevan a cabo, de los que no). Por ello, se proponen dos métodos que combinan, en tiempo real, la información del calendario con la localización y los datos procedentes de las redes sociales, reduciendo la aparición de falsos eventos considerablemente.

Más tarde, Hermann Stern y su equipo realizaron un estudio para detectar la interrumpibilidad de un usuario basándose en información de localización y calendario. Aunque no consiguieron un sistema en el que la interrumpibilidad estimada se correspondiera con la percibida por el propio usuario, sí que constataron que los registros GPS sumados a los de calendario ofrecen información suficiente para poder realizar cálculos que determinasen la interrumpibilidad (Stern, Pammer, & Lindstaedt, 2011).

2.2. Patentes

A continuación se citan una serie de patentes americanas que describen ejemplos de sistemas que pueden resultar de interés para este proyecto:

System and method for smart contextual calendaring based meeting scheduling: En este documento se describen sistemas, métodos y medios de almacenamiento no transitorios legibles por ordenador para el calendario contextual. El calendario contextual puede programar reuniones con diferentes estados de intervalos de tiempo bloqueados basados en el comportamiento de los usuarios con respecto a los participantes, temas y tareas o contexto de la reunión. Por ejemplo, el anfitrión H invita al invitado A para una reunión; el sistema de calendario contextual sabe que no está disponible el viernes, por lo que puede priorizar la tarea para A el viernes en relación a los demás participantes y programar un “evento firme” o puede sugerir una persona alternativa que esté disponible basándose en el tema y el contexto

26

anterior. El sistema puede extraer información del contexto, e identificar (basándose en ella) un asistente deseado y una prioridad. El sistema puede programar un “evento flexible” en el calendario de los asistentes deseados basándose en la prioridad (Dhara, Krishnaswamy, & Anajwala, 2014).

Context conflict resolution and automatic context source maintenance: El siguiente documento explora técnicas para detectar y resolver conflictos en la información de contexto proveniente de múltiples fuentes. El sistema recoge información de distintas fuentes y determina si existe un conflicto entre ellas. Si esto ocurre evalúa una serie de reglas para seleccionar al menos una que sirva para resolver el conflicto. El sistema se acciona cuando se detecta un cambio en el contexto del usuario al cual se le notifica del conflicto. Las fuentes marcadas como inválidas son ignoradas un tiempo determinado, hasta que se determine que vuelven a ser válidas. Cada actualización de las fuentes trae consigo una actualización del calendario del usuario (Doss, Pozefsky, & Sundstrom, 2009).

System and method of managing real-time communications using context-based awareness states: se describe un método para la administración de comunicaciones entre los usuarios de un sistema de conciencia. El equipo del usuario recibe mensajes instantáneos (IM) de sus vecinos, y responde con información de contexto sobre la actividad actual del usuario para determinar si se encuentra ocupado o no. Esto permite realizar un horario con los espacios de tiempo en el que el usuario está disponible para recibir mensajes de sus vecinos. El sistema crea una lista con el estado (ocupado o no) de cada uno de sus vecinos y con su localización, tomando conciencia del estado de actividad del conjunto de usuarios (Kogan, Galvin, Solie, Ronald E. Pontrich, Travis, & Mewherter, 2014).

Creating a calendar event using context: En este documento se describe un método para crear nuevos eventos en un calendario utilizando como fuente de información expresiones del lenguaje natural. En primer lugar identifica slots en un texto que indiquen la creación de un nuevo evento de calendario, comparándolos con los guardados en los módulos gramaticales. Si coinciden, se crea un nuevo evento de calendario ejecutando las reglas guardadas en los módulos. Uno o más slots relacionados con un nuevo evento deben al menos incluir la fecha, la hora, el tipo de evento o la localización (Hazen, Bishop, Duta, Longo, & Babaeizabeh, 2016).

2.3. Ejemplos de Aplicaciones

La mayoría de aplicaciones existentes relacionadas con la conducción se enfocan en evitar atascos e identificar la existencia de radares. Ejemplos de aplicaciones de este tipo son:

DGT: la aplicación de la Dirección General de Tráfico permite conocer el estado del tráfico en tiempo real, teniendo en cuenta posibles incidencias momentáneas (atascos, accidentes, etc.) e incluso las inclemencias meteorológicas. La aplicación señala dónde se encuentran los radares fijos y permite llamar directamente al 112 en caso de emergencia (DGTinfo, 2014).

Waze: una app colaborativa y gratuita, propiedad de Google, en la que la comunidad de conductores que la emplean son los que avisan de las distintas situaciones que nos podemos encontrar por el camino (Waze, 2019).

Google Maps: esta aplicación de mapas, además de ser un excelente navegador GPS que nos informa de las mejores rutas para llegar a un destino, proporciona información sobre los atascos a tiempo real y ofrece información muy actualizada sobre el estado de las carreteras y puntos de interés (Google Developer, 2017).

27

Por otro lado, también encontramos aplicaciones cuyo propósito es el de detectar accidentes de tráfico o alertar a los servicios de emergencia en el caso de que se sufra uno. Ejemplos representativos son:

My 112: es una aplicación gratuita que permite comunicarse con el Centro 112 de Emergencias, enviando automáticamente la ubicación al realizar la llamada. Este sistema rastrea la ubicación para compartirla con la persona que atiende la llamada desde el 112. Además, si se produce un aviso de emergencia en la zona donde se encuentra el usuario, recibirá una notificación con información asociada, dándole la oportunidad de enviar fotografías del incidente, como información adicional. (Google Play, 2019)

iRescue: es una aplicación que ayuda a los profesionales de emergencias a obtener información para el rescate de personas en accidentes de tráfico. Esta app contiene información de más de 40 marcas y 900 modelos de vehículos, lo que hace más fácil el rescate a los servicios de emergencias al disponer de información del automóvil. Además, la aplicación permite visualizar la posición del dispositivo en el mapa y enviar una fotografía por correo electrónico, adjuntando, si es necesario, la posición del GPS (App Store, 2016).

SOSmart: detecta la ocurrencia de un accidente automáticamente utilizando los sensores internos del Smartphone, y de manera inmediata envía una notificación de emergencia con la ubicación del usuario a contactos de emergencia, seleccionados previamente. Esto reduce enormemente el tiempo en que los servicios de urgencia son notificados del accidente. (SOSmart, 2019)

Todas estas aplicaciones son útiles una vez que un accidente ha tenido lugar; sin embargo, no ayudan a prevenir que este ocurra. Son pocos los ejemplos de aplicaciones que tratan de dar una solución real para disminuir el riesgo de que tenga lugar un accidente de tráfico. A continuación se describe en mayor profundidad un ejemplo de aplicación (Mutting) que tiene como objetivo reducir la aparición de un accidente poniendo en silencio el dispositivo móvil. Posteriormente hablaremos de otra aplicación (SilentMeet) que aunque no tiene como objetivo reducir los accidentes de tráfico, utiliza información contextual de localización y calendario para poner en silencio el teléfono móvil durante una reunión y, por tanto, resulta de interés para este proyecto.

28

2.3.1. Mutting

Mutting es una aplicación para móviles iOS y Android que mejora la calidad de tu conducción añadiendo un plus de seguridad vial mediante la disminución de distracciones al volante. En la Fig 6 se puede apreciar la interfaz principal de esta app.

Fig 6 Interfaz de Mutting. Fuente: (mutting, 2018)

Esta APP es gratuita y al activarla, se silencian todos los avisos del móvil, anulando no sólo los sonidos sino también las vibraciones, apagando igualmente la pantalla del móvil. Mientras la aplicación está en activo se informa a quien llama que el usuario se encuentra conduciendo, y sólo si la llamada se repite, la aplicación interpreta que es algo urgente y pasa la llamada a manos libres. En el momento en el que el usuario salga del coche se desactivará la aplicación y podrá ver las llamadas y mensajes, pues todo ello queda almacenado en el móvil. Los creadores de Mutting (Desarrollos informáticos JEP) están ubicados en Sevilla y buscan la responsabilidad en los usuarios de centrarse en conducir de forma segura y sin distracciones (mutting, 2018).

29

2.3.2. SilentMeet

Uno de los ejemplos más relevantes de aplicaciones proactivas que usan el calendario y la localización como principal fuente de información contextual es SilentMeet (Dobrican, Neyens, & Zampunieris, 2016).

Fig 7 Dispositivos probando la app SilentMeet.

SilentMeet es un prototipo de aplicación móvil colaborativa basada en la localización para poner el móvil en silencio durante reuniones o eventos importantes.

En un primer paso se utiliza un algoritmo para establecer si un evento es confirmado por sus participantes, y en un segundo se utiliza su localización para determinar si los participantes se encuentran en el lugar del evento el mismo día a la misma hora para poner en silencio sus dispositivos móviles. La aplicación trata de evitar los casos en que los participantes aceptan la invitación pero no acuden al evento, o cuando no responden a la invitación pero asisten al evento. Para coordinar e intercambiar información y tomar decisiones distribuidas usa una técnica llamada GPaSs, para lo que utiliza una arquitectura middleware basada en reglas.

Al ser un prototipo esta app no se encuentra en Google Play para ser descargada, sin embargo en la Fig 7 se puede ver una imagen de los dispositivos utilizados para probar esta app, en la cual se puede apreciar su interfaz principal.

30

3. Diseño

3.1. Requisitos

A continuación se presentan los requerimientos definidos para el sistema a desarrollar. Se ha utilizado la metodología MoSCoW, de modo que se identifique lo que el sistema TIENE, DEBERÍA, PODRÍA y NO TENDRÁ que ser capaz de realizar. Los requerimientos se han extraído a partir de la observación y análisis del problema en cuestión.

El sistema tiene que ser capaz de:

o Conectarse a las distintas APIs de los servicios necesarios de localización y mapas.

o Acceder a los datos del calendario del usuario.

o Guardar los datos en una base de datos local.

o Procesar la información recopilada (calcular la hora de salida, la hora de notificación, etc).

o Crear notificaciones para alertar al usuario de cuándo debe salir para llegar a tiempo a los distintos eventos.

o Crear correos electrónicos para enviarlos a los participantes de los distintos eventos en caso de que el usuario llegue tarde.

o Tener una interfaz gráfica que permita visualizar la lista de eventos así como su localización.

El sistema debería:

o Ser capaz de detectar las situaciones adecuadas en las que actuar.

o No enviar correos electrónicos repetidos o notificar más de una vez para un mismo evento.

o Tener un retraso aceptable en cuanto a actualización de posición y datos.

El sistema podría:

o Ser configurable. Parámetros susceptibles de configuración pueden ser la ventana de notificación (el tiempo antes de la hora de salida que el usuario desea que se le notifique que debe salir para no llegar tarde) o la ventana de email (tiempo que el usuario desea que tarde el sistema en enviar un email una vez que ha detectado que el usuario llega tarde).

o Ser personalizable. En cuanto a temas, colores, mensaje que se le envía a los participantes del evento, estilo de las notificaciones, etc.

El sistema no tendrá esta vez:

o Compatibilidad con otros sistemas operativos (iOS, Windows Phone, etc).

o Compatibilidad con sistemas wearable.

31

3.2. Arquitectura del sistema

En este apartado se describirá la arquitectura propuesta para llevar a cabo el sistema. En la Fig 8 se muestra un diagrama que ilustra esta arquitectura, y posteriormente se procederá a explicar el proceso de comunicación entre cada uno de los componentes.

Fig 8 Arquitectura del sistema.

32

Como se aprecia en el diagrama anterior, el sistema se compondrá de 6 módulos diferenciados:

extractor de datos de calendario: encargado de recolectar los datos del calendario del usuario y guardarlos en la base de datos local. Estas acciones las realizará periódicamente cada cierto espacio de tiempo programado.

extractor de eventos: se encarga de extraer los datos guardados de los eventos periódicamente de la base de datos y realizar una petición al completador de información, solicitando la información restante para tomar una decisión. Una vez recolectada toda la información se la retransmite al decisor basado en reglas.

completador de información: este módulo se encarga de calcular la hora de salida para llegar a tiempo al evento desde la localización actual del usuario. Para ello, primero hace una petición al GPS sobre la localización actual del usuario y, posteriormente, realiza una petición al servidor de localización sobre el tiempo de viaje que hay entre la posición del usuario y la del evento. Con esto calcula la hora de salida. Además, también realiza una petición al servidor de mapas para poder mostrar al usuario la localización del evento a la que debe dirigirse. Una vez recopilada toda esta información se la retransmite al extractor de eventos.

decisor basado en reglas: recibe la información captada por los módulos anteriores, y en base a esta y a la hora actual, toma una decisión sobre cómo actuar. Realiza los cálculos necesarios para determinar una hora de notificación (hora a la que notificar al usuario para que salga hacia el evento y que no llegue tarde), y una hora de email (hora a la que se debe mandar un email a los invitados del evento indicando que el usuario llegará tarde. Nótese que esta hora cambiará con el cambio de la localización del usuario). Si la hora actual es anterior a la hora de notificación, no re realizará nada. Si la hora actual se encuentra entre la hora de notificación y la hora de email, se llamará al recordador de eventos, que notificará al usuario para que salga y se marcará el evento como notificado. Si la hora es posterior a la hora de email, se llamará al generador de emails para que genere un correo electrónico y lo envíe a los participantes del evento y se marcará el evento como email mandado.

recordador de eventos: se encarga de crear una notificación para avisar al usuario de que debe salir si no quiere llegar tarde al próximo evento.

generador de emails: crea un correo electrónico avisando de que el usuario llegará tarde y lo envía a los participantes del evento.

33

A continuación se describirá el proceso de comunicación entre los componentes, ilustrado en la figura 5.

(1) El extractor de datos de calendario hace una solicitud al reloj para saber si debe entrar en acción.

(2) El reloj responde con la hora actual.

(3) El extractor de datos de calendario hace una solicitud al servidor de calendario.

(4) El servidor de calendario responde con los eventos existentes en el calendario del usuario.

(5) El extractor de datos de calendario guarda los eventos en la base de datos local.

(6) El extractor de eventos hace una solicitud al reloj para saber si debe entrar en acción.

(7) El reloj responde con la hora actual.

(8) El extractor de eventos hace una petición a la base de datos local.

(9) La base de datos local responde a la petición con los eventos almacenados.

(10) El extractor de eventos realiza una petición al completador de información pidiéndole la hora de salida y el mapa con la localización del evento.

(11) El completador de información realiza una petición al GPS pidiéndole la ubicación actual del usuario.

(12) El GPS responde con la ubicación actual del usuario.

(13) El completador de información realiza una petición al servidor de localización preguntándole por el tiempo de viaje desde la ubicación actual del usuario a la del evento.

(14) El servidor de localización responde con el tiempo de viaje.

(15) El completador de información realiza una petición al servidor de mapas pidiéndole el mapa con la localización del evento.

(16) El servidor de mapas responde con el mapa.

(17) El completador de información transmite la información adicional al extractor de eventos.

(18) El extractor de eventos envía el evento y la información necesaria al decisor.

(19) El decisor hace una consulta al reloj.

(20) El reloj responde con la hora actual.

34

A partir de aquí se abren tres posibles ramas de ejecución, representadas en la Fig 9:

Si la hora actual es anterior a la hora de notificación termina el proceso.

Si la hora actual se encuentra entre la hora de notificación y la de email, y el evento no ha sido notificado anteriormente, se marca el evento como notificado y se precede de la siguiente forma:

(21) El decisor llama al recordador de eventos.

(24) El recordador de evento notifica el usuario.

Si la hora actual es posterior a la hora de email y para ese evento aún no se ha mandado correo electrónico se marca el evento y se procede de la siguiente forma:

(21) El decisor llama al generador de emails.

(22) El generador de emails manda los correos electrónicos al servidor de email.

(23) El servidor de email manda los correos electrónicos a los participantes del evento.

Fig 9 Árbol de decisión.

35

Capítulo 4

4. Implementación

4.1. Software utilizado

4.1.1. Java

Java es un lenguaje de programación y una plataforma informática comercializada por primera vez en 1995 por Sun Microsystems (Oracle, 20015). Las principales características de este lenguaje son (Tutorial de Java, 2005):

Orientado a objetos: el enfoque orientado a objetos es uno de los estilos de programación más popular. En la programación orientada a objetos, un problema complejo se divide en conjuntos más pequeños mediante la creación de objetos. Esto hace que el código sea reutilizable, tenga beneficios de diseño y haga que el código sea más fácil de mantener.

Compilado e interpretado: el compilador de java es el encargado de convertir el código fuente de un programa en un código intermedio llamado bytecode que es independiente de la plataforma en que se trabaje. Este bytecode es ejecutado posteriormente por el intérprete de Java que forma parte de la Máquina Virtual de Java (JVM) y que traduce el bytecode a lenguaje máquina.

Independiente de la plataforma: java se creó con la filosofía de “escribe una vez, ejecuta en cualquier lado” (WORA). El código de Java escrito en una plataforma (sistema operativo) se ejecutará en otras plataformas sin modificaciones. Esto es gracias a la propiedad anteriormente citada.

Rápido: el código Java bien optimizado es casi tan rápido como los lenguajes de nivel inferior como C/C ++, y mucho más rápido que Python, PHP, etc.

Seguro: la plataforma Java proporciona varias características para la seguridad de las aplicaciones Java. Algunas de las características de alto nivel que maneja Java son:

o Proporciona una plataforma segura para desarrollar y ejecutar aplicaciones

o Administración automática de memoria, reduce la corrupción de la memoria y vulnerabilidades

o Proporciona comunicación segura al proteger la integridad y privacidad de los datos transmitidos

Multihilo: java puede llevar a cabo varias tareas simultáneamente dentro del mismo programa mejorando el rendimiento y velocidad de ejecución.

Distribuido: contiene una gran biblioteca de clases para la utilización del protocolo TCP/IP. El código java se puede manipular a través de recursos URL fácilmente.

36

Sólido: usa una sintaxis rigurosa, lo que evita que se quiebre fácilmente ante errores de programación. Por ejemplo, no permite escribir en zonas arbitrarias de la memoria que corrompan el código.

Amplio conjunto de bibliotecas: una de las razones por las que Java es ampliamente utilizado es debido a la disponibilidad de una gran biblioteca estándar.

4.1.2. XML

Se utilizará XML para realizar el diseño gráfico de la aplicación. XML es un lenguaje de marcado similar a HTML. De las siglas Extensible Markup Language (Lenguaje de Marcado Extensible) y es una especificación de W3C como lenguaje de marcado de propósito general. Esto significa que, a diferencia de otros lenguajes de marcado, XML no está predefinido, por lo que el usuario debe definir sus propias etiquetas. El propósito principal del lenguaje es compartir datos a través de diferentes sistemas, como Internet (Mozilla Developers, 2019).

En la Fig 10 se muestra un ejemplo de fichero XML que se ha utilizado en la aplicación para realizar la interfaz gráfica de la actividad “DisplayContactsActivity”.

Fig 10 Fichero XML del layout de DisplayContactsActivity.

37

4.1.3. Android Studio

Android Studio es el entorno de desarrollo integrado (IDE) oficial para el desarrollo de apps para Android, basado en IntelliJ IDEA. Fue anunciado el 16 de mayo de 2013 en la conferencia Google I/O, y reemplazó a Eclipse como el IDE oficial para el desarrollo de aplicaciones para Android. La primera versión estable fue publicada en diciembre de 2014. (Android Developers, 2017).

Como herramientas integradas para el desarrollo de programas en Android, contiene una interfaz de usuario con variados modelos de pantalla, en la que los elementos existentes pueden ser desplazados. IntelliJ IDEA soporta variados lenguajes de programación que se basan en JVM; Java, Clojure, Groovy, Kotin y Scala.

En cuanto al desarrollo del flujo de trabajo, Android Studio posee un conjunto de herramientas encargadas, a lo que se le suma el posible acceso desde la línea de comandos a las herramientas SDK (Software Development Kit). El SDK de Android, incluye un conjunto de herramientas de desarrollo que comprende un depurador de código, bibliotecas, un simulador de teléfono basado en QEMU, documentación, ejemplos de código y tutoriales.

Además del potente editor de códigos y las herramientas para desarrolladores de IntelliJ, Android Studio ofrece más funciones que aumentan la productividad cuando se desarrollan apps para Android. Las funciones más destacadas recogidas de la guía de usuario de Android Studio (Introducción a Android Studio, 2017) son:

- Un sistema de compilación flexible basado en Gradle. Con esta tecnología, asociada a Android Studio, las posibilidades son cómodas para la creación y construcción de aplicaciones para este sistema.

- Un emulador rápido y lleno de funciones, depuración y la posibilidad de trabajo con Logcat.

- Un entorno unificado donde se puede desarrollar para todos los dispositivos Android.

- Aplicación de cambios para insertar cambios de códigos y recursos a la aplicación en ejecución sin reiniciar la aplicación.

- Integración con GitHub y plantillas de código que sirven de ayuda a la hora de compilar funciones de apps comunes y para importar código de ejemplo.

- Variedad de marcos de trabajo y herramientas de prueba.

- Herramientas de Lint para identificar problemas de rendimiento, usabilidad y compatibilidad de la versión, entre otros.

- Compatibilidad con C++ y NDK.

- Compatibilidad integrada para Google Cloud Platform, que facilita la integración con Google Cloud Messaging y App Engine.

38

En el diagrama de la Fig 11 se pueden apreciar las etapas para la realización de aplicaciones en Android Studio:

1. Configuración de entorno: se instala el Android SDK y las herramientas de desarrollo Android. Además se realiza la conexión a los elementos en donde se pueden realizar la instalación de las app, y se crean dispositivos virtuales.

2. Configuración del Proyecto y Desarrollo: creación de módulos que contengan recursos para la aplicación, archivos de código fuente y el archivo Android Manifest.

3. Pruebas, depuración y construcción de la aplicación: se construye el proyecto en un paquete depurable .apk que se puede instalar y ejecutar en el emulador o en un dispositivo con Android. Posteriormente, se hace la depuración de la aplicación a través de las herramientas de depuración (debugging) y registro (logging) que proporciona Android. Para finalizar, se pone a prueba la aplicación.

4. Publicación de la aplicación: se realiza la configuración y se arma la solicitud para el uso y libre distribución de la aplicación a los usuarios. Durante la etapa de preparación se construye una versión de la aplicación, que los usuarios pueden descargar e instalar en sus dispositivos de modo que se pueda vender y distribuir la versión de esta.

En la Tabla 1 se pueden ver los requisitos necesarios para instalar Android Studio v3.

Windows OS X/ macOS Linux

OS version Windows 10/8/7 (32-o 64-

bit)

Mac OS X 10.10 (Yosemite) o superior,

hasta 10.13 ( macOS High Sierra)

GNOME o KDE desktop

RAM 4 GB RAM mínimo, 16 GB RAM recomendado más 1GB adicional para el emulador de

Android

Espacio en disco 2 GB de espacio en disco para Android Studio, 4GB recomendados (500MB para la IDE y

al menos 1.5 GB para Android SDK, imágenes de sistema de emulador y cachés)

Java version Java Development Kit (JDK) 8

Resolución de pantalla 1280x800 mínimo, 1440x900 recomendado

Tabla 1 Requisitos del sistema para instalar Android Studio v3.

Fig 11 Diagrama de las distintas etapas para la realización de aplicaciones en Android Studio. Fuente: (Android Developers, 2017)

39

4.1.4. Realm

Para la persistencia de datos en la aplicación se ha utilizado Realm. (Realm, 2017).

Realm Platform es una combinación de dos componentes (cliente y servidor) basados en noSQL conectados a través de un protocolo de sincronización rápido y eficiente para permitir operar en tiempo real a aplicaciones y servicios conectados que responden y funcionan independientemente del estado de la red. Realm Platform tiene dos componentes principales: Realm Database y Realm Object Server. Estos dos componentes funcionan en conjunto para sincronizar automáticamente los datos. A esto se le suma su capacidad de integración con backends existentes (SQL, Kafka, etc). En nuestro caso solo se utilizará Realm Database. En la Fig 12 se puede apreciar un esquema de Realm platform.

Fig 12 esquema de Realm Platform. Fuente: (Realm, 2017)

4.1.4.1. Realm Database

Integrada en el cliente, Realm Database es una base de datos multiplataforma, orientada a objetos que permite la persistencia de los datos localmente en el dispositivo. Está disponible para los principales lenguajes móviles, como Swift y Objective-C (iOS), Java (Android), C # (Xamarin, .NET) y JavaScript (React Native y Node.js).

Es ligera y de alto rendimiento, capaz de manejar cargas de datos muy grandes y ejecutar consultas en fracciones de segundo. Está basada en objetos vivos compartidos, y es capaz de sincronizar datos en tiempo real con el Realm Object Server sin la necesidad de escribir código de red, serialización o mapeo relacional de objetos.

4.1.4.2. Realm frente SQLite

Una de las principales ventajas de usar Realm frente a la famosa base de datos SQLite es la gran facilidad que ofrece a la hora de su configuración y mantenimiento. A esto se le suma la gran cantidad de documentación disponible en su plataforma web. Además, según los tests realizados en Top Digital Agency (2018) la base de datos Realm es más rápida que SQLite. Aun así SQLite es mejor opción a la hora de gestionar muchas peticiones por segundo, y ofrece una gran portabilidad, ya que es básicamente un fichero.

En conclusión, podríamos decir que para proyectos sencillos que no realicen demasiadas llamadas simultáneas a la base de datos, Realm es la mejor herramienta con la que trabajar, ya que posibilita un rápido y más sencillo desarrollo con un gran rendimiento. Sin embargo, para proyectos más complejos que requieran el manejo de un gran número de peticiones por segundo, SQLite sería la opción más acertada.

40

4.1.5. Interfaces de Programación de Aplicaciones (APIs)

Una interfaz de programación de aplicaciones (API) proporciona un conjunto de comandos, funciones y protocolos para facilitar la programación de software. Estas funciones predefinidas simplifican la interacción del programador con el sistema operativo, ya que el hardware (monitor, datos en el disco duro, etc.) no tiene que ser direccionado directamente. En lo que se refiere a Internet, las APIs Web están a la vanguardia y también sirven como interfaz para permitir el uso de funciones existentes de terceros.

Una API web es una interfaz para páginas y aplicaciones web. Se utiliza en el intercambio y procesamiento de contenidos entre webs y permite a terceros acceder a grupos de datos y círculos de usuarios. La API de autorización y la API de autenticación son dos tipos especiales de API web. (Rytewiki, 2019).

El motor de búsqueda de Google proporciona muchas APIs como parte de sus servicios. Esto permite que otras webs pasen los servicios de Google directamente a sus visitantes sin necesidad de recuperar el sitio web de Google. En este proyecto se utilizan las siguientes APIs de Google:

4.1.5.1. Directions API

Esta API es un servicio que calcula indicaciones entre ubicaciones mediante una solicitud HTTP. En el caso de este proyecto se utiliza para calcular el tiempo que se tarda en llegar desde la ubicación actual del usuario hasta la ubicación del evento, y entre las ubicaciones de dos eventos consecutivos en el tiempo. (Google Developers, 2017)

Con esta API se puede:

- Buscar indicaciones para distintos medios de transporte, incluidos transporte público, en coche, a pie o en bicicleta.

- Obtener indicaciones por partes, utilizando una serie de puntos de referencia.

- Especificar orígenes, destinos y puntos de referencia como cadenas de texto, a partir de sus coordenadas, o con su identificador.

- La API devuelve la ruta más eficiente entre dos ubicaciones. El tiempo de viaje es el principal factor a optimizar, pero también tiene en cuenta factores como la distancia, o el número de curvas, entre otros, para decidir qué ruta es la más eficiente.

Las peticiones a esta API tienen la siguiente forma:

https://maps.googleapis.com/maps/api/directions/outputFormat?parameters

En nuestro caso el formato de salida (outputFormat) será “json” que indica que la respuesta será un objeto JSON.

41

Los parámetros utilizados son los siguientes:

o origin: la dirección, coordenadas o identificador desde el cual se quieren empezar a calcular las indicaciones. Los siguientes ejemplos representan la misma ubicación:

origin=ETSIIT

origin=CallePeriodistaDanielSaucedoAranda,18014,Granada,España

origin=37.197308,-3.624502

o destination: la dirección, coordenadas o identificador hasta el cual se quieren calcular las indicaciones. El formato es igual que origin.

o key: la clave API de la aplicación. Este campo identifica la aplicación con propósitos de gestión y tarificación. Más adelante se explicará el proceso para conseguir una clave API.

Un ejemplo de petición con origen en la ETSIIT y destino en la calle Pintor López Mezquita sería el siguiente:

https://maps.googleapis.com/maps/api/directions/json?origin=ETSIIT&destination=c

allepintorlopezmezquita,granada&key=AIzaSyCF73lqckrWLqI7OOWgzjOS5Z6FUrAO

M2U

Si hacemos click en el enlace anterior podemos visualizar la respuesta, que será un objeto JSON. Dentro de este, la información que nos interesa para calcular la hora a la que el usuario debe salir hacia el evento es el campo “duration”, que se encuentra dentro de “routes”, “legs”.

En la Fig 13 se muestra un fragmento de la respuesta recibida, la cual debe ser parseada por nuestra app para obtener la información que nos interesa.

Fig 13 Fragmento de la respuesta JSON

42

4.1.5.2. Maps Static API

Esta API permite insertar una imagen de Google maps en nuestra aplicación a partir de una petición URL. (Google Developer, 2017)

Los parámetros que se itilizan son los siguientes:

o Zoom: el nivel de detalle representado en la imagen.

o Size: el tamaño de la imagen.

o Maptype: el tipo de mapa (satélite, de carretera, simplificado, etc) en este caso será de carretera (roadmap).

o Markers: marcados de un lugar que queremos destacar. Además se le pueden añadir parámetros como el color del marcador o una etiqueta.

o Key: La API key de la aplicación.

A continuación se muestra un ejemplo de la petición:

http://maps.google.com/maps/api/staticmap?center=ETSIIT&zoom=15&size=1500x2

00%20&sensor=false&markers=color:red%7CETSIIT&key=AIzaSyCF73lqckrWLqI7OO

WgzjOS5Z6FUrAOM2U

Y este sería el resultado:

Fig 14 Ejemplo de respuesta de un mapa estático.

43

4.1.5.3. Calendar Provider API

El Proveedor de calendario es un repositorio de los eventos de calendario de un usuario. La API del Proveedor de calendario permite consultar, insertar, actualizar y borrar operaciones de calendarios, eventos, asistentes, recordatorios, etc.

Para leer datos del calendario, una aplicación debe contar con el permiso READ_CALENDAR en su archivo de manifiesto. Debe incluir el permiso WRITE_CALENDAR para borrar, insertar o actualizar datos del calendario:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"...>

<uses-sdk android:minSdkVersion="14" />

<uses-permission android:name="android.permission.READ_CALENDAR" />

<uses-permission android:name="android.permission.WRITE_CALENDAR" />

...

</manifest>

El proveedor de contenido que ofrece la plataforma Android expone los datos como un conjunto de tablas basadas en un modelo de base de datos relacional en el que cada fila es un registro y cada columna consiste en datos de un tipo y un significado específicos. A través de la API de Proveedor del calendario, las aplicaciones y los adaptadores de sincronización pueden obtener acceso de lectura/escritura a las tablas de la base de datos que contienen datos del calendario de un usuario. (Android Developers, 2017)

En la Fig 15 se muestra una representación gráfica del modelo de datos del Proveedor de calendario, ilustrando las tablas principales y los campos que las vinculan entre sí.

Fig 15 Modelo de datos del proveedor de calendario. Fuente: (Android Developers, 2017)

44

4.1.5.4. Activar una API y conseguir una API key

Para usar una API primero se debe activar y conseguir una API key. A continuación se explicará el proceso a seguir para ello:

1. En primer lugar deberemos crearnos una cuenta de Google.

2. Tras esto nos dirigimos a Google Cloud Console.

3. Una vez allí creamos un nuevo proyecto (Fig 16).

Fig 16 Creación de un nuevo proyecto.

4. A continuación buscamos en la biblioteca las APIs que queremos utilizar y hacemos click en habilitar (Fig 17 y Fig 18).

Fig 17 Busqueda de las APIs a utilizar.

Fig 18 Habilitar API.

45

5. Volvemos a al visor general de APIs y servicios y hacemos click en credenciales (Fig 19).Tras esto nos aparecerá una ventana con un desplegable que nos preguntará por el tipo de credencial que queremos crear. Seleccionamos “Clave de API” (Fig 20).

Fig 19 Seleccionar credenciales.

Fig 20 Seleccionar clave API.

6. Una vez hecho esto habremos creado con éxito nuestra API key que luego copiaremos en el archivo “manifest” de nuestra aplicación para darle acceso a los diferentes servicios. Si a continuación hacemos click en restringir clave (Fig 21) podremos restringir algunos parámetros como se muestra en la Fig 22 para impedir el uso no autorizado en producción.

46

Fig 21 Clave API.

Fig 22 Restricciones de clave.

47

4.2. Clases y métodos

En este apartado se presenta las clases utilizadas en el proyecto, así como sus métodos. En la Fig 23 se muestra un diagrama UML que describe la relación entre las clases del proyecto. Posteriormente serán explicadas en mayor profundidad las clases más importantes así como sus métodos.

4.2.1. Main Activity

Una actividad es un componente de la aplicación que contiene una pantalla con la que los usuarios pueden interactuar. Esta es la actividad principal desde la cual se estructura la aplicación, y se muestra una interfaz gráfica al usuario. En ella se crea una instancia de la base de datos, se programan los servicios que se encargarán de actualizar la base de datos y de notificar o enviar un mensaje electrónico, y se muestra al usuario una lista con los eventos del día de hoy. Todo esto se realiza dentro del método onCreate.

4.2.2. DisplayContactsActivity

Esta actividad se encarga de mostrar al usuario la lista de contactos invitados al evento seleccionado, dándole la posibilidad de seleccionarlos para mandarles un correo electrónico. Esto se realiza dentro del método onCreate.

Fig 23 Diagrama UML del proyeto.

48

4.2.3. Clase Evento

Esta clase representa un evento del calendario al que debe asistir el usuario. Además, esta clase extiende de RealmObject, lo cual es necesario para que pueda ser almacenado en la base de datos Realm.

4.2.3.1. Datos Miembro

id: Tipo long. Identificador del evento. Este número identifica unívocamente a cada evento de cualquier otro.

nombre: Tipo String. Nombre del evento.

horaEvento: Tipo Date. Hora a la que comienza el evento.

horaSalida: Tipo Date. Hora a la que debería salir el usuario para llegar a tiempo. (horaEvento - tiempo de viaje desde la posición actual).

ubicacionEvento: Tipo String. Dirección o coordenadas del lugar donde tiene lugar el evento.

ubicaciónInicial: Tipo String. Ubicación desde la que calcular la hora de salida. Puede ser la ubicación actual del usuario o la ubicación del evento anterior.

invitados: Tipo RealmList<String>. Lista de los correos electronicos de los participantes del evento.

4.2.3.2. Constructores

public Evento(): Constructor sin parámetros. Realm necesita un constructor sin parámetros para su funcionamiento, es por ello que debemos incluirlo.

public Evento (long id, String nombre, Date horaEvento, String ubicacionEvento, String ubicacionInicial,RealmList<String> invitados) : El constructor más completo. La hora de salida se calculará y asignará posteriormente a partir de la ubicación del evento, la hora del evento y la ubicación inicial.

public Evento (long id, String nombre, Date horaEvento, String ubicacionEvento, String ubicacionInicial): Constructor sin invitados.

public Evento (long id, String nombre, Date horaEvento, String ubicacionEvento): Constructor con los datos basicos del evento procedentes de la consulta al calendario.

49

4.2.3.3. Métodos

public Date getHoraSalida(): Método público que devuelve la hora de salida.

public String getUbicacionInicial(): Método público que devuelve la ubicación inicial desde la que se calcula la hora de salida.

public long getID(): Método público que devuelve el identificador del evento.

public long getNombre(): Método público que devuelve el nombre del evento.

public Date getHoraEvento(): Método público que devuelve la hora de comienzo del evento.

public String getUbicacionEvento() : Método público que devuelve la ubicación donde tiene lugar el evento.

public List<String> getInvitados(): Método público que devuelve la lista de invitados al evento.

public void añadirInvitado(String invitado): Método público que recibe como parámetro el correo de un nuevo invitado y lo añade a la lista de invitados al evento.

public void setInvitados(RealmList<String> invitados): Método público que recibe como parámetro una lista de invitados y la asigna al evento.

public void calcularHorasalida(): Método público que a partir de la localización del evento y la localización inicial, hace una petición a Google directions API y calcula el tiempo de viaje. Tras esto hace uso de otro método auxiliar (sumarRestarSegundosfecha) para restar a la hora del evento el tiempo de viaje y así obtener la hora de salida. Tras esto asigna el valor obtenido al dato miembro horaSalida. Este procedimiento se explicará más detalladamente en el apartado 4.3.

public static Date sumarRestarSegundosFecha(Date fecha, int segundos): Método público y estático que recibe como parámetros una fecha y un tiempo en segundos y devuelve una nueva fecha resultante de la suma o resta de ambos. Si queremos sumar el tiempo en segundos debe ser positivo, y si queremos restar negativo.

50

4.2.4. Clase EventAdapter

Un adaptador es un objeto que implementa la interfaz “Adapter” y que actúa como enlace entre un conjunto de datos y un adaptador vista (un objeto de una clase que extiende a la clase abstracta AdapterView), en nuestro caso un Listview. El conjunto de datos puede ser cualquier cosa que presente datos en una manera estructurada, pero en nuestro caso se trata de la lista de eventos rescatados del calendario del usuario y que queremos representar en pantalla. (envatotuts+, 2016)

Este adaptador extiende de la clase “BaseAdapter” y es el responsable de rescatar los eventos de la lista de eventos y generar objetos View. Posteriormente estos objetos View generados son usados para rellenar nuestro Listview en el MainActivity.

4.2.4.1. Datos Miembro

context: Tipo Context. Contexto en el que se desea usar el adaptador.

eventos: Tipo List<Evento>.Lista de Eventos de los que recogemos los datos para posteriormente inflar cada objeto View.

layout: Tipo int. Referencia al layout con la interfaz gráfica para inflar los objetos View.

4.2.4.2. Constructor

public EventAdapter(Context context, List<Evento> eventos, int layout): Pasamos como parametros los datos miembro y los asignamos.

4.2.4.3. Métodos

public int getCount(): Devuelve el tamaño de la lista de eventos.

public Evento getItem(int position): Devuelve el evento que se encuentra en la posicion indicada.

public long getItemId(int position): Devuelve el ID del evento en la posición indicada.

public View getView(final int position, View convertView, ViewGroup parent): Devuelve la vista inflada, es decir, el objeto View con los datos del evento y con la interfaz reflejada en el layout. Para ello creamos un viewHolder que contiene los distintos contenedores de datos (TextViex, ImageView…) y los relleamos con los datos del evento (e incluso realizando una petición a un servidor externo para cargar una imagen del mapa que indica la ubicación del evento). Este proceso será visto en mayor profundidad en el apartado 4.3.

51

4.2.5. Clase ContactAdapter

Este adaptador extiende de la clase “BaseAdapter” y es el responsable de rescatar los correos electrónicos de los invitados a cada evento y generar objetos View. Posteriormente estos objetos View generados son usados para rellenar nuestro Listview en el ContactActivity.

4.2.5.1. Datos Miembro

context: Tipo Context. Contexto en el que de desea usar el adaptador.

contactos: Tipo List<String>.Lista con el correo electrónico de cada uno de los invitados al evento de la que recogemos los datos para posteriormente inflar cada objeto View.

layout: Tipo int. Referencia al layout con la interfaz gráfica para inflar los objetos View.

4.2.5.2. Constructor

public ContactAdapter(Context context, List<String> contactoss, int layout): Pasamos como parametros los datos miembro y los asignamos.

4.2.5.3. Métodos

public int getCount(): Devuelve el tamaño de la lista de invitados.

public Evento getItem(int position): Devuelve el correo electrónico del invitado que se encuentra en la posicion indicada.

public long getItemId(int position): Devuelve el ID del invitado en la posición indicada.

public View getView(final int position, View convertView, ViewGroup parent): Devuelve la vista inflada, es decir el objeto View con los datos del evento y con la interfaz reflejada en el layout. Para ello creamos un viewHolder que contiene los distintos contenedores de datos (TextViex, Checkbox…) y los relleamos con los datos del invitado.

52

4.2.6. Clase Tasks

Esta clase contiene los métodos que implementan las tareas que se realizarán en segundo plano. Estas tareas son:

- Obtener los eventos del calendario y guardarlos en la base de datos.

- Realizar una serie de comprobaciones y en función de estas notificar al usuario, mandar un email o no hacer nada.

4.2.6.1. Constantes

public static final String ACTION_FETCH_CALENDAR_DATA: Llamar al método fetchCalendarData.

public static final String ACTION_CHECK_AND_NOTIFY: Llamar al método checkAndNotify.

public static final int VENTANA_NOTIFICACION_MIN: Número de minutos antes de la hora de salida para notificar al usuario que debe salir.

public static final int VENTANA_NOTIFICACION_SEG: Número de segundos antes de la hora de salida para notificar al usuario que debe salir. VENTANA_NOTIFICACION_MIN x 60.

public static final int VENTANA_EMAIL_MINS: Número de minutos después de la hora del evento para mandar un email a los participantes del evento.

public static final int VENTANA_EMAIL_SEG: Número de segundos después de la hora del evento para mandar un email a los participantes del evento. VENTANA_EMAIL_MINS x 60.

private static long lastnotifiedEventID; Identificador del ultimo evento notificado.

private static long lastmailedEventID; Identificador del ultimo evento en el cual se ha mandado un correo electrónico a los participantes.

4.2.6.2. Métodos

public static void executeTask(Context context, String action): Ejecuta la acción deseada. Dependiendo de la acción indicada llama al método checkAndNotify() o fetchCalendarData().

private static void checkAndNotify(Context context): Este método se encarga de crear una fecha para notificar(fecha de salida - VENTANA_NOTIFICACION_SEG) y una para mandar el email (fechaEvento + VENTANA_EMAIL_SEG). Si la fecha actual es antes de la fecha de notificación no actúa. Si la fecha actual es después de la fecha a notificar pero antes que la fecha para mandar el email y el evento no ha sido notificado, lo notifica. Si por el contrario la fecha actual es después de la fecha a mandar el email y no se ha mandado un email antes para este evento, manda un email a los invitados del evento comunicando que el usuario llegará tarde. Este método será estudiado con mayor detalle en el apartado 4.3.

private static boolean checIfNotified(long id): Comprueba si el evento ya ha sido notificado.

private static boolean checIfMailed(long id): Comprueba si ya se ha mandado un email

53

a los invitados del evento.

private static void sendEmail(Context context, Evento evento): Manda un email notificando a los invitados del evento pasado como parámetro que el usuario llegará tarde.

private static void fetchCalendarData(Context context): Este método hace una consulta al calendario y guarda en la base de datos los eventos que el usuario tiene programados para el día actual desde la hora actual hasta las 12:00 pm. Este método será estudiado en mayor profundidad en el apartado 4.3.

public static void saveNewEvent(Evento evento) : Guarda el evento pasado como parámetro en la base de datos.

public static void clearDataBase(): Borra todos los eventos de la base de datos.

4.2.7. Clase FetchCalendarDataJobService

Un Servicio es un componente de una aplicación que puede realizar operaciones de larga ejecución en segundo plano y que no proporciona una interfaz de usuario. Otro componente de la aplicación puede iniciar un servicio y continuar ejecutándose en segundo plano aunque el usuario cambie a otra aplicación. Además, un componente puede enlazarse con un servicio para interactuar con él e incluso realizar una comunicación entre procesos (IPC). (android developers, 2016).

Esta clase extiende de la clase JobService y se encarga de ejecutar la acción ACTION_FETCH_CALENDAR_DATA, anteriormente definida en la clase Tasks, en segundo plano.

4.2.7.1. Métodos

protected Object doInBackground(Object[] objects): Llama al método executeTask() pasando como parametro la acción ACTION_FETCH_CALENDAR_DATA. Por defecto los “jobs” son ejecutados en la hebra principal, por lo que este método crea una tarea asíncrona para que la acción sea ejecutada en otra hebra.

protected void onPostExecute(Object o): Llama al método JobFinished() para notificar al “JobManager” que el “job” ha terminado, pasándole los “jobParameters” y una variable booleana que representa si el “job” necesita ser reprogramado.

public boolean onStopJob(@NonNull JobParameters jobParameters): Comprueba si la tarea en segundo plano iniciada anteriormente se encuentra en ejecución, y en tal caso la cancela.

54

4.2.8. Clase CheckAndNotifyJobService

Esta clase extiende de la clase JobService y se encarga de ejecutar la acción ACTION_CHECK_AND_NOTIFY, anteriormente definida en la clase Tasks, en segundo plano.

4.2.8.1. Métodos

protected Object doInBackground(Object[] objects): Llama al método executeTask() pasando como parámetro la acción ACTION_CHECK_AND_NOTIFY. Por defecto los “jobs” son ejecutados en la hebra principal, por lo que este método crea una tarea para que la acción sea ejecutada en otra hebra.

protected void onPostExecute(Object o): Llama al método JobFinished() para notificar al “JobManager” que el “job” ha terminado, pasándole los “jobParameters” y una variable booleana que representa si el “job” necesita ser reprogramado.

public boolean onStopJob(@NonNull JobParameters jobParameters): Comprueba si la tarea en segundo plano iniciada anteriormente se encuentra en ejecución, y en tal caso la cancela.

4.2.9. Clase NotificationsUtils

Esta clase contiene métodos y constantes útiles para la generación de notificaciones.

4.2.9.1. Constantes

private static final int EVENT_REMINDER_NOTIFICATION_ID: Identificador de la notificación.

private static final int PENDING_INTENT_ID: Identificador del “pending intent”.

private static final String EVENT_REMINDER_NOTIFICATION_CHANNEL_ID: Identificador del canal de notificación.

4.2.9.2. Métodos

public static void clearAllNotifications(Context context): Cancela todas las notificaciones existentes en el canal de notificaciones.

public static void remindUserForEvent(Context context, String nombreEvento, Date horaSalida): Crea un canal de notificaciones y muestra una notificación al usuario diciéndole que debe salir si no quiere llegar tarde al siguiente evento.

private static PendingIntent contentIntent(Context context): Crea un “pending intent” para que al pulsar sobre la notificación nos lleve a la aplicación.

private static Bitmap largeIcon(Context context): Devuelve el icono de nuestra aplicación para que pueda ser mostrado en la notificación.

55

4.2.10. Clase ScheduleUtilities

Esta clase contiene métodos y constantes útiles para programar los JobServices descritos anteriormente (CheckAndNotifyJobService y FetchCalendarDataJobService).

4.2.10.1. Constantes

private static final int FETCH_INTERVAL_MINUTES: Indica cada cuanto tiempo en minutos el FetchCalendarDataJobService debe ser llamado.

private static final int FETCH_INTERVAL_SECONDS: Indica cada cuanto tiempo en segundos el FetchCalendarDataJobService debe ser llamado.

private static final int FETCH_SYNC_FLEXTIME_SECONDS: Indica la flexibilidad segundos que tiene el sistema para llamar a FetchCalendarDataJobService.

private static final String FETCH_JOB_TAG: Identificador para que el FetchCalendarDataJobService sea programado.

private static boolean fetchInitialized: Indica si el FetchCalendarDataJobService ya ha sido programado.

private static final int CHECK_INTERVAL_MINUTES: Indica cada cuanto tiempo en minutos el CheckAndNotifyJobService debe ser llamado.

private static final int CHECK_INTERVAL_SECONDS: Indica cada cuanto tiempo en segundos el CheckAndNotifyJobService debe ser llamado.

private static final int CHECK_SYNC_FLEXTIME_SECONDS: Indica la flexibilidad segundos que tiene el sistema para llamar a CheckAndNotifyJobService.

private static final String CHECK_JOB_TAG: Identificador para que el CheckAndNotifyJobService sea programado.

private static boolean checkInitialized: Indica si el FetchCalendarDataJobService ya ha sido programado.

4.2.10.2. Métodos

synchronized public static void scheduleFetchCalendarData(@NonNull final Context context): Programa el FetchCalendarDataJobService en el tiempo.

synchronized public static void scheduleCheckAndNotify(@NonNull final Context context): Programa el CheckAndNotifyJobService en el tiempo.

4.2.11. Clases HTTPClient, Response, AndroidHelper, OnHttpRequestComplete, DownloadImageTask

Estas clases forman parte de librerías externas incluidas en el proyecto para realizar peticiones HTTP. Serán utilizadas para realizar peticiones a las distintas APIs. Puesto que no se han realizado específicamente para este proyecto, no serán explicadas, tan solo nombradas.

A continuación se muestra un enlace al tutorial donde se explica cómo utilizar estas clases y como incluirlas en el proyecto. https://www.youtube.com/watch?v=vo8vhS2aHJ4&t=1216s

56

4.3. Descripción de algunas funcionalidades a través de fragmentos de código.

A continuación se mostrarán algunos fragmentos de código que se han considerado interesantes para ilustrar el funcionamiento de algunos métodos, algoritmos o funcionalidades de la aplicación

4.3.1. Calcular la hora de salida

Esta operación la realizamos llamando al método “calcularHoraSalida()”. Este método asigna a la variable “HoraSalida” de un objeto evento la hora a la que debe salir el usuario para no llegar tarde al evento. Para ello realiza una petición a la API Directions de Google. Para realizar esta llamada lo primero que debemos hacer es montar la url.

Como se explicó anteriormente en el apartado 4.1.5.1 la forma que debe tener la url para realizar la petición es la siguiente:

https://maps.googleapis.com/maps/api/directions/outputFormat?parameters

Recordemos que el formato de salida será “json”, y los parámetros utilizador serán “origin”, “destination” y “key” (para información más detallada sobre cómo realizar las consultas a esta API consultar el apartado 4.1.5.1)

En el campo “origin” pondremos la ubicación desde la cual se quiere calcular la ruta (posición actual del usuario o localización del evento anterior), en el campo “destination” la ubicación del evento, en el campo “key” la API key que hemos generado para este proyecto. Utilizamos el método “replaceAll()” para reemplazar todos los espacios que puedan contener las direcciones de origen y destino por cadenas vacías, ya que una url no puede contener espacios (Fig 24).

Fig 24 Montar la url para realizar la petición

A continuación creamos un cliente http y sobre escribimos el método onComplete(). Cuando se complete la petición, si la respuesta ha sido exitosa, procedemos a parsear el objeto JSON que habremos obtenido. La información que nos interesa se encuentra dentro del campo “routes”, “legs” y tiene la etiqueta “duration” que nos proporcionará la duración del trayecto en segundos. Después obtenemos la hora de salida restando a la hora del evento la duración del trayecto. Esto lo realizamos con el método auxiliar sumarRestarSegundoFecha (Fig 25).

En la Fig 26 se muestra un fragmento de la respuesta JSON.

57

Fig 25 Extraemos la información de la respuesta en JSON

Fig 26 Fragmento de la respuesta JSON.

Ahora solo nos restaría ejecutar el cliente (Fig 27).

Fig 27 Ejecutamos el cliente.

58

4.3.2. Cargar los datos del calendario

Esta operación se realiza en la clase “Tasks”, concretamente en el método “fetchCalendarData()”. Este método accede al calendario del usuario y recoge los eventos que tiene programados para ese día, para posteriormente guardarlos en la base de datos local.

Para realizar esta tarea haremos uso de la API de proveedor de calendario previamente explicada en el apartado 4.1.5.3.

En un primer lugar creamos un array de Strings con los identificadores de los campos que queremos consultar, y creamos constantes que indiquen los índices de estos campos. La consulta se realizará a la tabla Instances (Fig 28).

Fig 28 Creamos un array con los identificadores y asignamos los índices.

Ahora especificamos el rango de tiempo en el que queremos buscar las instancias de los eventos. En este caso buscaremos los eventos existentes en el calendario del usuario desde la hora actual hasta las 12 de la noche de ese día (Fig 29).

Fig 29 Especificamos un rango de tiempo para realizar la búsqueda.

Construimos la petición con el rango deseado (Fig 30).

Fig 30 Construcción de la petición.

59

Realizamos la petición y la asignamos a un cursor que nos servirá para movernos por los elementos de las tablas (Fig 31).

Fig 31 Asignamos la respuesta a un cursor.

Creamos un array para guardar los eventos, y otro para guardar si el evento tiene o no invitados. Esto lo hacemos porque desde la tabla de instancias es imposible acceder al correo electrónico de los invitados, por tanto primero averiguamos que eventos tienen invitados, y posteriormente realizamos una nueva consulta a la tabla attendees del proveedor de calendario para incluir esta información a cada evento (Fig 32).

Fig 32 Creamos un array de eventos y otro con los datos de la existencia de invitados en los eventos.

Ahora con un bucle recorreremos todos los elementos que nos ha devuelto la petición y extraeremos el identificador del evento, su nombre, la hora de comienzo en segundos, su localización, si el evento tiene invitados o no, y si el evento dura todo el día (en cuyo caso es un recordatorio y no un evento al que se deba asistir).

Una vez extraída esta información quitaremos los espacios que pueda haber en la localización del evento (ya que posteriormente necesitaremos que esta dirección no tenga espacios para poder realizar peticiones a las distintas APIs) y cambiaremos el formato de la hora de comienzo del evento.

Para finalizar si el evento no dura todo el día (y por tanto no se trata de un recordatorio sino de un evento al que se debe asistir) lo guardamos en el array de eventos y guardamos la información de si tiene invitados o no en el array eventsAttendees. Al completar el bucle While cerramos el cursor (Fig 33).

Fig 33 Bucle que extrae la información del calendario.

60

Ahora procedemos a asignar la ubicación inicial desde la cual se calculará el tiempo de viaje al evento. Esta ubicación será la actual del usuario para el primer evento y la del evento anterior para los demás. La localización actual la obtenemos con el método getLocalizacionActual() que realiza una consulta al GPS y devuelve un String con la latitud y longitud de la posición actual del usuario (Fig 34).

Fig 34 Añadir Ubicación inicial a los eventos.

Tras esto añadimos los correos electrónicos de los participantes de los eventos. Para ello realizamos un procedimiento similar al anterior, pero esta vez haciendo la consulta a la tabla Attendees, y solo a aquellos eventos que tengan invitados (información que tenemos almacenada en el array evensAttendee (Fig 35).

Fig 35 Añadir participantes a los eventos.

Finalmente procedemos a borrar la versión anterior de los datos existente en la base de datos local, y actualizarla con los datos de los eventos que hemos extraido del calendario del usuario. Figura 39.

Fig 36 Actualización de la base de datos local.

Cabe destacar que toda esta actividad comentada anteriormente ha sido programada con un JobService que se activará cada cierto periodo de tiempo para llevarla a cabo periódicamente.

61

4.3.3. Comprobar la hora y actuar en consecuencia

Esta operación se realiza en la clase “Tasks”, concretamente con el método checkAndNotify(). Este método recoge los eventos guardados en la base de datos local, calcula la hora de notificación (hora después de la cual se debe notificar al usuario para que salga hacia el evento y no llegue tarde) y la hora de email (hora después de la cual se debe mandar un correo electrónico para avisar a los participantes de un evento que el usuario llegará tarde) y actúa comparando estos parámetros con la hora actual.

En un primer lugar creamos una instancia de la base de datos y extraemos el primer evento (Fig 37).

Fig 37 Extracción del primer evento de la base de datos.

Ahora calcularemos la hora de notificación como la hora de salida menos una ventana de notificación (tiempo antes de la hora de salida al que se desea notificar), y la hora de email como la hora de salida más una ventana de email (tiempo posterior a la hora de salida a la que se desea notificar a los participantes del evento que el usuario llegará tarde). Nótese que la hora de salida depende de la localización actual del usuario, por tanto cambiará a medida que el usuario se acerque o aleje de la localización del evento, ajustando a su vez a estos parámetros calculados (Fig 38).

Fig 38 Calculo de fechaNotificar y FechaEmail.

Tras esto procederemos a tomar la decisión de cómo debe actuar nuestro sistema. Si la fecha actual es anterior a fechaNotificar no se realiza ninguna acción. Si la fecha actual es posterior a fechaNotificar, pero anterior a fechaEmail y el evento no ha sido notificado anteriormente, se procede a enviar una notificación al usuario para que salga hacia la localización del evento y no llegue tarde, y se marca el evento como notificado. Si la fecha actual es posterior a fechaEmail y no se ha enviado ningún email para ese evento se proceda a enviar un email a los invitados del evento y a marcar el evento como enviado. Nótese que una vez finalizado el evento, cuando se actualice la base de datos no lo recogerá, por tanto todas estas acciones se realizarán para el evento siguiente (Fig 39).

Fig 39 Reglas para definir la forma de actuar de la aplicación.

Cabe destacar que toda esta actividad comentada anteriormente ha sido programada con un JobService que se activará cada cierto periodo de tiempo para llevarla a cabo periódicamente.

62

Capítulo 5

5. Evaluación

5.1. Descripción experimental

En este apartado se propondrá un escenario ficticio en el que se pondrá a prueba la aplicación y se ilustrará su uso.

Imaginemos que queremos asistir a 2 eventos en los que se incluyen más participantes, uno situado en la Escuela Técnica Superior de Ingenierías Informática y de Telecomunicación de la Universidad de Granada a las 15:30, y el otro en el parque tecnológico de la salud a las 19:30. Para el primer evento salimos con tiempo y llegamos a tiempo, pero dirigiéndonos hacia el segundo nos encontramos con que hay más tráfico del esperado y en consecuencia llegamos tarde. Vemos como actuaria nuestra aplicación en tal escenario:

En un primer lugar añadiremos al calendario 2 eventos con las siguientes características:

Evento 1:

o Nombre: Evento 1.

o Hora del evento: 15:30.

o Ubicación: Escuela Técnica Superior de Ingenierías Informática y de Telecomunicación de la Universidad de Granada.

o Invitados: clemente.irigaray.97@gmail.com, clemente@correo.ugr.es.

Evento 2:

o Nombre: Evento 2.

o Hora del evento: 19:30.

o Ubicación: Parque Tecnológico de Ciencias de la Salud, Granada.

o Invitados: clemente.irigaray.97@gmail.com, clemente@correo.ugr.es.

Cabe destacar que como invitados se han usado 2 correos electrónicos propios para poder comprobar si la aplicación actúa correctamente mandando un correo electrónico en el momento indicado (Fig 40).

63

Fig 40 Añadir eventos al calendario.

A continuación nos dirigimos a nuestra aplicación “SmartSender”. Una vez abierta podremos observar una lista con los eventos que tenemos en el calendario para el día de hoy. Para cada evento se muestra el nombre, la hora del evento, la hora a la que debemos salir para llegar a tiempo y un pequeño mapa con la localización del evento (Fig 41).

Fig 41 Pantalla principal SmartSender.

Ahora comprobaremos que estos datos son correctos. Para ello hacemos click en los mapas que hay en cada uno de los evento para que nos lleve a la aplicación Google maps, desde la que podremos comprobar la ruta a seguir (Fig 42).

64

Fig 42 Pantallas resultantes al hacer click en los mapas.

Como hemos podido ver la aplicación toma como punto de partida para el primer evento la localización actual del usurio, y para los demás la localización del evento anterior.

Si hacemos click en el icono de invitados podremos acceder a una pantalla en la que se nos muestran los participantes del evento. Si queremos enviarle un mensaje a alguno de ellos, basta con marcarlo y pulsar sobre el botón “Enviar mensaje”. Esto nos llevará a nuestro cliente de correo electrónico para mandar escribir el mensaje deseado. Cabe destacar que esta funcionalidad es opcional, y se utilizaría en el caso de que se quisiera mandar un mensaje a algún participante de un evento con anterioridad (Fig 43).

Fig 43 Pantalla de invitados.

65

Para llegar a tiempo al primer evento debemos salir a las 15:18 como se muestra en la pantalla principal, sin embargo cuando falten 10 minutos para esta hora la aplicación nos mandará una notificación para que el usuario salga hacia el evento y no llegue tarde (Fig 44).

Fig 44 Notificación al usuario del Evento1.

En este caso nos dirigimos hacia el “Evento 1” y llegamos a tiempo, por tanto ningún correo en enviado. Tras la finalización del “Evento 1” desaparece de la pantalla principal quedando únicamente el “Evento 2” (Fig 45).

Fig 45 Pantalla principal una vez completado el Evento 1.

Como vemos en la Fig 45 para llegar a tiempo al siguiente evento debemos salir a las 19:18, por tanto 10 minutos antes de esta hora la aplicación nos manda una notificación (Fig 46).

66

Fig 46 Notificación Evento 2.

Esta vez no hacemos caso de la notificación y cuando cogemos el coche para ir al Evento 2 llevamos un gran retraso. Además estas horas hay un gran atasco para entrar a la autovía, por tanto es imposible que lleguemos a tiempo. Es entonces cuando la aplicación detecta basándose en nuestra localización actual y en el tiempo que se tarda en ir a la localización del Evento 2 que será imposible que lleguemos a tiempo, por lo que entra en acción mandando un email a los participantes de este evento sin que tengamos que desviar nuestra atención de la carretera (Fig 47).

Fig 47 Correo enviado por la Aplicación.

67

Como vemos hemos recibido un correo (en este caso pusimos como asistentes del evento nuestro propio correo y el correo clementeic@correo.ugr.es). El correo ha sido enviado a las 19:28. Esto es porque una vez pasadas las 19:18 y seguir prácticamente en la misma ubicación donde tenía lugar el evento 1, la aplicación ya se dio cuenta de que no llegaríamos a tiempo, pero dejó una ventana de 10 minutos para poder rectificar esta situación. Como 10 minutos después nuestra localización seguía siendo prácticamente igual, el sistema determinó que ya no era, de ninguna manera, posible llegar a tiempo, por lo que decidió mandar el correo electrónico.

68

5.2. Usabilidad del sistema

En este apartado se tratará de medir la usabilidad del sistema poniendo nuestra aplicación a prueba frente a usuarios reales.

Para medir usabilidad del sistema se ha utilizado un método llamado SUS (System Usability Scale). Este método fue inventado por John Brooke en 1986 como una forma rápida y sencilla de evaluar la usabilidad de un sistema. (usabilitygeek, 2015)

Los beneficios de utilizar este método frente a otros es que es rápido de administrar y no implica prácticamente ningún coste. SUS es uno de los métodos más eficientes para recopilar datos estadísticos válidos y dar a nuestro sistema una puntuación precisa.

Comparándolo con otros tipos de métodos de evaluación SUS es:

Más barato: ya que consiste en un pequeño cuestionario de 10 preguntas (Fig 48), por lo que necesita numerosos recursos en cuanto su administración. Por tanto es muy útil si se está limitado por el presupuesto, pero aun así se quiere tener acceso a buena información de forma rápida.

Más rápido: existe una plantilla fija para implementar este método, lo que lo hace rápido y sencillo de usar.

A pesar de ser mucho más barato y rápido que la mayoría de métodos este sistema es totalmente válido, y ha demostrado ser una fuente de información sólida y confiable.

Este método de evaluación consiste en un cuestionario con 10 afirmaciones que serán puntuadas en 5 niveles según el grado de conformidad del encuestado con cada afirmación.

Para calcular la puntuación que recibe nuestra aplicación, siendo 100 la máxima calificación posible, debemos:

Para cada afirmación impar restar 1 a la puntuación.

Para cada afirmación par restar a 5 su puntuación.

Sumar las puntuaciones obtenidas y multiplicarlas por 2.5

Este método no muestra un diagnóstico de los problemas concretos de nuestra aplicación, pero nos dará una estimación como de usable es.

La puntuación media de este método en el mercado es 68. Si nuestra puntuación se encontrase por debajo querría decir que nuestra aplicación tiene un problema de usabilidad. Si por el contrario se encontrase por encima de un 80.3 querría decir que la usabilidad de nuestra aplicación es fantástica.

69

Nº Pregunta Totalmente desacuerdo

Desacuerdo Intermedio De

acuerdo Totalmente de acuerdo

1 Pienso que usaría el sistema a menudo.

2 Encuentro el sistema

innecesariamente complejo.

3 Encuentro el sistema

fácil de usar.

4 Pienso que necesitaría la ayuda de un experto

para usar el sistema.

5 Pienso que las

funciones del sistema están bien integradas.

6

Pienso que había demasiada

inconsistencia en el sistema.

7

Pienso que la mayoría de la gente aprendería a usar rápidamente el

sistema.

8 El sistema me pareció incomodo de usar

9 Me sentí con

seguridad a la hora de usar el sistema.

10 Tendría que aprender

muchas cosas antes de poder usar el sistema.

Fig 48 Cuestionario realizado según el método SUS.

70

Para poner en práctica la evaluación de la usabilidad con el método SUS se le ha dado a probar la aplicación a un numero de 5 usuarios cuyo rango de edad se ha tratado que sea amplio y variado para obtener una muestra lo más representativa posible. Después se le entregó a cada uno de ellos un cuestionario como el representado en la Fig 48. Tras esto se obtuvieron los resultados representados en la Fig 49.

Fig 49 Puntuación de las preguntas por cada uno de los encuestados.

Si se hace la media para cada pregunta se obtienen los resultados reflejados en la tabla 2.

P1 P2 P3 P4 P5 P6 P7 P8 P9 P10

1.6 1 4.4 1.2 3 3.8 4.6 2.6 0.8 4

Tabla 2 Media de los resultados de cada pregunta.

Tras realizar las operaciones propias del método SUS anteriormente descritas, nuestra aplicación obtiene una puntuación de 64.5 puntos lo que está ligeramente por debajo del umbral de accesibilidad medio del mercado.

0

1

2

3

4

5

6

1 2 3 4 5 6 7 8 9 10

Encuestado1

Encuestado2

Encuestado3

Encuestado4

Encuestado5

(nº Pregunta)

71

5.3. Interpretación de los resultados

En el apartado anterior se evaluó la usabilidad de la aplicación a través del método SUS obteniendo una puntuación de 64.5 puntos sobre 100. Esta puntuación se encuentra por debajo de la puntuación media esperada en el mercado, lo que denota que se debe continuar trabajando y desarrollando la aplicación para conseguir un grado de usabilidad satisfactorio y poder sacarla con éxito al mercado. Como aspectos positivos se ha podido observar que los usuarios encuentran la aplicación fácil de usar, comprensible y no innecesariamente compleja. Uno de los objetivos de este proyecto es minimizar la intervención de usuario, por lo que es esencial que los encuestados encuentren la aplicación sencilla, intuitiva y fácil de usar. Esto nos indica que se ha que se ha seguido una línea de diseño correcta y se debe avanzar en esa dirección. Sin embargo se encuentran varias inconsistencias en el sistema sobre todo debido al retardo introducido al realizar consultas a la API “Directions”, que como se dice en su documentación, no está diseñada para responder en tiempo real. A demás los usuarios encontraron el uso del correo electrónico poco eficaz, prefiriendo el uso de mensajería instantánea como por ejemplo “Whatsapp”. A pesar de todo y al tratarse de un primer prototipo experimental pueden considerarse estos resultados bastante positivos, ya que en una primera aproximación se ha conseguido acercarse bastante a un umbral correcto de usabilidad, lo cual hace ver que si se dispusiera de tiempo para seguir desarrollando el proyecto se podría conseguir una solución real y usable para minimizar los accidentes de tráfico.

5.4. Limitaciones

- El uso del correo electrónico como medio de notificación a los participantes del evento en lugar de aplicaciones de mensajería instantánea.

- Retardos introducidos a la hora de realizar consultas a la API “Directions” debido a que esta, como se indica en su documentación, no está diseñada para operar en tiempo real.

- Falta de precisión para determinar si el usuario se encuentra en una situación lo suficientemente crítica como para actuar por él.

- Carencia de personalización y configuración.

- Incompatibilidad con dispositivos IOS.

72

Capítulo 6

6. Conclusiones y vías futuras

6.1. Grado de consecución de los objetivos iniciales

En este proyecto se ha desarrollado un sistema proactivo de notificación automática de indisponibilidad durante la conducción basado en información de contexto, pretendiendo de esta forma disminuir el número de distracciones que tienen lugar mientras un usuario conduce.

Para ello se ha realizado un estudio sobre los trabajos relacionados y tecnología existente, y se llegó a la conclusión de que aunque existen numerosas aplicaciones relacionadas con el ámbito vial, la mayoría de ellas se centran en evitar atascos o en facilitar la actuación de los servicios de emergencia una vez se ha producido un accidente. Sin embargo, muy pocas de ellas tratan de dar una solución real para disminuir los accidentes de tráfico, y las que lo hacen se limitan a silenciar el dispositivo móvil durante la conducción en lugar de realizar tareas que descarguen de responsabilidades al usuario para que pueda centrarse en la conducción.

Tras esto se ha realizado el diseño de una arquitectura para este sistema basada en 6 módulos diferenciados que se relacionan entre sí para extraer la información contextual del usuario de distintos servidores y almacenarla en una base local. Tras esto se evalúa periódicamente la información almacenada (completándola cuando es necesario) detectando los casos en los que se ha de notificar al usuario para que no llegue tarde a un evento o los casos en los que el usuario llaga tarde a un evento pero no puede notificárselo a sus participantes por el hecho de estar conduciendo, actuando en consecuencia de forma autónoma o bien notificando al usuario para que salga y no llegue tarde o bien (y esta es la funcionalidad principal) avisando a los participantes del evento del retraso del usuario sin que este tenga que detenerse a coger el teléfono móvil mientras conduce.

Este sistema se ha Implementado a través de una aplicación móvil para dispositivos Android. Esta aplicación es capaz de acceder tanto al calendario del usuario como a las distintas APIs de Google para recibir la información necesaria, y tras esto notificar al usuario a qué hora debe salir para llegar a tiempo a un evento, y en caso de que este llegue tarde, notificar a los invitados del evento al que se dirige vía email.

Finalmente se ha realizado una evaluación de la implementación realizada en un entorno simulado y sometiéndola al método SUS (Sistem Usability Scale) a través de formularios en los que la aplicación ha recibido una puntuación de 64.5 puntos sobre 100. Esta puntuación se encuentra por debajo de la puntuación media esperada en el mercado, lo que denota que se debe continuar trabajando y desarrollando la aplicación para conseguir un grado de usabilidad satisfactorio, sin embargo al tratarse de una primera aproximación, se ha considerado este resultado como positivo, ya que se ha acercado bastante a un nivel de usabilidad correcto, teniendo que mejorar algunos aspectos (como el retardo), cambiar otros (como la notificación a los participantes a través de mensajería instantánea en lugar de email), pero manteniendo las líneas de diseño generales. En el apartado 6.2 se hablará de las contribuciones de este proyecto y en el 6.3 se comentarán posibles vías para seguir desarrollándolo.

73

6.2. Contribuciones del trabajo

Como se ha visto anteriormente millones de personas pierden la vida a causa de accidentes de tráfico y aunque las distracciones al volante relacionadas con teléfono móvil representan casi un 30% de las causas de estos accidentes, sigue siendo un problema sobre el cual aún no existe una solución suficientemente válida. La mayoría de aplicaciones se limitan a alertar de estos accidentes o a facilitar la tarea de los servicios de emergencia, sin embargo son muy pocas las que tratan de aportar una solución real para disminuir estas distracciones y la única que se ha encontrado se limita a silenciar el teléfono durante la conducción. En este proyecto se ha tratado de ir un paso más allá proponiendo un enfoque en el que la tecnología sea consciente de las necesidades del usuario y consiga actuar por él. De esta forma se pretende que la única preocupación del conductor sea la carretera, abstrayéndolo totalmente de toda preocupación externa que no sea conducir. Aunque se trate de una primera aproximación, este proyecto sienta las bases para el desarrollo de un sistema el cual sea capaz de extraer información contextual necesaria para conocer las necesidades del usuario y en función de ellas actuar. En este nuevo enfoque dejamos de ver la tecnología como un elemento dañino y distractor que debe ser eliminado o silenciado durante la conducción, para pasar a verla como un elemento activo capaz de liberar al usuario de cargas, tareas y preocupaciones que pueden ser automatizadas. Por tanto podríamos decir que la mayor aportación de este trabajo es la introducción del concepto de un sistema proactivo en el ámbito de la conducción.

74

6.3. Vías futuras

La principal limitación a la hora de realizar este trabajo ha sido el tiempo en el que se ha tenido que desarrollar el sistema. Ha de tenerse en cuenta que se trata de una temática complementaria con la formación de un ingeniero de Telecomunicaciones, por lo que se ha tenido que dedicar mucho tiempo a adquirir los conocimientos y competencias necesarias que demanda este proyecto.

Es por ello que si se dispusiera de más tiempo se deberían corregir las limitaciones encontradas en el sistema, optimizando los retardos, cambiando el uso del correo electrónico como medio de notificación a los participantes de un evento por aplicaciones de mensajería instantánea más usadas (como “Whatsapp”), incluyendo personalización y configuración de varios parámetros (como el tiempo antes de la hora de salida a la que se debe notificar), mejorando la compatibilidad de la aplicación con distintos sistemas operativos, o incluyendo un sistema de reconocimiento para que el sistema solo se active únicamente cuando el usuario se encuentra conduciendo. Esto se podría realizar a través de comprobaciones bluethooth con el equipo del automóvil o analizando los patrones de movimiento del usuario a través de localización para detectar que se encuentra conduciendo.

A medida que se realicen avances, se debe ir sometiendo la aplicación a evaluación (utilizando el método SUS como se ha realizado en este trabajo por ejemplo) para determinar si se está avanzando en la dirección correcta. Tras conseguir una usabilidad correcta se podría lanzar esta app al mercado publicándola en Google Play.

Una posible vía de trabajo sería la de combinar las funcionalidades descritas por la aplicación “Mutting” (mutting, 2018) con las descritas en este proyecto, consiguiendo así evitar tanto las distracciones provocadas por otros usuarios mientras se está conduciendo, como actuar por el usuario descargándolo de preocupaciones cuando se encuentra al volante.

Otro tema de interés es el estudio de las ventanas de notificación (tiempo antes de la hora de salida a la que se debe notificar al usuario, o momento en el que se debe notificar a los participantes del evento), ya que dependiendo del tiempo que dure el trayecto será más óptimo notificar en un momento u otro.

75

7. Referencias bibliográficas

Tutorial de Java. (2005). Recuperado el 2019, de http://dis.um.es/~bmoros/Tutorial/parte2/cap2-5.html

DGTinfo. (2014). Recuperado el 2019, de https://www.dgtinfo.es/app-dgt-android-e-iphone-ios/

usabilitygeek. (2015). Recuperado el 2019, de https://usabilitygeek.com/how-to-use-the-system-usability-scale-sus-to-evaluate-the-usability-of-your-website/

android developers. (2016). Recuperado el 22 de 10 de 2016, de https://developer.android.com/guide/components/services?hl=es-419

App Store. (2016). Recuperado el 2019, de https://apps.apple.com/es/app/irescue/id483566831

envatotuts+. (2016). Recuperado el 10 de 21 de 2019, de https://code.tutsplus.com/es/tutorials/android-from-scratch-understanding-adapters-and-adapter-views--cms-26646

slashgear.com. (2016). Recuperado el 2019, de https://www.slashgear.com/google-awareness-api-now-ready-for-context-aware-android-apps-28446139/

Google Developer. (2017). Recuperado el 20 de 10 de 2019, de https://developers.google.com/maps/documentation/maps-static/intro

Google Developers. (2017). Recuperado el 20 de 10 de 2019, de https://developers.google.com/maps/documentation/directions/intro

Introducción a Android Studio. (2017). Recuperado el 2019, de https://developer.android.com/studio/intro?hl=es-419

mutting. (2018). Recuperado el 2019, de https://mutting.com/

DGT. (2019). Recuperado el 2019, de http://www.dgt.es/es/seguridad-vial/

Google Play. (2019). Recuperado el 2019, de https://play.google.com/store/apps/details?id=com.telefonica.my112&hl=es

Rytewiki. (2019). Recuperado el 19 de 10 de 2019, de https://es.ryte.com/wiki/API

SOSmart. (2019). Recuperado el 2019, de http://www.sosmartapp.com/inicio.html

Waze. (2019). Recuperado el 2019, de https://www.waze.com/es/

Android Developers. (2017). developer.android.com. Recuperado el 2019, de https://developer.android.com

CEA. (2018). cea-online.es. Recuperado el 2019 de 10 de 15, de https://www.cea-online.es/blog/460-distracciones-al-volante-principal-causa-de-accidentes-mortales

Dhara, K. K., Krishnaswamy, V., & Anajwala, S. (2014). System and method for smart contextual calendaring based meeting scheduling. US 2014/0372162 A1.

Dobrican, R. A., Neyens, G. I., & Zampunieris, D. (2016). A Context-Aware Collaborative Mobile Application for Silencing the Smartphone. International Journal On Advances in Intelligent Systems, 171-180.

76

Doss, J. S., Pozefsky, R., & Sundstrom, R. J. (2009). Context conflict resolution and automatic context source maintenance. US 7487,234 B2.

Fernandéz, A. (15 de 10 de 2019). Nueve de cada diez distracciones al volante están relacionadas con el uso del teléfono móvil. El Pais.

Fundación Mapfre. (2018). fundacionmapfre.org. Recuperado el 15 de 10 de 2019, de https://www.fundacionmapfre.org/fundacion/es_es/programas/seguridad-vial/temas-clave/distracciones/

Hazen, T. J., Bishop, D., Duta, N., Longo, P., & Babaeizabeh, M. (2016). Creating a calendar event using context. US 9,372,851 B2.

Kogan, S. L., Galvin, J. P., Solie, K., Ronald E. Pontrich, J., Travis, A. D., & Mewherter, D. L. (2014). System and method of managing real-time communications using context-based awareness states. US 8,639,755 B2.

Mozilla Developers. (25 de 7 de 2019). developer.mozilla.org. Recuperado el 2019, de https://developer.mozilla.org/es/docs/Web/XML/Introducci%C3%B3n_a_XML#targetText=XML%20es%20un%20lenguaje%20de,de%20marcado%20de%20prop%C3%B3sito%20general.

Mynatt, E., & Tullio, J. (2001). Inferring Calendar Event Attendance. Proceedings of the 6th international conference on Intelligent user interfaces. Atlanta.

O’Neill, E., Lovett, T., Irwin, J., & Pollington, D. (2010). The Calendar as a Sensor: Analysis and Improvement. Conference: UbiComp 2010: Ubiquitous Computing, 12th International Conference, UbiComp 2010, Copenhagen, Denmark, September 26-29, 2010, Proceedings.

Oracle. (20015). Java.com. Recuperado el 2019, de https://www.java.com/es/

Realm. (2017). realm.io. Recuperado el 18 de 10 de 2019, de https://realm.io

Salovaara, A., & Oulasvirta, A. (2004). Six modes of proactive resource management: A user-centric typology for proactive behaviors. Nordic conference on human-computer interaction, 57-60.

Sondea. (2019). Nueve de cada diez distracciones al volante están relacionadas con el uso del teléfono móvil.

Stern, H., Pammer, V., & Lindstaedt, S. N. (2011). A Preliminary Study on Interruptibility Detection Based on Location and Calendar Information. Workshop on Context-Systems Design, Evaluation and Optimisation . Copenhagen, Denmark.

Tennenhouse, D. (2000). Proactive Computing. Communications of the ACM, 43-50.

Top Digital Agency. (2018). topdigital.agency. Recuperado el 18 de 10 de 2019, de https://topdigital.agency/realm-vs-sqlite-the-battle-of-databases/

Whatls. ( 06/09/2019). whatis.techtarget.com. Obtenido de https://whatis.techtarget.com/definition/context-awareness

Zampunieris, D. (2006). Implementation of a Proactive Learning Management System. Proceedings of "ELearn - World Conference on E-Learning in Corporate, Government, Healthcare & Higher Education", 3145–3151.

77