Seguimiento geográfico diario automatizado del usuario

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA INGENIERÍA DEL SOFTWARE FEET3 SEGUIMIENTO GEOGRÁFICO DIARIO AUTOMATIZADO DEL USUARIO AUTOMATIC USER DAILY GEOGRAPHIC TRACKING Realizado por David Bandera García Tutorizado por Enrique Alba Torres Francisco Javier Ferrer Urbano Departamento LENGUAJE Y CIENCIAS DE LA COMPUTACIÓN UNIVERSIDAD DE MÁLAGA MÁLAGA, Noviembre de 2016 Fecha defensa: El Secretario del Tribunal Resumen: El análisis de nuestra actividad diaria puede ser una fuente de información muy valiosa para conocer características de nuestros hábitos cotidianos que pueden pasar desapercibidas. En el presente Trabajo Fin de Grado se pretende detectar de forma automática la rutina diaria del usuario mediante el registro de las localizaciones en las que se detiene. Mediante el uso de un dispositivo móvil Android podemos detectar estas paradas utilizando los sensores disponibles en la mayoría de los dispositivos móviles inteligentes (smartphones). Estas paradas se almacenarán de forma totalmente automática y de manera local en el dispositivo móvil del usuario, pudiendo ser consultadas en cualquier momento. Adicionalmente, el usuario puede solicitar registrar una parada en su posición de forma manual si lo desea. También se podrá obtener información sobre la fecha y hora de las paradas, además de disponer de información sobre las redes inalámbricas detectadas en cada parada, tanto fijas (routers) como otros dispositivos móviles cercanos. También se podrán consultar las paradas de forma gráfica en un mapa de la zona mediante el uso de la API GoogleMaps. La aplicación, además, se puede configurar para adaptarla a distintos usos, gracias a los parámetros de distancia mínima a la que se considera una parada como nueva y tiempo mínimo de detección para que se determine si se ha producido una parada. El objetivo final es hacer consciente al usuario de su propio comportamiento, para permitir mejoras en su vida. Palabras claves: automatización, aplicación móvil, rutina, detección, GPS Abstract: The analysis of our daily routine can be a source of very valuable information to learn about the characteristics of our daily habits that are not so obvious. This degree thesis aims to automatize the detection of the daily routine of the user by registering the locations where he/she stops. With an Android mobile device we can detect these stops by employing the sensors most smartphones have nowadays. These stops will be automatically and locally stored in the device and able to be consulted at any time. Additionally, the user will be able to register a stop at their current position manually, should they desire it. The user will be able to obtain information about the date and time of every stop, and consult information about the detected wireless networks at each stop, be it a fixed network (routers) or another nearby mobile device. Stops will also be shown graphically on a map through the use of GoogleMaps API. The application can be adjusted to different uses thanks to two parameters, the minimum distance to consider a stop as a new one and minimum detection time to determine if a stop has been made. The final goal is to make the user aware of his/her own routines, so as to improve his/her own live. Keywords: automatization, mobile application, routine, detection, GPS Índice Capítulo 1. Introducción .............................................................................................. 1 1.1. Motivación ........................................................................................................ 1 1.2. Objetivos .......................................................................................................... 1 1.3. Estructura de la memoria ................................................................................. 2 Capítulo 2. Tecnologías .............................................................................................. 3 2.1. Repositorio de código fuente ............................................................................ 3 2.2. Aplicación móvil ................................................................................................ 3 2.2.1. Plataforma móvil ........................................................................................ 3 2.2.2. Base de datos............................................................................................ 3 2.2.3. Bibliotecas externas .................................................................................. 4 2.3. Entorno de desarrollo ....................................................................................... 4 Capítulo 3. Especificación y análisis ........................................................................... 5 3.1. Requisitos funcionales de la aplicación Android............................................... 5 3.2. Requisitos no funcionales de la aplicación Android .......................................... 6 3.3. Casos de uso ................................................................................................... 7 3.4. Base de datos ................................................................................................ 12 Capítulo 4. Diseño .................................................................................................... 13 4.1. Modelo relacional de la base de datos ........................................................... 13 4.2. Diagrama de clases ........................................................................................ 14 Capítulo 5. Implementación y pruebas ..................................................................... 17 5.1. Estructura de la aplicación Android ................................................................ 17 5.2. Desarrollo del proyecto .................................................................................. 19 5.2.1. Inicio ........................................................................................................ 19 5.2.2. Solicitar almacenamiento de parada ....................................................... 20 5.2.3. Consultar información de parada............................................................. 22 5.2.4. Edición de nombre ................................................................................... 24 5.2.5. Visualización gráfica mediante mapa ...................................................... 25 5.2.6. Automatización ........................................................................................ 27 5.2.7. Preferencias ............................................................................................ 31 5.3. Pruebas .......................................................................................................... 33 Capítulo 6. Conclusiones y líneas futuras ................................................................ 37 6.1. Conclusiones .................................................................................................. 37 6.2. Líneas futuras ................................................................................................. 38 Referencias .............................................................................................................. 39 Apéndices ................................................................................................................. 41 A. Manual de usuario ............................................................................................ 41 Índice de figuras ....................................................................................................... 44 Índice de tablas ........................................................................................................ 45 1 Capítulo 1. Introducción 1.1. Motivación El número de usuarios de smartphones es cada vez más elevado (1). Sin embargo, gran parte de estas personas no aprovechan todo el potencial de dichos dispositivos, ya sea por desconocimiento o por la falta de necesidad. Dichos dispositivos son una gran fuente de información a la que se le puede sacar mucho partido. En las ciudades inteligentes la automatización y el análisis de datos cobran una gran importancia puesto que ayuda a la optimización de los recursos y el aumento de la productividad (2). Las aplicaciones capaces de realizar un seguimiento de las actividades diarias del usuario son muchas, pero la mayoría necesitan datos introducidos por el mismo o hardware adicional, como en el caso de las pulseras de fitness. En este Trabajo Fin de Grado (TFG) se pretende acabar con estas limitaciones aprovechando todo el potencial de los dispositivos móviles inteligentes, utilizando tanto la tecnología GPS como los sensores de movimiento y la interfaz WiFi. Vamos a crear una aplicación automática y fácil de usar para el seguimiento de la rutina diaria, permitiendo al usuario mantener un control de su horario y ayudándole a recordar las visitas realizadas con anterioridad. 1.2. Objetivos El objetivo del presente TFG es el desarrollo de una aplicación móvil Android capaz de detectar la posición geográfica del usuario y determinar cuándo éste se ha detenido en algún sitio durante un tiempo significativo, para posteriormente registrar dicha parada junto con la fecha y hora en la que se realizó. Adicionalmente, se realizará un escaneo de redes inalámbricas existentes en dicho lugar, las cuales se clasificarán como redes de punto fijo (routers) o dispositivos móviles (otros smartphones). Posteriormente se podrán consultar en forma de lista o de forma gráfica mediante un mapa de la zona. Todo el proceso se realizará de forma automática mediante el uso de los sensores del dispositivo móvil y GPS. Además, el usuario podrá solicitar manualmente el registro de una parada en su ubicación actual. 8 En el Caso de uso 1 el usuario registra una parada de forma manual. Detectar parada manualmente Identificador UC-1. Requisitos asociados RF-01, RF-03, RF-04. Actores Usuario. Descripción El usuario solicita registrar una parada inmediatamente en su posición actual. Precondiciones La aplicación debe encontrarse en la pantalla principal. Postcondiciones La parada se almacena correctamente en la base de datos. Escenario principal 1El usuario pulsa el botón Guardar localización. 2La aplicación detecta la posición geográfica actual. 3La aplicación detecta las redes cercanas al dispositivo. 4La parada generada se almacena en la base de datos del dispositivo. Escenario alternativo La geolocalización (GPS) está desconectada o no se encuentra disponible: 2aLa aplicación muestra un mensaje informando de que no se pudo obtener la localización. Tabla 3: Caso de uso 1 En los Casos de uso 2 y 3 el usuario consulta la información recopilada sobre las paradas realizadas. Consultar historial de paradas Identificador UC-2. Requisitos asociados RF-06. Actores Usuario. Descripción El usuario consulta el historial de paradas guardado en el dispositivo. Precondiciones Debe existir al menos una parada guardada en la base de datos. La aplicación debe encontrarse en la vista principal. Postcondiciones Ninguna. Escenario principal 1La aplicación muestra una lista con el historial de paradas. Escenario alternativo Ninguno. Tabla 4 - Caso de uso 2 9 Consultar información adicional de parada Identificador UC-3. Requisitos asociados RF-06, RF-07. Actores Usuario. Descripción El usuario consulta información adicional sobre las paradas, y consulta el mapa de paradas. Precondiciones Debe existir al menos una parada almacenada en la base de datos. La aplicación debe encontrarse en la vista principal. Postcondiciones Ninguna. Escenario principal 1El usuario selecciona una parada de la lista de paradas de la vista principal. 2Se muestra la vista información adicional de la parada. 3El usuario pulsa el botón Mapa en la vista de información adicional de la parada. 4La aplicación abre la vista de mapa en la que se muestran las paradas realizadas. Escenario alternativo Ninguno. Tabla 5 - Caso de uso 3 Los Casos de uso 4 y 5 de uso permiten editar información de las paradas. Editar nombre de parada Identificador UC-4. Requisitos asociados RF-09. Actores Usuario. Descripción El usuario edita el nombre de una parada. Precondiciones Debe existir al menos una parada almacenada en la base de datos. Postcondiciones El nombre se actualiza correctamente en la base de datos. Escenario principal 1 - El usuario selecciona una parada de la lista de paradas de la vista principal. 2 - Se muestra la vista información adicional de la parada. 3 - El usuario pulsa sobre el nombre de la parada. 4 – Se muestra la vista editar nombre de parada. 5 - El usuario edita nombre y pulsa el botón Guardar. 6 - El nombre se actualiza y guarda en la base de datos. Escenario alternativo El usuario introduce un nombre no válido: 5a - El usuario deja el nombre vacío y pulsa el botón guardar. 6a - No se realiza ningún cambio en la base de datos. Tabla 6 - Caso de uso 4 10 Editar nombre de red Identificador UC-5. Requisitos asociados RF-10. Actores Usuario. Descripción El usuario edita el nombre de una red (dispositivo fijo o móvil). Precondiciones Debe existir al menos una parada almacenada en la base de datos. Debe existir al menos una red asociada a una parada almacenada en la base de datos. Postcondiciones El nombre se actualiza correctamente en la base de datos. Escenario principal 1 - El usuario selecciona una parada de la lista de paradas de la vista principal. 2 – La aplicación muestra la vista información adicional de la parada. 3 - El usuario pulsa sobre el nombre de una de las redes disponibles en la lista de redes. 4 - La aplicación muestra la vista de editar nombre de red. 5 - El usuario escribe el nuevo nombre y pulsa el botón Guardar. 6 - El nombre es actualizado y guardado en la base de datos. Escenario alternativo El usuario introduce un nombre no válido 5aEl usuario deja el campo de nombre vacío y pulsa el botón guardar. 6a - El nombre no se almacena y se mantiene la vista de editar nombre. El usuario retrocede sin pulsar el botón Guardar 6b - Se mantiene el nombre anterior sin realizar modificaciones a la base de datos. Tabla 7 - Caso de uso 5 El siguiente Caso de uso 8 describe el ajuste de los parámetros de la aplicación por el usuario. La aplicación consta de dos parámetros, pero se ha decidido englobar los dos parámetros en un solo caso de uso, puesto que el escenario es exactamente el mismo desde el punto de vista del actor principal, el usuario. 11 Ajustar parámetros Identificador UC-6. Requisitos asociados RF-11. Actores Usuario. Descripción El usuario ajusta los parámetros de configuración de la aplicación. Precondiciones Ninguna. Postcondiciones Los parámetros se actualizan correctamente. Escenario principal 1 - El usuario pulsa el botón de preferencias de la vista principal. 2 - La aplicación muestra la vista de preferencias. 3 - El usuario pulsa en una preferencia para modificar. 4 - La aplicación muestra los valores posibles de dicha preferencia. 5 - El usuario elige el valor deseado. 6 - La aplicación actualiza correctamente el valor. Escenario alternativo Ninguno. Tabla 8 - Caso de uso 6 En el Caso de uso 9 se describe el proceso de borrado del historial. Borrar historial Identificador UC-7. Requisitos asociados RF-05. Actores Usuario. Descripción El usuario borra el historial de paradas almacenado en la base de datos. Precondiciones Ninguna. Postcondiciones Los datos son borrados correctamente de la base de datos. Escenario principal 1 - El usuario pulsa el botón Borrar historial. 2 - La aplicación muestra la vista de confirmación de borrado. 3 - El usuario selecciona la opción Aceptar. 4 - La aplicación borra los datos guardados en la base de datos. Escenario alternativo El usuario decide no borrar los datos 3a - El usuario selecciona la opción Cancelar 4a - La aplicación cierra la vista de confirmación de borrado sin alterar la base de datos. Tabla 9 - Caso de uso 7 12 El último Caso de uso 10 describe cómo se detecta una parada de forma automática mediante el uso de los sensores del dispositivo móvil. Detectar parada automáticamente Identificador UC-8. Nombre Detectar parada automáticamente. Requisitos asociados RF-02. Actores Dispositivo móvil. Descripción La aplicación detecta automáticamente una parada. Precondiciones La aplicación se encuentra activa o en segundo plano. Postcondiciones La parada se almacena correctamente en la base de datos. Escenario principal 1 - Los sensores del dispositivo móvil detectan que el usuario se ha detenido. 2 - La aplicación recibe la señal de que el usuario se encuentra detenido. 3 - Tras cumplirse los parámetros establecidos, la aplicación registra una parada. Escenario alternativo Ninguno. Tabla 10 - Caso de uso 8 3.4. Base de datos En este apartado se dará una breve explicación sobre la estructura de la base de datos que hemos decidido emplear en nuestra aplicación, ofreciéndose en el siguiente capítulo una explicación en mayor profundidad. Para cumplir con los requisitos de la aplicación hemos optado por utilizar 4 entidades que van a almacenar la información que necesitará nuestra aplicación Feet3:  Position: Representa un lugar físico, es la entidad utilizada para guardar información sobre la localización geográfica del usuario.  Devices: Representa dispositivos inalámbricos, distinguiendo entre dispositivos de punto fijo o dispositivos móviles.  Finding: Es la entidad más importante, relaciona las posiciones geográficas con los dispositivos encontrados en ellas, además de almacenar información de la parada realizada tal como la fecha y la hora.  Finding_has_Devices: Se trata de una entidad que representa la relación entre varias paradas y varios dispositivos, ya que en el caso de un dispositivo móvil, este puede ser encontrado en diferentes posiciones. 13 Capítulo 4. Diseño 4.1. Modelo relacional de la base de datos Para almacenar los datos de forma persistente, se ha empleado una base de datos basada en SQLite. En nuestra aplicación esta información se guarda de forma local en el dispositivo donde se encuentre instalada la aplicación. En la Figura 2 podemos observar el modelo relacional de la base de datos: Figura 2 - Modelo relacional de la base de datos Las entidades mostradas en la Figura 2 son detalladas a continuación:  Position: Representa una posición geográfica. Sirve para registrar los lugares físicos en los que se detecta una parada. o Los valores Latitude y Longitude consisten en las coordenadas geográficas del lugar, y son usados como clave primaria para esta tabla, por lo que son valores obligatorios. Son registrados como valores reales. o Name: Es el nombre asignado a dicha posición, introducido por el usuario si lo desea. Es un campo opcional, por lo que puede encontrarse vacío. o Address: Consiste en la dirección que la API GoogleMaps devuelve para dicha localización. Se trata de una cadena de caracteres, y también es totalmente opcional. 14  Devices: Representa un dispositivo de red inalámbrico, tanto fijo como móvil. o MAC address: Contiene la dirección MAC del dispositivo detectado, y es usado como clave primaria para la tabla. Su tipo es de cadena de caracteres y es de carácter obligatorio. o Name: De nuevo, es el nombre asignado al dispositivo. Por defecto se asigna el SSID del dispositivo detectado, pero puede ser alterado por el usuario. Igualmente se trata de una cadena de caracteres opcional. o Type: Sirve para determinar si un dispositivo es fijo o móvil. Es un valor booleano obligatorio.  Finding: Representa una parada, asociando una posición geográfica con los dispositivos que han sido encontrados en dicha posición. o Los valores Position_Latitude y Position_Longitude son claves foráneas a la tabla Position para referenciar la posición detectada. Son guardados en forma de valores enteros obligatorios. o Date: Almacena la fecha y hora en la que se detectó la parada mediante un datetime, y es el identificador principal de esta tabla, por lo que es un valor obligatorio. Cabe mencionar que esta tabla se relaciona con los dispositivos mediante la tabla Finding_has_Devices.  Finding_has_Devices: Esta entidad representa la relación de muchos a muchos entre una parada y los dispositivos que se hayan detectado. Todos sus parámetros son claves foráneas a las respectivas tablas. 4.2. Diagrama de clases En esta sección se muestra el diagrama de clases UML de la aplicación Android desarrollada en la Figura 3. Se han incluido únicamente las clases más relevantes del sistema, obviando clases para implementación de interfaces de usuario en Android. 15 Figura 3 - Diagrama de clases La aplicación ha sido dividida en tres grupos, un paquete general llamado Feet3 en el cual se encuentran las clases de lógica de aplicación y los otros dos paquetes. Las clases que implementan funcionalidades y utilidades están situadas en el paquete Utils, remarcado en color rojo, y las clases de gestión de la base de datos en el paquete Data, remarcado en color verde. Las clases más destacables del diagrama son las siguientes:  MainActivity: Gestiona la mayor parte de la aplicación, empleando funcionalidad necesaria de las clases del paquete Utils y gestionando la detección e inclusión de las paradas en la base de datos mediante las clases representantes de las entidades y la clase gestora de datos Feet3DataSource.  Feet3DataSource: Contiene todos los scripts de creación de la base de datos, las sentencias sql necesarias para realizar peticiones a la base de datos y la lógica para gestionarlas.  Feet3WifiManager: Gestiona la detección de redes WiFi cercanas y obtiene información sobre ellas, pudiendo devolver una lista con la información.  Feet3ActivityRecognizeManager: Es la clase encargada de la detección automática de paradas mediante el uso de los sensores del dispositivo móvil. 16  Feet3LocationManager: Clase responsable de gestionar la posición geográfica del dispositivo, mediante el uso de GPS o redes móviles. Con esta estructura de la aplicación se ha conseguido implementar la totalidad de los requisitos funcionales mencionados anteriormente. 17 Capítulo 5. Implementación y pruebas En este capítulo se detalla la estructura de la aplicación Android junto con los detalles de la implementación más críticos e importantes. Finaliza con una recopilación de las pruebas llevadas a cabo. 5.1. Estructura de la aplicación Android La siguiente imagen muestra la estructura de la aplicación Android del proyecto. El paquete principal, llamado main.feet3, contiene las clases principales de la aplicación además de los paquetes de las clases encargadas de la gestión de datos y de ofrecer utilidades y funciones. Figura 4 - Estructura de la aplicación Android Procederemos a dar una explicación detallada sobre la funcionalidad de las clases esenciales para el funcionamiento de la aplicación. 24 Figura 8 - Información adicional remarcada La parada seleccionada es remarcada mediante un fondo oscuro para que el usuario pueda saber fácilmente cuál se encuentra seleccionada. 5.2.4. Edición de nombre El usuario puede editar el nombre de posiciones y redes que se hayan detectado. Para ello, sólo tiene que pulsar sobre el nombre de la parada en la pantalla de información adicional de parada mostrada anteriormente, o en el elemento de la lista de Redes detectadas deseado. Esta acción abrirá un Dialog en el que se muestra el valor actual, y un cuadro de texto editable en el que el usuario puede escribir el nombre que desee. Dicho Dialog se puede apreciar en la Figura 9. Cuando el usuario finalice, solo tiene que pulsar el botón Guardar. En caso de que el usuario retroceda sin pulsar el botón o introduzca un nombre vacío, no se realizará ningún cambio. 25 Figura 9 - Edición de nombre 5.2.5. Visualización gráfica mediante mapa Como se ha podido observar en las imágenes anteriores, en la misma vista de información adicional existe un botón llamado Mapa. Al pulsar este botón, se abre la vista de mapa en la que se muestran las paradas de forma gráfica, la cual es mostrada en la Figura 10. 26 Figura 10 - Visualización mediante mapa Las paradas son representadas mediante marcadores posicionados en el mapa en los lugares donde se detectaron. Al seleccionar un marcador aparece información sobre la fecha y la hora en la que se realizó esa parada y el nombre de la posición, en caso de que el usuario haya decidido editar el nombre por defecto. El usuario puede moverse libremente por el mapa y hacer zoom para visualizar marcadores que queden fuera del área mostrada en todo momento, como se puede observar en la Figura 11. Por defecto, el mapa se centra en la primera parada realizada. 27 Figura 11 - Mapa alejado 5.2.6. Automatización Hasta ahora hemos explicado las acciones que el usuario puede realizar de forma manual, pero gran parte del trabajo de este proyecto ha sido dirigido para conseguir que la aplicación Android detecte paradas de forma automática. Una de las acciones más complejas de automatizar fue detectar cuándo el usuario se ha detenido en un lugar, y no confundir una parada con simplemente una corta detención (como por ejemplo esperar en un semáforo). Para detectar la actividad del usuario, se ha empleado la API de GooglePlayServices, la cual ofrece un servicio de detección de actividad mediante el uso de los sensores y acelerómetros de los dispositivos móviles actuales. Esta API es capaz de reconocer diversas actividades que el usuario podría estar realizando y devolver una lista con todas las posibles actividades. Las actividades van acompañadas de un intervalo de confianza para indicar la probabilidad de que realmente se esté realizando esa actividad. 28 El proceso de detección automática se lleva a cabo en la clase Feet3ActivityRecognizeManager. Cuando esta clase es inicializada, se realiza una conexión con la API de Google mediante el uso de un GoogleApiClient, tal como se muestra en el Código 2. Código 2 - Constructor Feet3ActivityRecognizeManager Una vez inicializado el constructor, se procede a llamar al método connect(), el cual realiza las operaciones necesarias para conectar con la API y llama al método onConnected() que podemos ver en el Código 3. Código 3 - Método onConnected La acción que se realiza aquí es solicitar que los resultados de la detección de actividad sean enviados a la subclase ActivityRecognizedService. El parámetro time será el que determine la frecuencia con la que se realicen los análisis de actividad, del cual hablaremos más adelante. 29 La clase ActivityRecognizedService escuchará las respuestas de la API y las mandará a un método llamado handleDetectedActivies, mostrado en el Código 4. Este método es el responsable de la automatización de la detección de las paradas. Código 4 - Algoritmo de automatización Este método recibe una lista de actividades posibles en activityList. Contamos con 3 variables booleanas para ayudarnos a detectar la parada. Estas variables son stopped, moving y registered, inicializadas a falso. La lista recibida es iterada, y por cada elemento se comprueba si se trata de la actividad still (el dispositivo se encuentra quieto, la situación típica en la que se ha dejado encima de una superficie como una mesa o el usuario está sentado con su móvil en el bolsillo). Si en efecto la actividad detectada se trata de still y tenemos una confianza del 90% o mayor, entraremos por la primera condición. En ese momento se comprobará si la variable stopped se encuentra a cierto o falso. Esta variable representa si en la última detección que realizamos se detectó al usuario como still o no. En el caso de que sea falsa, se cambia a verdadera y se finaliza el proceso. En la siguiente comprobación la variable stopped se encuentra a verdadero. Si volvemos a detectar still como actividad realizaremos una comprobación de la variable registered. Esta variable sirve para controlar si la parada en la que nos encontramos ya ha sido registrada o no y evitar registrar la misma parada repetidas 30 veces (esto es, sin habernos puesto realmente en movimiento). En el caso de que la parada no esté registrada (registered es falso) se llamará a la función registerStop() la cual almacenará la parada en la base de datos de forma normal. Tras esta operación la variable registered es cambiada a verdadero para evitar registrar la parada de nuevo. A partir de este momento todas las detecciones consecutivas de still no realizarán ninguna acción. Vayamos al caso contrario. Cuando la actividad detectada no es still o no tiene al menos un 90% de confianza entramos por la segunda parte de la condición. En ese momento entra en acción la variable moving, la cual es comprobada. En esta situación se encuentra en falso, ya que es inicializada a falso y también es declarada como falso cuando entramos por la rama de detección de still. La siguiente acción es declarar la variable moving como verdadero sin realizar ninguna otra acción. El objetivo de esta variable es evitar que dejemos de considerar una parada en el caso de que el usuario decida usar su dispositivo móvil momentáneamente (como por ejemplo, mirar la hora o consultar mensajes) sin que realmente haya cambiado de lugar. Esta variable nos indica si se ha detectado dos veces seguidas que el usuario se encuentra en movimiento. Si en la siguiente comprobación de actividad se vuelve a detectar al usuario en movimiento, la variable moving se encuentra ahora a verdadero, por lo que entramos por la otra rama en la cual se reinician las variables stopped y registered y dejamos de considerar que aún permanecemos en la parada detectada. Tras esta acción el proceso lógico queda reiniciado al estado inicial (en el que esperamos que el usuario se detenga para registrar una nueva parada). En el caso de que el usuario haya realizado una parada y ésta se haya registrado correctamente, las variables stopped y registered se encontrarían en verdadero y la variable moving en falso. Si el usuario utilizase su dispositivo móvil se detectaría que el usuario no se encuentra still, por lo que la variable moving sería declarada a verdadero. Sin embargo, si el dispositivo móvil vuelve a encontrarse en reposo se detectaría la actividad still, por lo que como se puede ver en la imagen la variable moving sería reiniciada a falso y se seguiría considerando la misma parada. El intervalo en el que se realizan las comprobaciones de actividad es determinado por la variable timer vista anteriormente, la cual puede ser determinada por el usuario mediante el uso del menú de preferencias, tal como será explicado en el siguiente apartado 31 5.2.7. Preferencias El usuario puede ajustar dos parámetros de la aplicación. Para ello, se debe encontrar en la vista principal de la aplicación Android visible en la Figura 12 y pulsar el botón con forma de engranaje situado en la parte superior derecha de la pantalla. Figura 12 - Botón de preferencias Tras pulsar el botón se abrirá la vista de Preferencias en la cual se muestran los dos valores que pueden ser ajustados tal como se muestra en la Figura 13. 32 Figura 13 – Preferencias En las figuras 14 y 15 se visualizan ambos menús desplegables. El primer valor se trata del Tiempo de detección de parada, el cual determina cada cuánto tiempo se realizará una comprobación automática de actividad para la detección de paradas automática. Este valor se podrá ajustar en intervalos de un minuto, y tomará valores entre 1 minuto y 10, siendo 6 minutos el valor por defecto. Para ello solo hay que pulsar sobre el texto y elegir el valor deseado. 33 Figura 14 - Tiempo de detección de parada Figura 15 - Distancia de detección de parada El segundo parámetro se trata de la Distancia de detección de parada. Este valor determina a qué distancia mínima las paradas serán consideradas realizadas en la misma posición o se guardarán como una posición nueva. Este parámetro podrá tomar valores entre 1 metro y 50 metros, siendo 20 metros el valor por defecto, y para cambiarlo solo se debe pulsar el texto y elegir el valor deseado. Cabe destacar que este parámetro afectará tanto a las paradas manuales como a las automáticas. 5.3. Pruebas La realización de pruebas de una aplicación Android que emplea geolocalización y mapas resulta complicada y costosa en tiempo. Los emuladores que se suelen emplear para esta plataforma no tienen la capacidad de simular 40 41 Apéndices A. Manual de usuario La aplicación se proporciona en el CD incluido junto a la memoria entregada. Sin embargo si se desea se puede descargar un APK de la aplicación utilizando el siguiente enlace: https://drive.google.com/open?id=0B44rCJ2SNeBJVlZWYXI0MFpNMTQ Una vez dispongamos del APK sólo habrá que copiar el mismo en el dispositivo móvil Android y ejecutarlo, lo que procederá a instalar la aplicación en el terminal. Es posible que sea necesario permitir la instalación de aplicaciones de origen desconocido. Dicha opción se encuentra generalmente en el apartado de seguridad del dispositivo. Ya instalada la aplicación lo único que hay que hacer es pulsar en el icono para abrirla. Lo primero que ocurrirá, en terminales con versión de Android 6.0 o superior, será la solicitud de los permisos de GPS, los cuales deben ser aceptados para el correcto funcionamiento de la aplicación. Una vez hecho esto la aplicación estará lista para funcionar. En el caso de tener una versión de Android inferior a 6.0 no hará falta otorgar permisos a la aplicación, puesto que se realiza de forma automática al instalarla. Feet3 comenzará a detectar paradas automáticamente sin necesidad de ninguna interacción por parte del usuario. Siempre que la aplicación se encuentre activa o en segundo plano, seguirá detectando paradas. Sin embargo, si la aplicación es terminada mediante el menú de finalización de aplicaciones, se detendrá la detección automática completamente. Es importante comprobar que el servicio de Ubicación del dispositivo se encuentre activo, puesto que sin él no se podrán detectar posiciones geográficas, ya sea mediante el uso de GPS o de ubicación por redes. La interfaz de la aplicación es sencilla de entender, en las Figuras 19 y 20 se encuentran marcados los elementos más importantes: 42 Figura 18 - Manual Main Activity 1. Botón de preferencias: Abre el menú de preferencias 2. Lista de Historial de paradas: Lista navegable en la que se muestran todas las paradas realizadas. 3. Botón de guardar localización: Al pulsar el botón se guardará inmediatamente una parada en el lugar en el que se encuentre el usuario. 4. Botón de borrar historial: Permite borrar todo el historial de paradas almacenado en la base de datos local del dispositivo. 43 Figura 19 - Manual Información adicional 1. Nombre de posición: Nombre asignado a la posición en la que se encuentra la parada. En el caso de que no se le haya asignado ningún nombre se mostrará por defecto las coordenadas de la posición. 2. Botón de mapa: Botón que abre la vista gráfica de paradas mediante mapa. 3. Lista de Historial de paradas: Lista navegable en la que se muestran todas las fechas en las que se detectó una parada en dicha posición. 4. Lista de Redes detectadas: Lista navegable que muestra las redes detectadas en la fecha seleccionada. Si se pulsa sobre una red se abrirá el menú para editar su nombre. 44 Índice de figuras Figura 1 - Casos de uso ............................................................................................. 7 Figura 2 - Modelo relacional de la base de datos ..................................................... 13 Figura 3 - Diagrama de clases .................................................................................. 15 Figura 4 - Estructura de la aplicación Android .......................................................... 17 Figura 5 - Main Activity ............................................................................................. 20 Figura 6 - Historial de paradas ................................................................................. 21 Figura 7 - Información adicional ............................................................................... 23 Figura 8 - Información adicional remarcada ............................................................. 24 Figura 9 - Edición de nombre ................................................................................... 25 Figura 10 - Visualización mediante mapa ................................................................. 26 Figura 11 - Mapa alejado .......................................................................................... 27 Figura 12 - Botón de preferencias ............................................................................ 31 Figura 13 - Preferencias ........................................................................................... 32 Figura 14 - Tiempo de detección de parada ............................................................. 33 Figura 15 - Distancia de detección de parada .......................................................... 33 Figura 16 - Prueba 1 ................................................................................................. 34 Figura 17 - Prueba 2 ................................................................................................. 35 Figura 18 - Manual Main Activity .............................................................................. 42 Figura 19 - Manual Información adicional ................................................................. 43 45 Índice de tablas Tabla 1 - Requisitos funcionales ................................................................................. 5 Tabla 2 - Requisitos no funcionales ............................................................................ 6 Tabla 3: Caso de uso 1 .............................................................................................. 8 Tabla 4 - Caso de uso 2 ............................................................................................. 8 Tabla 5 - Caso de uso 3 ............................................................................................. 9 Tabla 6 - Caso de uso 4 ............................................................................................. 9 Tabla 7 - Caso de uso 5 ........................................................................................... 10 Tabla 8 - Caso de uso 6 ........................................................................................... 11 Tabla 9 - Caso de uso 7 ........................................................................................... 11 Tabla 10 - Caso de uso 8 ......................................................................................... 12