Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos

Escola Tècnica Superior d’Enginyeria Informàtica Universitat Politècnica de València Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos Trabajo Fin de Grado Grado en Ingeniería Informática Autor: Alejandro Sanjuán Quiles Tutor: José Luis Poza Luján Cotutor: Juan Luis Posadas Yagüe Curso Académico 2014-2015 Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 2 3 Resumen El presente trabajo de fin de grado describe paso a paso el proceso de desarrollo de una aplicación Android que forma parte de un sistema distribuido mayor. La aplicación ofrece a la sociedad la posibilidad de enviar avisos multimedia relativos a la pérdida o avistamiento de animales a un servidor remoto para su posterior cotejamiento. De esta forma se consigue ayudar a las asociaciones protectoras de animales en la tarea de localizar a los animales perdidos o abandonados para que así puedan ser recogidos, cuidados o dados en adopción. En este documento se describe el trabajo realizado consistente en: un análisis del mercado actual en aplicaciones de este ámbito, una especificación de los requisitos que la aplicación ha de cumplir, un diseño para la aplicación, su implementación y por último las pruebas realizadas. Palabras clave: animal, mascota, perdido, abandonado, aviso, aplicación, app, Android, sistema distribuido, servicio web, REST, Java. Abstract The present project describes step by step the whole development process made for an Android application, which is part of a greater distributed system. The application provides the society with the means for sending warnings related with the lost or sighting of animals to a remote server for its later collation. By this method the Animal Protection Societies get some assistance in the task of locating lost or abandoned animals. After that the animals can be gathered up, taken care of, and given a new home. In this document is described the work carried out consistent in an analysis of the current market in applications of this scope, an specification of the requirements that the application have to meet, a design for the application, and its implementation and finally the tests that have been made. Keywords: animal, pet, lost, abandoned, warning, application, app, Android, distributed system, web service, REST, Java. Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 4 5 Tabla de contenidos 1. Introducción ........................................................................................................................ 12 1.1. Contexto y motivación ................................................................................................ 12 1.2. Objetivos ..................................................................................................................... 12 1.3. Descripción del documento ......................................................................................... 12 2. Análisis estratégico ............................................................................................................. 14 2.1. Introducción ................................................................................................................ 14 2.2. Sistemas similares ....................................................................................................... 14 2.2.1. Animales Sin Hogar ............................................................................................ 15 2.2.2. Alerta Animal ...................................................................................................... 16 2.2.3. PetFinder.my ....................................................................................................... 17 2.2.4. HeLP Lost and Adoptable Pets ........................................................................... 18 2.2.5. Charleston Animal Society .................................................................................. 19 2.2.6. Callejerito Help! .................................................................................................. 20 2.2.7. Guau! qué perros ................................................................................................. 21 2.2.8. Encuéntralos ........................................................................................................ 22 2.2.9. Find My Pet ......................................................................................................... 23 2.2.10. Pet Finder ............................................................................................................ 24 2.2.11. Pet Search ............................................................................................................ 25 2.2.12. Back2Gether ........................................................................................................ 26 2.2.13. Pet Position .......................................................................................................... 26 2.2.14. PetCrumbs ........................................................................................................... 26 2.2.15. iRescue Pet .......................................................................................................... 27 2.2.16. Otras aplicaciones ............................................................................................... 27 2.3. Análisis de los sistemas similares ............................................................................... 28 2.3.1. Características generales ..................................................................................... 28 2.3.2. Introducción de datos en el sistema ..................................................................... 30 2.3.3. Rasgos animales .................................................................................................. 32 2.3.4. Otras características ............................................................................................. 34 2.4. Síntesis de características ............................................................................................ 35 2.5. Conclusiones ............................................................................................................... 37 3. Especificación de requisitos ................................................................................................ 38 Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 6 3.1. Introducción ................................................................................................................ 38 3.1.1. Propósito.............................................................................................................. 38 3.1.2. Ámbito del sistema .............................................................................................. 38 3.1.3. Definiciones, acrónimos y abreviaturas .............................................................. 39 3.1.4. Visión general del documento ............................................................................. 39 3.2. Descripción general ..................................................................................................... 40 3.2.1. Perspectiva del producto ..................................................................................... 40 3.2.2. Funciones del producto (de la aplicación) ........................................................... 41 3.2.3. Características de los usuarios ............................................................................. 42 3.2.4. Restricciones ....................................................................................................... 42 3.2.5. Suposiciones y dependencias .............................................................................. 42 3.3. Requisitos específicos ................................................................................................. 42 3.3.1. Interfaces externas ............................................................................................... 43 3.3.2. Requisitos funcionales ......................................................................................... 43 3.3.3. Requisitos no funcionales .................................................................................... 45 4. Diseño del sistema ............................................................................................................... 47 4.1. Introducción ................................................................................................................ 47 4.2. Diseño global .............................................................................................................. 47 4.3. Diseño por capas ......................................................................................................... 49 4.3.1. Presentación ........................................................................................................ 49 4.3.2. Negocio ............................................................................................................... 50 4.3.3. Persistencia .......................................................................................................... 56 4.4. Conclusiones ............................................................................................................... 56 5. Implementación y Pruebas .................................................................................................. 57 5.1. Introducción ................................................................................................................ 57 5.2. Aplicación Android ..................................................................................................... 57 5.2.1. Código ................................................................................................................. 57 5.2.2. Recursos estáticos e interfaces ............................................................................ 64 5.3. Sistema soporte de la aplicación ................................................................................. 70 5.3.1. Servicios Web Implementados ............................................................................ 71 5.3.2. Base de datos ....................................................................................................... 72 5.4. Pruebas ........................................................................................................................ 73 5.4.1. Gestión de usuarios ............................................................................................. 73 5.4.2. Gestión de avisos ................................................................................................. 74 5.4.3. Localización ........................................................................................................ 75 5.4.4. Configuración ...................................................................................................... 77 7 5.4.5. Resultado de las pruebas ..................................................................................... 77 6. Conclusiones ....................................................................................................................... 78 6.1. Dificultades encontradas ............................................................................................. 78 6.2. Aportaciones realizadas ............................................................................................... 78 6.3. Trabajo futuro .............................................................................................................. 79 Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 8 Índice de figuras Figura 1 – Animales Sin Hogar (Google Play) ........................................................................... 15 Figura 2 – Alerta Animal (Google Play) ..................................................................................... 16 Figura 3 – PetFinder.my (Google Play) ...................................................................................... 17 Figura 4 – HeLP (Google Play)................................................................................................... 18 Figura 5 – Charleston Animal Society (Google Play) ................................................................. 19 Figura 6 – Callejerito Help! (Google Play) ................................................................................. 20 Figura 7 – Guau! Qué perros (Google Play) ............................................................................... 21 Figura 8 – Encuéntralos (Google Play) ....................................................................................... 22 Figura 9 – Found My Pet (Google Play) ..................................................................................... 23 Figura 10 – Pet Finder (Google Play) ......................................................................................... 24 Figura 11 – Pet Search (Google Play) ......................................................................................... 25 Figura 12 – Gráfica del uso de las diferentes versiones similares de Android a lo largo de los años ..... 36 Figura 13 – Perspectiva del producto .......................................................................................... 40 Figura 14 – Diagrama de casos de uso para la aplicación ........................................................... 41 Figura 15 – Diagrama de componentes de la aplicación ............................................................. 48 Figura 16 – Prototipos o Mock-Ups diseñados para la aplicación............................................... 49 Figura 17 – Diagrama de clases de la aplicación ........................................................................ 51 Figura 18 – Diagrama de secuencia: Inicio de sesión ................................................................. 52 Figura 19 – Diagrama de secuencia: Enviar aviso ...................................................................... 52 Figura 20 – Diagrama de secuencia: Enviar imagen ................................................................... 53 Figura 21 – Diagrama de secuencia: Enviar localización del dispositivo ................................... 53 Figura 22 – Diagrama de secuencia: Enviar grabación de audio ................................................ 54 Figura 23 – Diagrama de secuencia: Grabar audio ..................................................................... 54 Figura 24 – Diagrama de secuencia: Cambiar parámetro configurable ...................................... 55 Figura 25 – Carpeta src ............................................................................................................... 58 Figura 26 – Pantalla de espera ..................................................................................................... 61 9 Figura 27 – Diálogo de configuración de la localización ............................................................ 61 Figura 28 – Carpeta res (1/2) ....................................................................................................... 64 Figura 29 – Carpeta res (2/2) ....................................................................................................... 66 Figura 30 – Interfaz de arranque ................................................................................................. 67 Figura 31 – Interfaz de inicio de sesión (Orientación vertical) ................................................... 67 Figura 32 – Interfaz de inicio de sesión (Orientación Horizontal) .............................................. 68 Figura 33 – Interfaz de configuración ......................................................................................... 68 Figura 34 – Interfaces de envío de aviso (Orientación vertical) ................................................. 69 Figura 35 – Interfaz de envío de aviso (Orientación Horizontal) ................................................ 69 Figura 36 – Interfaz de grabación de audio ................................................................................. 70 Figura 37 – Tablas de la base de datos ........................................................................................ 72 Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 16 2.2.2. Alerta Animal Esta aplicación (véase [3]) permite al usuario crear una denuncia en situaciones en las que aparecen animales siendo maltratados o abandonados. Dispone de dos partes. La primera parte nos ofrece información relativa a:  ¿Qué situaciones son denunciables?  ¿Quién recibe mi denuncia?  ¿Puedo preservar el anonimato?  ¿Cómo puedo informarme sobre la situación denunciada? A su vez nos ofrecen diferentes enlaces a páginas web y a redes sociales (Facebook y Twitter) propias de la asociación. La navegación se hace dentro de la propia app. La segunda permite hacer una denuncia. Pudiendo añadir texto, una única foto, un video y por último la ubicación. Figura 2 – Alerta Animal (Google Play) 17 2.2.3. PetFinder.my Esta aplicación (véase [4]) dispone de publicaciones del estilo post, en diferentes secciones, con la posibilidad de utilizar filtros en todos los casos. Estas disponen de una foto principal, con información general del animal como por ejemplo de qué animal se trata, si está perdido, en adopción o encontrado o su sexo y edad. También dispone de localización aunque aparentemente sin mostrarla en un mapa, de una galería de fotos y videos, de información de contacto y de la opción de dejar comentarios. Al entrar a la aplicación se accede directamente a una pantalla con publicaciones relativas a animales en adopción. Pulsando en un botón de menú nos permite acceder a nuevas opciones. Estas son:  Find a pet: Se trata de la pantalla inicial de adopción.  Lost & Found: Publicaciones relativas a animales perdidos o encontrados.  Visual Map: Dice buscar avisos relativos a la posición del usuario pero muestra un mapa exclusivamente de Malasia.  Favourites: Requiere autenticarse.  My account: Requiere autenticarse.  About Us: Dispone de un pequeño texto sobre el portal web de la aplicación, algunos links así como información sobre la app. Figura 3 – PetFinder.my (Google Play) Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 18 2.2.4. HeLP Lost and Adoptable Pets Aplicación (véase [5]) cuyo objetivo es ayudar a los animales perdidos. Dispone de cinco secciones:  My pets: Requiere autenticarse.  Adoptable Pets: Te lleva a un formulario para filtrar los animales que se pueden adoptar.  Missing Pets: Igual que la anterior pero para animales perdidos.  Emergency: Ofrece una lista de diferentes servicios, no solo de emergencia, sino también de otros servicios relativos a mascotas. Permite seleccionar más de una opción, pero al final te lleva a un formulario idéntico en la web de la asociación.  Snap and Send: Permite enviar fotos de posters de la calle sobre animales perdidos. Figura 4 – HeLP (Google Play) 19 2.2.5. Charleston Animal Society Esta app (véase [6]) dispone de muchos menús. Algunos de ellos son:  Donate  Adopt: Permite ver publicaciones sobre perros y gatos en adopción. Muestra información general del animal así como una foto opcionalmente.  Events: En nuestro caso no muestra ningún evento.  Bark Wall: Pequeña red social del estilo de Facebook pero para animales que permite compartir comentarios, ubicaciones y fotos, permitiendo filtrar por recientes o por cercanía.  Alerts: No muestra alertas.  Dog parks: Nos muestra en mapa o en lista diferentes parques para perros en Nueva York. No funciona muy bien, y ni siquiera está acabada.  Submit a photo  Lost & Found: No funciona.  Dog Training  Facebook y Twitter  Volunteer Program  Adoption Notes  About us y About the app Figura 5 – Charleston Animal Society (Google Play) Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 20 2.2.6. Callejerito Help! Aplicación (véase [7]) que tiene como función recoger datos de animales encontrados introducidos por el usuario, así como una foto y su localización y automáticamente hacer un cotejamiento con posibles similitudes en el ámbito mundial. Permite una descripción del animal bastante completa mediante formularios, y no da rodeos, ya que no dispone de un menú como es normal en otras apps, si no que directamente se hace la notificación. Solo permite perros y gatos. Figura 6 – Callejerito Help! (Google Play) 21 2.2.7. Guau! qué perros Esta app (véase [8]) nada más entrar, nos muestra tres menús parecidos, uno para perros en adopción, otro para perros perdidos, y otro para perros encontrados, así como un cuarto menú para la configuración de la app. En los tres primeros nos muestra avisos según el menú en el que se está en ese momento. Además permite publicar un nuevo aviso. A la hora de hacer una publicación, se nos permite introducir información general del animal, una descripción, así como una foto. En el cuarto menú, nos permite configurar un filtro para los otros tres menús. Permite filtrado por ciudad (España), raza del perro o sexo. Figura 7 – Guau! Qué perros (Google Play) Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 22 2.2.8. Encuéntralos Aplicación (véase [9]) que muestra animales perdidos, filtrados por proximidad al usuario. Para cada animal perdido podemos ver su foto, su descripción e información de contacto, la ubicación en un mapa español sin nombres (pero permite hacer zoom) y por último dejar comentarios. También si hemos iniciado sesión nos permite algunas otras opciones entre ellas la de subscribirse a las actualizaciones sobre una mascota concreta, o introducir un aviso de pérdida o de encuentro de una mascota. En este caso permite introducir la información de contacto, una foto del animal, una descripción en forma de texto y la localización y fecha del suceso. Figura 8 – Encuéntralos (Google Play) 23 2.2.9. Find My Pet Esta aplicación (véase [10]) requiere estar registrado, permitiéndote hacerlo desde la app. Al registrarte dice que tomará información como la IP e ID del dispositivo, además te pide tu posición, email y número de teléfono. Una vez registrado accedes al menú principal el cual incluye:  My pets: Permite crear una ficha de tu mascota incluyendo información general y foto. La forma de introducir la información es de tipo formulario.  I Lost My Pet: Deja poner un aviso indicando que una mascota se ha perdido pudiendo añadir una descripción y una posible recompensa ambos en forma de texto, así como añadir la ubicación. También permite ver alertas.  Lost Pets Around Me: Muestra un mapa mundial sin ningún aviso en él.  Lost and Found: Al entrar a esta página sale un mensaje de “No has recibido ninguna alerta aun”, refiriéndose a que no se ha puesto ningún aviso relativo a una mascota propia perdida. También permite poner un aviso de animal encontrado pudiendo añadir un comentario de 255 caracteres, la especie, y la ubicación.  Articles: Este menú permite ver en forma de páginas web dentro de la misma app una gran cantidad de artículos sobre el cuidado de las mascotas. Esta aplicación utiliza una cantidad ingente de publicidad intersticial (pop-ups). A pesar de ello funciona ágilmente además de disponer de una interfaz muy cuidada y que el usuario agradecerá. Figura 9 – Found My Pet (Google Play) Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 24 2.2.10. Pet Finder Aplicación (véase [11]) que permite, tras hacer log in (inicio de sesión) con Facebook, notificar la pérdida o el encuentro de una mascota rellenando un formulario idéntico en los dos casos que permite insertar el nombre de la mascota, la ubicación, la descripción, el email, el teléfono de contacto y una foto. Por otro lado te permite buscar notificaciones recientes y cercanas, y además, ofrece información sobre diferentes organizaciones de animales de Bogotá. Figura 10 – Pet Finder (Google Play) 25 2.2.11. Pet Search Las diferentes secciones de esta app (véase [12]) son:  About us  Receive Lost Alerts: Permite registrarte para ser avisado cuando un animal es encontrado cerca tuya.  Animal Shelters  Found Stray: Rico y bastante extenso formulario para notificar que un animal ha sido encontrado  Lost a pet: Información sobre qué hacer al perder un animal.  Información de contacto, de redes sociales, y de videos, así como de promociones. Figura 11 – Pet Search (Google Play) Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 32 App TX FM LO FT AU DV NI Animales sin hogar No No No No No No Sí Alerta Animal Sí No Sí Sí No No No PetFinder Sí Sí Sí Sí No No No HeLP No Sí Sí Sí No No No Charleston Animal Society No No No No No No Sí Callejerito Help! No Sí Sí Sí No No No Guau! Qué perros Sí Sí No Sí No No No Encuéntralos Sí Sí Sí Sí No No No Find My Pet No Sí Sí Sí No No No Pet Finder Sí Sí Sí Sí No No No Pet Search Sí Sí Sí No No No No Back2gether Sí Sí Sí Sí No No No Pet Position Sí No Sí Sí No No No PetCrumbs Sí Sí Sí Sí No No No iRescue Pet Sí Sí Sí Sí No No No Tabla 2 – Comparativa de la introducción de datos en el sistema para los diferentes sistemas similares 2.3.3. Rasgos animales En cuanto a la descripción de un animal, podemos acudir a una gran variedad de rasgos característicos que diferencian a los animales unos de otros. Cuantos más rasgos una aplicación permita introducir, más preciso será su cotejamiento posterior a la hora de buscar coincidencias con otros avistamientos/pérdidas, y mejor resultado podrá ofrecer por tanto la aplicación. Para poder cuantificar correctamente los rasgos que permite utilizar cada aplicación, vamos a indicar en la tabla 3 el número de posibles valores para ese rasgo concreto. En caso de que se permita introducir texto o el rango de valores quede abierto de otra forma, aparecerá una ‘A’ de Abierto para ese rasgo y esa aplicación. En el caso contrario de que no quede claro la forma en que se introduce el valor, se indicara ‘NS’ de No se Sabe. Si aparece un ‘+’ justo después de un valor numérico indicaremos un número mayor que el indicado. Por último, cabe destacar que por lo general el que se permitan rangos de valores abiertos, es un claro indicativo de que los datos serán posteriormente procesados por un humano, ya que estos campos son bastante difíciles de procesar por un ordenador, y por lo contrario, rangos de valores limitados podrían ser tanto procesados por humanos como automáticamente. 1. Número de especies animales (ES) Algunas aplicaciones solo sirven para perros perdidos o abandonados. Otras además incluyen gatos. Idealmente deberían abarcar más especies. 33 2. Raza (RA) La aplicación permite o no introducir la raza del animal como puede ser “Yorkshire Terrier” para una especie “Perro” o “Siamés” para un “Gato”. 3. Tamaños diferentes (TA) Normalmente esto podrá ser 3 posibles valores (“pequeño”, “mediano”, “grande”) o ninguno. Esto puede ser subjetivo. 4. Edad (ED) La edad del animal, puede ser difícil de discernir en un animal encontrado, pero en el caso de una pérdida, sí que será fácil de saber. A pesar de esta incertidumbre, puede utilizarse de manera orientativa ya que por ejemplo sí que podría saberse si el animal es recién nacido o viejo. 5. Sexo (SE) Por lo general dos posibles valores o ninguno aunque en algunos casos se introduce un tercer valor como puede ser “no se aprecia” o “camada”, aunque en este último caso los otros datos quedan algo ambiguos por tratarse de más de un animal. 6. Temperamento (TM) Si el animal es “tranquilo”, “nervioso”, “juguetón”, etc. Esto es muy subjetivo porque depende de la persona con la que se encuentre el animal, su estado en ese momento, o si no está acostumbrado a estar fuera de casa. 7. Colores (CL) Para este rasgo normalmente con valores abiertos, en la tabla 3, se indicará en primer lugar el número de colores primarios, y seguidamente entre paréntesis el número de colores secundarios refiriéndose por ejemplo al color de las manchas, o de las rayas, etc. 8. Forma de las marcas (MA) La forma de las marcas podrían ser manchas grandes, pequeñas, motitas, etc. Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 34 9. Rasgos característicos (RC) Esto podría referirse a cualquiera de las anteriores, o por otro lado, cualquier otra información adicional que el usuario crea que ayudará a reconocer al animal. Esto esta generalmente relacionado con un campo de texto abierto. App ES RA TA ED SE TM CL MA RC Animales sin hogar 5+ 0 0 0 2 0 0 0 A Alerta Animal 0 0 0 0 0 0 0 0 A PetFinder 8 50+ 0 6 2 0 0 0 A HeLP 9 50+ 4 4 2 0 0 0 A Charleston Animal Society 2 NS NS NS NS NS NS NS NS Callejerito Help! 2 0 3 0 3 0 6 6 6 Guau! Qué perros 1 50+ 0 A 3 0 0 0 A Encuéntralos 4 50+ 0 0 0 0 0 0 A Find My Pet 8 A A A 2 0 0 0 A Pet Finder 0 0 0 0 0 0 0 0 A Pet Search A A 0 0 2 0 A A A Back2gether 1 50+ 3 3 2 0 0 0 A Pet Position A A 0 0 0 A 0 0 A PetCrumbs 0 0 0 0 0 0 0 0 A iRescue Pet 5 A 3 0 0 0 A A A Tabla 3 – Comparativa de los rasgos animales disponibles para los diferentes sistemas similares 2.3.4. Otras características Además de todas las características vistas anteriormente, aún existen algunas otras que también son interesantes y merece la pena analizar pero no forman parte de ninguno de los grupos anteriores. Estas características se estudian a continuación. 1. Tipo de procesamiento (TP) Los datos son procesados por personas como por ejemplo en el caso del modelo de post, automáticamente (cotejando nuevos sucesos con sucesos anteriores) o automáticamente con supervisión humana para comprobar que el resultado del cotejamiento es correcto. En la tabla 4 se indicara “H” para procesamiento humano, “A” para el automático, “S” para el caso de que este sea supervisado, o “NS” si no se puede saber. 2. Funcionamiento (FU) Esta característica es bastante subjetiva e indica si la aplicación no funciona nada, funciona mal, o funciona correctamente. Será medida del 1 al 5 siendo “1” que no funciona y “5” que no hay ningún problema con el funcionamiento. 35 3. Interfaz amistosa (IA) Es importante que la aplicación tenga una interfaz agradable, que invite al usuario a utilizarla. En la tabla 4 se mide del 1 al 5, siendo el “1” nada agradable y “5” muy agradable. 4. Filtrado (FI) Cuando existan muchos avisos de animales perdidos o encontrados, es adecuado que exista una opción para filtrar a través de diferentes campos del aviso. Indicaremos con un valor numérico positivo el número de filtros disponibles, mientras que con un “0”, la ausencia de filtros. 5. Protección de los datos (PD) En este tipo de aplicaciones puede existir información sensible como por ejemplo la ubicación de un animal perdido. En la tabla 4 indicaremos con un “No” si existe información sensible no protegida, y por lo tanto está abierta al público y con un “Sí” si por lo contrario, sí que está protegida y solo es accesible por personas de confianza. “NS” indicará que no se conoce. App TP FU IA FI PD Animales sin hogar H 2 3 0 No Alerta Animal H 5 5 0 Sí PetFinder H 3 4 7 No HeLP NS 2 4 6 NS Charleston Animal Society H 1 3 1 NS Callejerito Help! S 4 4 0 Sí Guau! Qué perros H 5 5 3 Sí Encuéntralos H 4 2 1 No Find My Pet NS 3 5 0 No Pet Finder H 4 4 2 No Pet Search H 3 2 0 Sí Back2gether A 5 5 1 No Pet Position H 3 3 1 NS PetCrumbs H 4 5 3 No iRescue Pet H 4 5 3 NS Tabla 4 – Comparativa de otras características para los diferentes sistemas similares 2.4. Síntesis de características Una vez vistas las características existentes en las aplicaciones del mercado, lo siguiente es plantearse cómo sería la aplicación ideal buscada en este proyecto. Esta, debería estar por lo menos disponible en Android, el sistema móvil más utilizado hoy en día. Además debería poder funcionar en sistemas a partir de Android 4.1 conocido como Jelly Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 36 Bean, alcanzando así más del 90% de dispositivos Android como se aprecia en la figura 12 (Véase [14]). También se ha visto que prácticamente todas las aplicaciones son gratuitas, algo que es normal, dada la naturaleza voluntaria de estas aplicaciones. Así que esta aplicación debería ser también gratuita para que tenga éxito. Figura 12 – Gráfica del uso de las diferentes versiones similares de Android a lo largo de los años En cuanto a la introducción de información, hay que buscar la manera que implique menos interacciones del usuario con el sistema. Por lo tanto es deseable que el usuario pueda introducir la información mediante audio o imágenes con unos pocos toques en la pantalla, y estos puedan ser procesados en un servidor externo para extraer los rasgos del animal. Esto requiere que en algún punto del proceso, haya un humano supervisando que todo salga correcto. Otra forma posible es que el usuario pueda introducir audio, y este sea procesado por la propia app, y posteriormente, un formulario corriente sea rellenado con los datos extraídos. En este caso, el usuario introduciría la información con unos pocos toques (menos que en un formulario corriente) y podría verificar/corregir la información antes de enviarla, ahorrando tiempo de supervisión en el servidor. Además, la aplicación ideal contaría con el dibujo virtual, función que no aparece en ninguna otra aplicación. Esto se refiere a que el usuario según vaya introduciendo información, un dibujo virtual del animal se va creando para que el usuario pueda verificar lo que el sistema ha captado gráficamente, e incluso, que pueda introducirla o corregirla directamente sobre el dibujo. Por lo que a los rasgos animales se refiere, lo ideal sería, utilizar la cantidad mínima de rasgos, que consiga identificar correctamente un porcentaje de animales por encima de un umbral (por ejemplo el 90% de los animales), siendo así estos los rasgos más característicos o discriminativos de entre todos los posibles. Si se dispone de una cantidad grande de datos reales, esto se puede averiguar mediante el uso de algoritmos como LDA, PCA, etc. (Véase [15]). 37 Además debe de existir un servidor, implementando servicios web REST, capaz de cotejar los diferentes sucesos en busca de coincidencias entre ellos. Por ejemplo si existe un aviso de un animal perdido, y se da de alta un aviso de que se ha encontrado un animal, el servidor, teniendo en cuenta los rasgos, el momento de los avisos, y la distancia entre los sucesos ha de ser capaz de decir si se trata del mismo animal o no. Otro factor a tener en cuenta para la aplicación es que esta debería contar con diferentes perfiles de usuario y ofrecer unas funcionalidades u otras dependiendo de la persona que se haya autenticado. Los perfiles de usuario serían el de usuario colaborador, el de usuario corriente y opcionalmente el de usuario no registrado teniendo más privilegios el primero y menos el último. Un usuario no registrado, en caso de existir, sería capaz de avisar de que un animal se ha encontrado perdido o abandonado. En cambio un usuario corriente además de esto, podría dar de alta un animal perdido. La diferencia entre un caso y otro, es que para un animal encontrado no hace falta necesariamente una dirección de contacto. Simplemente con el aviso y la localización, un usuario colaborador sería capaz de ir a buscar al animal. Estos dos perfiles, al no tener información sobre ellos, no se les permitiría ver la localización de los animales. Por otro lado, además de lo anterior, un usuario colaborador debe de poder ver todas las incidencias y la ubicación precisa del animal, por si hiciese falta ir a buscarlo. También podría recibir notificaciones al encontrarse avisos nuevos, o cotejamientos en el servidor con resultado positivo. Por último, esta aplicación tendría una interfaz agradable, nativa de Android, y funcionaría ágilmente (así como el servidor) y con los mínimos bloqueos. El servidor por otro lado, debe estar disponible las 24h y ser escalable para poder atender todas las peticiones. Esto es algo importante si se quiere que la aplicación tenga éxito. 2.5. Conclusiones En este capítulo se han tomado diferentes aplicaciones móviles existentes para dispositivos Android e iOS en el ámbito del aviso y localización de animales perdidos, y se han revisado cuidadosamente sus características. Una vez hecho esto ha sido posible sintetizar todo esto, en una serie de características deseables para una aplicación ideal de estas características. Esta aplicación ideal es un objetivo bastante difícil de alcanzar en este trabajo por cuestiones de tiempo y depende en gran medida de un servidor existente en el que confiar. Por ello, definiremos una aplicación con menor complejidad, que se adapte a las limitaciones existentes y que será la aplicación objetivo de este trabajo. En el siguiente capítulo se procederá a especificar según el formato del estándar IEEE-830 los requisitos funcionales y no funcionales para esta aplicación. Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 38 3. Especificación de requisitos 3.1. Introducción En este capítulo se describe la Especificación de Requisitos del Software (ERS) de la aplicación móvil para el sistema operativo Android cuya funcionalidad es la de avisar y localizar animales perdidos o abandonados. Este apartado sigue la estructura definida y las prácticas recomendadas en el estándar IEEE 830-1998. Véase [16]. 3.1.1. Propósito El presente capítulo tiene como propósito definir los requisitos funcionales y no funcionales de la app para el sistema de aviso y localización de animales perdidos. Está dirigido al equipo de desarrollo de la aplicación y servirá como punto de partida para el diseño, y posterior implementación de la misma. Además en el caso de que existiese un cliente, permitiría llegar a un acuerdo con este para definir qué es lo que tiene que hacer la aplicación. 3.1.2. Ámbito del sistema El objetivo del desarrollo de este sistema, es el de facilitar la localización y rescate de animales perdidos o abandonados a las asociaciones protectoras de animales. Esto se conseguirá mediante el envío con la app Android por parte de los ciudadanos de avisos al perder un animal, o al encontrar uno perdido. Esta información recogida y almacenada por un servidor, será procesada por este, y cotejada para encontrar posibles coincidencias entre avisos. 39 3.1.3. Definiciones, acrónimos y abreviaturas Término Descripción HTTP HyperText Transfer Protocol es un protocolo que permite a aplicaciones ejecutándose en diferentes máquinas intercambiar información. HTTP ofrece métodos para solicitar información (GET), para enviarla (POST), actualizarla (PUT) o eliminarla (DELETE) remotamente (Véase [17]) JSON JavaScript Object Notation es un lenguaje utilizado para intercambiar objetos con datos. Su función es la de codificar estos objetos en texto plano para su posterior intercambio. Su sintaxis está basada en la de los objetos del lenguaje JavaScript (Véase [18]) Localización Par de valores consistentes en una latitud y una longitud, que definen una posición en el planeta Tierra. También pueden incluir la altitud para una mayor precisión REST Representational State Transfer es una arquitectura concreta para servicios Web que utiliza HTTP como canal para intercambiar mensajes y JSON o XML para codificar el mensaje enviado [19] Servicio Web Interfaz de un servidor web que permite intercambiar información con este. Esta interfaz ha sido definida mediante un conjunto de protocolos, lenguajes de programación y estándares concretos que establecen las reglas para usarlo. Una máquina interesada en consumir este servicio Web ha de conocer la interfaz y adherirse a estas reglas para poder establecer la comunicación (Véase [20]) XML eXtensible Markup Language, al igual que JSON es un lenguaje cuya función es la de codificar objetos en forma de texto plano para su posterior intercambio (Véase [21] y [22]) Tabla 5 – Definiciones, acrónimos y abreviaturas usados en la especificación de requisitos 3.1.4. Visión general del documento El punto de especificación de requisitos consta de 3 secciones:  La primera sección (sección actual) realiza una breve introducción al apartado de especificación de requisitos.   La segunda sección describe todos aquellos factores que afectan al producto y a sus requisitos. No se describen los requisitos, sino su contexto. Además proporciona una visión muy general del sistema.   Por último, la tercera sección contiene los requisitos a un nivel de detalle suficiente como para permitir a los diseñadores diseñar un sistema que satisfaga estos requisitos, y que permita al equipo de pruebas planificar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos.  Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 40 3.2. Descripción general Antes de detallar los requisitos del sistema, es importante hacer una descripción del sistema de alto nivel y analizar aquellos factores que afectan al producto y a sus requisitos. Esta sección incluye: perspectiva del producto, funciones del producto, características de los usuarios, restricciones y suposiciones. 3.2.1. Perspectiva del producto La aplicación móvil objetivo de este proyecto forma parte de un sistema mayor, el cual incluye una aplicación servidor que implementará una interfaz de servicios Web REST. Estos permitirán el intercambio de información con la aplicación móvil mediante ficheros JSON o XML. La información enviada, que puede incluir archivos multimedia como grabaciones de audio o imágenes, en la mayoría de los casos serán avisos de animales perdidos o encontrados, aunque podrá tratarse de otra información necesaria para el funcionamiento de la aplicación. Una vez enviada la información al servidor esta podrá ser guardada en una base de datos, y más tarde ser procesada. A su vez el servidor responderá a la aplicación móvil de la misma forma avisando al usuario a través del dispositivo móvil de si todo ha salido correctamente o no. En la figura 13 extraída de [23] se muestra la visión global del producto, y las interacciones entre la aplicación móvil Android y el servidor. Figura 13 – Perspectiva del producto 41 3.2.2. Funciones del producto (de la aplicación) La aplicación móvil permitirá a los usuarios:  Iniciar sesión en la aplicación.  Enviar un aviso pudiendo incluir información del animal, una imagen de este, una grabación de audio describiendo al animal y metadatos (fecha, hora, localización del dispositivo, y nombre de usuario).  Configurar la aplicación. Esto se muestra gráficamente en el diagrama de casos de uso de la figura 14. Figura 14 – Diagrama de casos de uso para la aplicación Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 48 También se ha decidido añadir un componente que centralice la configuración de la app de manera que en cualquier momento se encuentre disponible el valor actual de cualquier parámetro de configuración. Cuando cualquier otro componente necesite escribir o leer un valor de configuración accederá a través de este nuevo componente al que se ha llamado ConfigurationManager. Este componente en adición se encargará de que estos valores se escriban en un archivo de preferencias en el dispositivo para mantener los valores después de que la app se cierre. Además utilizaremos dos APIs de Google, una para obtener la localización del dispositivo, y otra para mostrarla en un mapa al usuario. La primera se trata de Google Play Services, que proporciona una serie de herramientas al desarrollador para obtener la localización del dispositivo, así como para gestionar y tratar de recuperarse de posibles errores en este proceso. Todas las llamadas a la API de Google Play Services se encontrarán en un componente al que se ha llamado GooglePlayManager. La segunda API de Google se trata de la API de Google Maps. Esta nos ofrece un componente visual con el mapa mundial de Google Maps. Sobre este componente se marcará la situación actual del dispositivo para mostrarla al usuario. Dado que toda la funcionalidad de esta API se centra en el componente visual, las llamadas a esta API se harán todas desde la interfaz. Todos estos componentes descritos, y las interacciones entre ellos se muestran en el diagrama de componentes en la figura 15. Figura 15 – Diagrama de componentes de la aplicación 49 4.3. Diseño por capas Como se ha indicado al principio de este capítulo, se ha optado por un diseño basado en capas. En este caso, la capa de interfaz será la encargada de interactuar con el usuario, la segunda, la capa de negocio incluirá la lógica interna de la aplicación y la capa de persistencia se encargará de interactuar directamente con los diferentes orígenes de datos utilizados en la aplicación. 4.3.1. Presentación Para diseñar la capa de presentación, se ha decidido crear una relación de prototipos para las diferentes interfaces de la app o mock-ups. Estos servirán de guía a la hora de definir en las interfaces dentro de la aplicación, aunque es posible que no se puedan seguir al pie de la letra pudiendo aparecer diversas limitaciones a la hora de adaptarse al entorno Android. La figura 16 muestra estos mock-ups. Figura 16 – Prototipos o Mock-Ups diseñados para la aplicación Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 50 El primer prototipo (arriba a la izquierda) muestra una pantalla en la que el usuario puede autenticarse o continuar usando la aplicación de manera anónima. Esta será la pantalla con la que arranque la aplicación. Seguidamente arriba a la derecha se muestra cómo será la interfaz para configurar la app. Por último las últimas cuatro pantallas serán las utilizadas para introducir y mostrar la información relativa al animal. La de arriba a la derecha permite introducir los rasgos del animal de manera manual. Estos rasgos se han definido anteriormente en el capítulo de especificación de requisitos. Esta pantalla se modificará dinámicamente según se vayan modificando los diferentes parámetros para mostrar los valores introducidos de forma visual. Esta pantalla ofrecerá acceso a las otras tres: La de abajo a la izquierda mostrará la ubicación obtenida por el dispositivo si hubiese una. La de abajo en el centro permitirá introducir la imagen del animal. La última, abajo a la derecha, será la que permita al usuario describir al animal mediante la grabación de un archivo de audio. 4.3.2. Negocio Seguidamente se presenta el diseño hecho para la capa de negocio. Cabe destacar que este diseño se ha separado en dos visiones, la visión estática, y la dinámica. La primera de ellas en forma de diagrama de clases muestra las diferentes entidades que forman parte de la aplicación con sus propiedades y métodos. Por otro lado la segunda mediante diagramas de secuencia se refleja la principal lógica interna de la aplicación. Visión estática Se han definido dos entidades para la aplicación Aviso y Usuario. En el diagrama de clases de la figura 17 se muestra la relación entre estas clases, sus propiedades y sus métodos de persistencia. A la hora de implementar, cada entidad se dividirá en dos clases. Las propiedades y métodos constructores, consultores y modificadores formarán parte de la clase de negocio de la entidad [24], y sus métodos de persistencia de su Objeto de Acceso a Datos (clase DAO) [25]. Los métodos constructores, modificadores, consultores, y métodos internos se han omitido por su trivialidad y en la implementación se podrán definir los que sean necesarios. Además los campos de tipo, especie, talla, color y temperamento codificarán en forma de entero los posibles valores para estos campos. La codificación utilizada se indica en la tabla 20. 51 Campo Código entero Significado Tipo 0 Perdido 1 Encontrado Especie 0 Perro 1 Gato Talla 0 Pequeño 1 Mediano 2 Grande Color 0 Claro 1 Punto medio 2 Oscuro Temperamento 0 Tímido 1 Social 2 Agresivo Tabla 20 – Significado de los posibles valores enteros para cada rasgo del animal Visión dinámica Para la visión dinámica de la capa de negocio se han diseñado diferentes diagramas de secuencia. En estos se muestra la mayoría de la lógica interna de la aplicación aunque con el objetivo de mantener los diagramas simples y legibles solo se han incluido los casos básicos en los que no hay ningún contratiempo. A la hora de implementar habrá que contemplar más casos y gestionar los posibles problemas y errores que puedan surgir. Cabe destacar que al terminar cada interacción con la aplicación en los diagramas se manda un mensaje a la interfaz llamado render. Este es un método ficticio que se ha creado para referirse a cualquier tipo de retroalimentación sobre los cambios realizados que haya que mostrar por la interfaz, desde posibles mensajes informativos o de error, hasta pasar a una nueva pantalla. Cuando a este método se le pasa un parámetro, se indica que la retroalimentación dependerá del valor de este parámetro. Figura 17 – Diagrama de clases de la aplicación Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 52 El primer diagrama de secuencia en la figura 18 se muestra el comportamiento interno de la aplicación para el log in o inicio de sesión. Seguidamente en las figuras 19 a 22 se muestran los diagramas de secuencia de las diferentes versiones de envío de aviso que se podrán hacer en la aplicación. Estos diagramas de secuencia se podrán combinar en función de la diferente información que haya introducido el usuario o la propia aplicación en el caso de la localización. Figura 18 – Diagrama de secuencia: Inicio de sesión Figura 19 – Diagrama de secuencia: Enviar aviso 53 Figura 20 – Diagrama de secuencia: Enviar imagen Figura 21 – Diagrama de secuencia: Enviar localización del dispositivo Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 54 Por último, se presentan el diagrama de secuencia para el grabador de audio (Figura 23) y la gestión de la configuración (Figura 24). Figura 22 – Diagrama de secuencia: Enviar grabación de audio Figura 23 – Diagrama de secuencia: Grabar audio 55 El diagrama de secuencia para la gestión de configuración es un diagrama genérico que representa lo que ocurre al modificar un parámetro de configuración. Esta genericidad aparece en paramView que se refiere al componente visual específico para modificar ese parámetro concreto, onViewEvent() es el evento que se crea al modificar el valor, setParam() y putType(“conf_param”, valor) donde “type” se refiere al tipo de datos del parámetro y “param” el nombre del parámetro. Este diagrama se muestra en la figura 24. Además conviene recordar que los parámetros configurables no quedaban especificados en el capítulo anterior. Por ello conviene definirlos antes de seguir adelante. En la tabla 21 se muestran los parámetros elegidos, su tipo, sus posibles valores y el motivo por los que se han escogido. Parámetro Tipo Posibles valores Motivo Reducir tamaño de imágenes enviadas Booleano Si/No (True/False) Pueden existir usuarios que no quieran hacer uso excesivo de su plan de datos por lo que se permitirá reducir las imágenes antes de ser enviadas URL del servidor URL Infinitos Este parámetro se añade para facilitar la tarea del desarrollo y testeo de la aplicación. No se mostrará al usuario final Color de la interfaz Color Naranja, rojo, azul y violeta Esto permitirá al usuario elegir el color de la interfaz permitiéndole así que se sienta más cómodo con esta. Tabla 21 – Parámetros configurables en la aplicación Figura 24 – Diagrama de secuencia: Cambiar parámetro configurable Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 56 4.3.3. Persistencia Por último para la capa de persistencia se ha hecho una propuesta de interfaz de servicios Web REST. Dado que esta interfaz ha de estar aceptada por el equipo a cargo del desarrollo del servidor, este diseño es el más proclive a sufrir cambios en el futuro. La interfaz propuesta en este trabajo se presenta en la tabla 22. Se ha utilizado JSON para los mensajes al estar más familiarizado con este lenguaje. Servicio Web Descripción Entrada (JSON) Salida (JSON) Conexión El servidor web recuperará el registro asociado al usuario y devolverá true si la contraseña es igual. Si no lo es o si no se encuentra el usuario se devuelve false. {“Usuario”: { “username”: string, “password”: string } } {“resultado”: boolean} Enviar Aviso El servidor guardará el aviso siendo todos los campos opcionales. Si no hay ningún error {“Aviso”: { “tipo”: integer, “especie”: integer, “talla”: integer, “color”: integer, “temperamento”: integer, “latitud”: double, “longitud”: double, “audio”: base64-blob, “imagen”: base64-blob, “usuario”: Usuario } } {“resultado”: boolean} Tabla 22 – Definición de los servicios web REST y de la estructura de los mensajes JSON 4.4. Conclusiones En este capítulo se ha mostrado el trabajo realizado en cuanto al diseño de la aplicación se refiere. Este diseño, primero introducido de forma global, después desglosado según el enfoque clásico de capas de presentación, negocio y persistencia establecen una base y una guía sobre la cual implementar la aplicación de manera consistente. 57 5. Implementación y Pruebas 5.1. Introducción Una vez presentado el diseño para la aplicación Android objetivo de este proyecto, el siguiente paso es implementar la aplicación a partir de este diseño. En el presente capítulo se tratarán todas las cuestiones relacionadas con la implementación realizada. En el segundo apartado se mostrará cómo se ha implementado la app Android. Se tratará en primer lugar el código Java que da cuerpo a la aplicación para pasar después a introducir lo que en este trabajo se ha llamado recursos estáticos de la aplicación que no es más que diferentes elementos predefinidos generalmente en ficheros XML y a los que la aplicación tiene acceso. En adición se ha implementado un servidor en PHP con la interfaz de servicios Web propuesta en el capítulo de diseño y que hará de soporte para la aplicación Android. Este servidor se tratará en el tercer apartado de este capítulo. Por último en el cuarto capítulo la aplicación será puesta a prueba con motivo de comprobar que la aplicación funciona correctamente y además se adecua a los requisitos establecidos para la aplicación. 5.2. Aplicación Android La implementación de la app se ha estructurado en diferentes paquetes Java de manera que el código está mejor organizado y es más fácil de encontrar en todo momento el archivo que sea necesario. Como todo proyecto Android, este está separado en dos directorios principales: src, el cual contiene el código fuente en java de la aplicación y res, con ficheros XML que definen las interfaces de la app, estructura de los menús, valores enteros y textuales estáticos, así como estilos utilizados en las interfaces. 5.2.1. Código El directorio src es el que alberga la estructura en paquetes del proyecto. Todos y cada uno de estos paquetes cuelgan de es.upv.inf.animales, por lo que cuando hablemos de uno de estos paquetes, por simplicidad no se dirá, por ejemplo “es.upv.inf.animales.usuarios”, si no “el paquete usuarios” directamente. En la tabla 23 se muestran los diferentes paquetes definidos y una breve descripción de su contenido y en la figura 25 se puede ver todo el contenido de src. Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 64 5.2.2. Recursos estáticos e interfaces Los recursos estáticos que se guardan en la carpeta res del proyecto, como su nombre indica son elementos que no cambian. Si no se vuelve a compilar la aplicación, estos mantendrán su valor. Estos están definidos en ficheros XML de Android en su mayoría, aunque también algunos de ellos son imágenes con formato PNG. Concretamente los que se encuentra dentro de los ficheros XML pueden ser números, cadenas de caracteres, definiciones de estilos, de interfaces, y de partes de interfaces. En las figuras 28 y 29 se muestra gran parte de la estructura de res. La gran ventaja de guardar en ficheros separados toda esta información es la adaptabilidad de la app: por ejemplo las cadenas de caracteres se almacenan todas en el archivo values/strings.xml, para los valores en inglés, o values-es/strings.xml para los valores en español, etc. El entorno Android se encargará durante la ejecución de cargar el fichero strings.xml adecuado según el lenguaje del dispositivo. De la misma forma se pueden definir distintas interfaces o estilos para las distintas orientaciones de la pantalla o para las distintas versiones de Android. Figura 28 – Carpeta res (1/2) 65 En este proyecto, una gran cantidad de los recursos se encuentran externalizados de esta manera, y se han aprovechado en gran medida estas posibilidades. A pesar de ello, la aplicación solo contiene los valores en castellano. Seguidamente se hablará de las distintas interfaces definidas durante el desarrollo de esta aplicación. Interfaces De entre todos los recursos estáticos antes mencionados posiblemente las interfaces de usuario se traten de los más importantes, extensos, y los que más tiempo han necesitado para su creación. Desde el principio del desarrollo se ha seguido una misma guía: se han tomado los elementos y controles Android existentes, y se han personalizado dándoles formas redondeadas y colores claros, de manera que la interfaz no es demasiado agresiva para el usuario, pero en cierto modo se mantiene nativa a Android. Los colores utilizados en la aplicación han sido definidos en el fichero colors.xml. Una gran variedad de colores y tonalidades se han incluido en este fichero, para poder cambiar de uno a otro fácilmente a la hora de encontrar la mejor opción. De entre todos, dos colores principales se han utilizado: el naranja y el verde. El naranja, primero por sí mismo, más tarde en combinación con el blanco, formando un gradiente vertical naranja-blanco-naranja (horizontal para la orientación horizontal del dispositivo), es utilizado de fondo en toda la aplicación. Más tarde, este mismo gradiente se ha creado en otros tres distintos colores (con blanco) para permitir al usuario elegir el que prefiera. El verde, ha sido utilizado como contenedor para los elementos manipulables de la interfaz, resaltándolos así del fondo naranja. Estos contenedores verdes son rectángulos con las esquinas redondeadas, que se adaptan al tamaño de los elementos que albergan y diferentes versiones de ellos están definidos en ficheros XML cuyo nombre empieza por border. Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 66 El principal llamado border, toma distintos colores dependiendo de su estado. Normalmente es verde claro, cuando se pulsa es verde más oscuro, y si está deshabilitado (o seleccionado) en azul. En algunas situaciones se ha utilizado una variante blanca definida en border_white, por ejemplo, en los campos de introducción de texto. Por último, se ha definido una última versión siempre verde para la barra de opciones (ActionBar) definida en border_actionbar. Para los colores del texto, inicialmente se utilizó el negro, en un segundo momento el blanco, pero la versión definitiva es en blanco con un fino borde negro para que resalte sobre el fondo verde. Esto está definido en el fichero styles.xml. Seguidamente se tratará una a una las distintas interfaces y sus distintas versiones durante el proceso de desarrollo. Interfaz de arranque de la aplicación La pantalla de arranque que se muestra cada vez que la aplicación arranca dispone de una interfaz que únicamente tiene el icono de la aplicación sobre el fondo que se esté usando. Aunque no contiene ningún elemento manipulable, mediante código se ha hecho que al tocar cualquier punto, esta pantalla se desvanezca. Su definición se encuentra en el fichero activity_splash.xml. Esta interfaz se muestra en la figura 30. Figura 29 – Carpeta res (2/2) 67 Interfaz de inicio de sesión Para la interfaz de la pantalla de inicio de sesión se han definido dos partes, la primera con los campos de texto para que el usuario introduzca su nombre de usuario y contraseña, la segunda con dos botones, uno para autenticarse en el servidor y otro para saltarse esta pantalla sin autenticarse. Estos elementos se han definido por un lado en el fichero layout/activity_login.xml con la primera parte encima de la otra para cuando la orientación de la pantalla es vertical (Figura 31). Por otro lado, se ha redefinido en el fichero layout-land/activity_login.xml con la primera parte a la izquierda, y la segunda a la derecha para aprovechar mejor el espacio cuando el dispositivo está en orientación horizontal (Figura 32). Figura 30 – Interfaz de arranque Figura 31 – Interfaz de inicio de sesión (Orientación vertical) Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 68 Interfaz de configuración La interfaz de configuración reúne los componentes necesarios para que el usuario pueda configurar a su gusto la aplicación. En primer lugar se encuentran cuatro rectángulos cada uno de un color para elegir el fondo de la aplicación. Estos rectángulos se tratan de contenedores de imágenes (ImageView) cuya imagen es un elemento border del color correspondiente. Aunque no se aprecie visualmente, el color seleccionado se encuentra deshabilitado para que no se ejecute el código que cambia el color por el color actual. Esto no es importante porque el usuario puede ver el color actual en el fondo. En segundo lugar se encuentra un componente para introducir texto cuyo fin es introducir la URL del servidor. Este componente no se mostrará al usuario final, pero durante el transcurso de este trabajo, es conveniente su aparición por la flexibilidad que da durante todo el proceso. Por último aparece un checkbox (un componente visual que permite indicar un valor verdadero o falso), permite decidir si las imágenes serán reducidas para los envíos o no, para aquellos usuarios que no quieran usar en exceso su plan de datos. Un texto explicativo a la izquierda del checkbox indica al usuario la función de este. Esta interfaz se muestra en la Figura 33. Figura 32 – Interfaz de inicio de sesión (Orientación Horizontal) Figura 33 – Interfaz de configuración 69 Interfaz de envío de avisos En esta interfaz cada sección utiliza su propio diseño como se aprecia en la figura 34. La primera, a la izquierda, utiliza seek bars para definir al animal, y diferentes elementos visuales para mostrar los cambios al usuario. Al ser una sección con mucha información no toda cabe en la pantalla por lo que se han habilitado barras de desplazamiento. La segunda, en el centro, es un cuadro para mostrar la foto seleccionada (en blanco si no hay ninguna) que se expande lo máximo posible, con dos botones debajo para elegir una imagen de la galería o tomar una con la cámara. La tercera, a la derecha, es un mapa de Google Maps que de la misma forma, también se expande lo máximo posible. Además se definió una versión alternativa para cuando el dispositivo se encuentra en posición horizontal. Esta tiene los tres botones para elegir sección a la izquierda, el de enviar a la derecha, con una imagen de enviar en vez de texto. En medio se muestra el fragmento elegido. Cabe destacar que los botones de las secciones así como el de enviar para la versión horizontal, toman las imágenes del sistema operativo, así que dependiendo de la versión de Android, la imagen puede cambiar. Esta versión alternativa se puede ver en la figura 35. Figura 34 – Interfaces de envío de aviso (Orientación vertical) Figura 35 – Interfaz de envío de aviso (Orientación Horizontal) Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 70 En cuanto a la barra de herramientas, utiliza una forma border, y muestra el icono de la aplicación, el nombre de usuario actual o “No registrado” y las opciones disponibles. Las opciones, definidas aparte en el fichero menu/fragmented_activity_aviso.xml, son gestionadas por el sistema operativo, y pueden aparecer con icono y texto, solo con icono, u ocultas en un menú de más opciones, en función del espacio disponible. Interfaz de grabación de audio Esta interfaz está compuesta únicamente por un botón con un micrófono dibujado y un sencillo texto explicativo. Este texto inicialmente indica que para empezar a grabar hay que pulsar el botón mientras que durante la grabación, este texto cambiará a “Grabando…”. Al tener pocos componentes, solo se ha definido una única interfaz (figura 36) para ambas orientaciones del dispositivo. 5.3. Sistema soporte de la aplicación En el capítulo de Especificación de requisitos se destacaba que una de las suposiciones que se hacían para este proyecto era la de disponer de la implementación de una interfaz de servicios web REST albergada en un servidor. La función a grandes rasgos de este servidor es la de actuar como persistencia de la aplicación Android, y además procesar y cotejar la información recibida con la existente para encontrar avisos similares. Figura 36 – Interfaz de grabación de audio 71 Durante el transcurso de este TFG esta suposición no se ha cumplido, así que para poder seguir con el trabajo, además de la aplicación Android se ha implementado un servidor web con la interfaz web propuesta en el capítulo de diseño, y la base de datos correspondiente. Es importante hacer notar que el servidor web no es el objetivo de este trabajo, de manera que no se ha invertido un tiempo excesivo en él, y no incluye ni procesamiento, ni cotejamiento ni cuestiones de seguridad, sino que actúa como sistema de soporte para que la aplicación Android pueda funcionar. Tanto los servicios web como la base de datos se encuentran albergados en un servidor web MAMP (servidor para el sistema Mac OS X, y que dispone de los componentes Apache, MySQL y PHP/Perl/Python, véase [28]), y la aplicación Android accede a él mediante la IP del ordenador, que no es fija, y depende de la red que compartan los dos dispositivos. 5.3.1. Servicios Web Implementados Para implementar los servicios web se ha utilizado CakePHP, un Framework para el desarrollo rápido de aplicaciones web en PHP (Véase [28], [29], [30], [31], [32], [38], [39] y [40]) que permite la creación de aplicaciones web en general con apenas unas cuantas líneas de código. Se han implementado los dos servicios web propuestos en el capítulo de diseño. En la tabla 25 se muestra la ruta relativa para acceder a cada servicio web, con ejemplos de archivo JSON para la petición y para la respuesta. El primero, permite que la aplicación autentique al usuario. Cuando la aplicación envía el nombre de usuario y contraseña introducidos, el servidor recupera de la base de datos la información del usuario en cuestión. Si la contraseña almacenada no fuese la misma que la que la app ha enviado, o si no se encontrase al usuario en la base de datos, se responde con un mensaje JSON negativo indicando que hay algún problema (false). En caso contrario se envía un mensaje afirmativo (true). Además se actualizará el campo modificado de la base de datos con la fecha y hora actual del servidor (esta es la fecha de última conexión). El segundo añade la posibilidad de enviar avisos y almacenarlo en el servidor. Cuando un aviso es enviado, la información se extrae del mensaje y cada dato se almacena en su correspondiente campo de la base de datos. Hay una excepción en esto: el nombre de usuario del usuario que envía el aviso es sustituido por su id en la base de datos de usuarios. En el caso de que esto no se pueda hacer, ningún id es insertado, pero la tabla de avisos tiene un valor por defecto para el id del usuario correspondiente al usuario anónimo o no registrado. Además el campo creado se actualiza con la fecha y hora actual del servidor. Si todo sale bien se envía una respuesta afirmativa, en caso contrario se responde negativamente. Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 72 Servicio Web Ruta Entrada Salida Conexión /usuarios/conexion {“Usuario”: { “username”: alsanqui, “password”: animales } } {“resultado”: “true”} Enviar Aviso /animales/insertar {“Aviso”: { “tipo”: 0, “especie”: 1, “talla”: 2, “color”: 0, “temperamento”: 1, “latitud”: 39.4739020, “longitud”: -0.3492620, “usuario”: {“Usuario”: { “username”: alsanqui } } } } {“resultado”: “false”} Tabla 25 – Servicios Web REST implementados y ejemplos de mensajes JSON 5.3.2. Base de datos Para poder almacenar toda la información recibida en el servidor, el sistema de gestión de bases de datos es un componente imprescindible. En este caso para gestionar las bases de datos se ha utilizado MySQL (véase [33] y [41]), un sistema de código abierto bastante extendido en el mundo de las aplicaciones web y que viene incluido en el paquete MAMP mencionado al principio de este apartado. Mediante este sistema, se ha creado una base de datos para la aplicación llamada Animales con una versión simplificada del diagrama de clases mostrado en el capítulo de análisis dado que el cotejamiento no se ha implementado (Figura 37). Como se aprecia, se han definido dos tablas, avisos y usuarios, teniendo la primera una clave ajena a la segunda mediante el campo usuario_id que indica el usuario que ha añadido el aviso. Figura 37 – Tablas de la base de datos 73 5.4. Pruebas Una vez implementado todo, el siguiente paso es asegurarse de que se cumplen los requisitos funcionales definidos en el capítulo de especificación de requisitos. Para ello se han definido una serie de pruebas que tendrán uno o más requisitos funcionales asociados, y con distintos condiciones iniciales. Al realizarlas sobre la aplicación, ofrecerán unos resultados que habrá que comparar con lo que se espera que ocurra. De esta manera es posible cerciorarse que la aplicación funciona correctamente. Estas pruebas se han separado en función de la característica a la que están asociadas. 5.4.1. Gestión de usuarios Prueba PU01 Descripción Entrar sin autenticación Casos de uso asociados RF01 Condiciones iniciales - Resultado obtenido La pantalla para enviar avisos se muestra indicando “No registrado” en la barra superior. Tabla 26 – Prueba realizada: Gestión de usuarios 1 Prueba PU02 Descripción Iniciar sesión Casos de uso asociados RF01 Condiciones iniciales Usuario no existe Resultado obtenido Se muestra un mensaje de error en pantalla, y no se muestra la pantalla de envío de avisos. Tabla 27 – Prueba realizada: Gestión de usuarios 2 Prueba PU03 Descripción Conexión Casos de uso asociados RF01 Condiciones iniciales El usuario existe pero la contraseña es errónea Resultado obtenido Se muestra un mensaje de error en pantalla, y no se muestra la pantalla de envío de avisos Tabla 28 – Prueba realizada: Gestión de usuarios 3 Prueba PU04 Descripción Conexión Casos de uso asociados RF01 Condiciones iniciales El usuario existe y la contraseña es correcta Resultado obtenido La pantalla para enviar avisos se muestra indicando el nombre de usuario en la barra superior Tabla 29 – Prueba Realizada: Gestión de usuarios 4 Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 80 Bibliografía [1] Wikimedia. Android (Operating System), 2015 [en línea]. Wikipedia, The Free Encyclopedia [fecha de consulta: 22 de julio de 2015]. Disponible en https://en.wikipedia.org/wiki/Android_(operating_system) [2] Simplifica Software. Animales Sin Hogar, 2012 [en línea]. Google Play [fecha de consulta: 21 de febrero de 2015]. Disponible en https://play.google.com/store/apps/ details?id=com.simplifica.ash.dashboardash [3] Alzago Soluciones Tecnológicas S.L. Alerta Animal, 2014 [en línea]. Google Play [fecha de consulta: 21 de febrero de 2015]. Disponible en https://play.google.com/store/apps/ details?id=com.alzago.alertaanimal [4] PetFinder.my and KindMeal.my Team. PetFinder.my, 2013 [en línea]. Google Play [fecha de consulta: 21 de febrero de 2015]. Disponible en https://play.google.com/store/apps/ details?id=com.petfinder.andykoh [5] Goddard Information Systems. HeLP Lost and Adoptable Pets, 2014 [en línea]. Google Play [fecha de consulta: 21 de febrero de 2015]. Disponible en https://play.google.com/store/apps/ details?id=com.helpinglostpets.colin [6] Larry Colett. Charleston Animal Society, 2012 [en línea]. Google Play [fecha de consulta: 21 de febrero de 2015]. Disponible en https://play.google.com/store/apps/details ?id=com.app_chasanimal.layout [7] Alconsoft Panama. Callejerito Help!, 2014 [en línea]. Google Play [fecha de consulta: 21 de febrero de 2015]. Disponible en https://play.google.com/store/apps/details?id=com.alchesoft. callejerohelp [8] Bukosabino. Guau! qué perros, 2015 [en línea]. Google Play [fecha de consulta: 21 de febrero de 2015]. Disponible en https://play.google.com/store/apps/details?id=com.ionicframe work.buscaperrocliente620403 [9] Javier Porto. Encuéntralos, 2014 [en línea]. Google Play [fecha de consulta: 21 de febrero de 2015]. Disponible en https://play.google.com/store/apps/details?id=com.ayudaaencontrarlos. encuentralos [10] Magma. Find My Pet, 2014 [en línea]. Google Play [fecha de consulta: 21 de febrero de 2015]. Disponible en https://play.google.com/store/apps/details?id=myapp.magma.findmypet [11] Creativity Apps. Pet Finder, 2015 [en línea]. Google Play [fecha de consulta: 21 de febrero de 2015]. Disponible en https://play.google.com/store/apps/details?id=co.creativityapps.petfin der [12] petsearch. Pet Search, 2014 [en línea]. Google Play [fecha de consulta: 21 de febrero de 2015]. Disponible en https://play.google.com/store/apps/details?id=com.appbuilder.u501565p78 1228 81 [13] Michael Hasibo. IcPet – Report/Find Lost Pets, 2015 [en línea]. Google Play [fecha de consulta: 21 de febrero de 2015]. Disponible en https://play.google.com/store/apps/details?id= com.hasiboapps.icpet [14] Wikimedia. Global Android version distribution since December 2009, 2015 [en línea]. Wikipedia, The Free Encyclopedia [fecha de consulta: 21 de junio de 2015]. Disponible en https://en.wikipedia.org/wiki/Android_version_history#/media/File:Android_historical_ver sion_distribution_-_vector.svg [15] Wikimedia. Dimensionality Reduction, 2015 [en línea]. Wikipedia, The Free Encyclopedia [fecha de consulta: 22 de julio de 2015]. Disponible en https://en.wikipedia.org/wiki/Dimensionality_reduction [16] The Institute of Electrical and Electronics Engineers, Inc. IEEE Recommended Practice for Software Requirements Specifications, 1998 [en línea]. University of Alaska Anchorage [fecha de consulta: 10 de marzo de 2015]. Disponible en http://www.math.uaa.alaska.edu/ ~afkjm/cs401/IEEE830.pdf [17] Wikimedia. Hypertext Transfer Protocol, 2015 [en línea]. Wikipedia, The Free Encyclopedia [fecha de consulta: 22 de julio de 2015]. Disponible en https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol [18] Wikimedia. JSON, 2015 [en línea]. Wikipedia, The Free Encyclopedia [fecha de consulta: 22 de julio de 2015]. Disponible en https://en.wikipedia.org/wiki/JSON [19] Wikimedia. Representational State Transfer, 2015 [en línea]. Wikipedia, The Free Encyclopedia [fecha de consulta: 22 de julio de 2015]. Disponible en https://en.wikipedia.org/wiki/Representational_state_transfer [20] Wikimedia. Web Service, 2015 [en línea]. Wikipedia, The Free Encyclopedia [fecha de consulta: 22 de julio de 2015]. Disponible en https://en.wikipedia.org/wiki/Web_service [21] Wikimedia. XML, 2015 [en línea]. Wikipedia, The Free Encyclopedia [fecha de consulta: 22 de julio de 2015]. Disponible en https://en.wikipedia.org/wiki/XML [22] World Wide Web Consortium. XML, 2015 [en línea]. World Wide Web Consortium [fecha de consulta: 22 de julio de 2015]. Disponible en http://www.w3.org/XML/ [23] Garrote-Hildebrand, D., Poza-Lujan, J. L., Posadas-Yagüe, J. L., Simó-Ten, J. E., JiménezGarcía, J. L. Distributed System for Intelligent Management of Lost or Abandoned Pets, 2014 [en línea]. Universitat Politècnica de València [fecha de consulta: 19 de febrero de 2015]. Disponible en http://wks.gii.upv.es/cobami/files/IJIR-R-AIR-3.pdf [24] Wikimedia. Business Object, 2015 [en línea]. Wikipedia, The Free Encyclopedia [fecha de consulta: 22 de julio de 2015]. Disponible en https://en.wikipedia.org/wiki/Business_object [25] Wikimedia. Data Access Object, 2015 [en línea]. Wikipedia, The Free Encyclopedia [fecha de consulta: 22 de julio de 2015]. Disponible en https://en.wikipedia.org/wiki/Data_access_object [26] Santiago Lezica. Writing Splash Screens The Right Way, 2012 [en línea]. blogActivity; [fecha de consulta: 22 de julio de 2015]. Disponible en https://blogactivity.wordpress.com/2012/02/24/writing-splash-screens-the-right-way/ Desarrollo de una aplicación móvil en Android para un sistema de aviso y localización de animales perdidos 82 [27] Wikimedia. Singleton Pattern, 2015 [en línea]. Wikipedia, The Free Encyclopedia [fecha de consulta: 22 de julio de 2015]. Disponible en https://en.wikipedia.org/wiki/Singleton_pattern [28] Wikimedia. MAMP, 2015 [en línea]. Wikipedia, The Free Encyclopedia [fecha de consulta: 22 de julio de 2015]. Disponible en https://en.wikipedia.org/wiki/MAMP [29] Wikimedia. CakePHP, 2015 [en línea]. Wikipedia, The Free Encyclopedia [fecha de consulta: 22 de julio de 2015]. Disponible en https://en.wikipedia.org/wiki/CakePHP [30] CakePHP. CakePHP Cookbook, 2015 [en línea]. CakePHP [fecha de consulta: 22 de julio de 2015]. Disponible en http://book.cakephp.org/3.0/_downloads/en/CakePHPCookbook.pdf [31] Wikimedia. PHP, 2015 [en línea]. Wikipedia, The Free Encyclopedia [fecha de consulta: 22 de julio de 2015]. Disponible en https://en.wikipedia.org/wiki/PHP [32] Seralo. PHP Frameworks comparison, 2010 [en línea]. Social Compare, Collaborative Comparison Engine [fecha de consulta: 22 de julio de 2015]. Disponible en http://socialcompare.com/en/comparison/php-frameworks-comparison [33] Wikimedia. MySQL, 2015 [en línea]. Wikipedia, The Free Encyclopedia [fecha de consulta: 22 de julio de 2015]. Disponible en https://en.wikipedia.org/wiki/MySQL 83 Enlaces adicionales [34] Android Reference: http://developer.android.com/reference/packages.html [35] Stack Overflow – Android: http://stackoverflow.com/questions/tagged/android [36] The New Boston – Android Application Development Tutorial: https://www.youtube.com/watch?v=SUOWNXGRc6g&list=PL33384E9848C4F55E [37] MAMP: https://www.mamp.info/en/ [38] CakePHP: http://cakephp.org/ [39] The New Boston – Beginner PHP Tutorial: https://www.youtube.com/watch?v=iCUV3iv9xOs&list=PL442FA2C127377F07 [40] w3schools.com – PHP: http://www.w3schools.com/php/php_intro.asp [41] MySQL: https://www.mysql.com/