Repositorio Institucional de Documentos

Proyecto Fin de Carrera - Ingeniería en Informática - Febrero de 2012 Aplicación móvil Android para cuadernos de viaje turísticos sincronizada con plataforma web Autor: Sergio Martínez Rodríguez Director: José Cascán Fernández Ponente: Pedro Muro Medrano Agradecimientos: A IAAA, por darme la oportunidad de desarrollar este proyecto y brindarme todo lo necesario, así como un pequeño hueco en el grupo, que ha hecho posible la realización del mismo en un ambiente idóneo para ello. En especial a José y Rodolfo, quienes me han iluminado durante todo este camino. A mis compañeros del IAAA, porque han hecho mucho más llevadero y ameno el tiempo que llevo dentro del grupo. A mi familia, por haberme dado la oportunidad de llegar hasta este punto de mi vida, por su bendita paciencia y por haberme enseñado a no rendirme jamás ante cualquier adversidad. Y a Ester, por haber sido la mejor compañera durante todo este tiempo. Aplicación móvil Android para cuadernos de viaje turísticos sincronizada con plataforma web RESUMEN GeoSisTur es una plataforma de promoción turística que permite dinamizar un destino utilizando las tecnologías sociales y la optimización del proceso de gestión de contenidos. Está pensada para satisfacer todas las necesidades que engloba el descubrimien- to de un nuevo destino: conocer el lugar a través de diferentes elementos multimedia informativos que impacten en la consciencia del usuario; presentación de los productos turísticos que se pueden disfrutar (qué hacer, comer y beber, itinerarios, etc); organizar la visita utilizando una agenda de viaje donde anotar la planicación decidida; y, tras el viaje, inclusión de comentarios y opiniones en el área de comunidad para que futuros turistas dispongan de información de otros usuarios que han visitado el lugar con anterioridad. El trabajo realizado en este Proyecto Fin de Carrera tiene como objetivo principal el desarollo de una aplicación para dispositivos móviles con sistema operativo Android, dedicada a la gestión y planicación de viajes a partir de lo que hemos llamado cuadernos de viaje, basados en el módulo homónimo de GeoSisTur. En un cuaderno de viaje, el usuario recopilará información sobre un viaje concreto antes, durante o después del periodo que dure dicho viaje. El usuario será capaz de obtener y gestionar desde recursos multimedia, como fotos y videos, hasta recursos turísticos o POI's que ha visitado. Se ha conseguido desarrollar la aplicación móvil evitando la dependencia total de una conexión a Internet con el n de conseguir la máxima funcionalidad en cualquier momento y lugar en el tiempo. Por último, estando la aplicación móvil respaldada por la plataforma web turística GeoSisTur permite el intercambio de contenido entre la plataforma web y el dispositivo móvil. Las tareas necesarias para la obtención de dicha aplicación móvil han sido las tradicionales en un proyecto software, es decir, la determinación de los requisitos que deberán cumplirse, el análisis y el diseño de la propia aplicación, la implementación de las soluciones diseñadas, y la integración nal de los componentes. Índice general I Memoria 1 1. Introducción 2 1.1. Contexto profesional . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Contexto tecnológico . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1. Android .............................. 3 1.2.2. XML................................ 5 1.2.3. SQLiteyORMlite ........................ 6 1.2.4. ServiciosWeb........................... 6 1.2.5. JSONyGSON .......................... 6 1.3. Motivación y objetivos del proyecto . . . . . . . . . . . . . . . . . . . 7 1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Trabajo realizado: Travel Blog 11 2.1. Situación previa y estudio de mercado . . . . . . . . . . . . . . . . . 11 2.1.1. TouristEye ............................ 12 2.1.2. TripJournal............................ 12 2.2. Análisis de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.1. Denición de cuaderno de viaje . . . . . . . . . . . . . . . . . 13 2.2.2. Determinación de requisitos . . . . . . . . . . . . . . . . . . . 13 2.3. Diseño de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.1. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . 14 2.3.2. Modelodedatos ......................... 16 2.4. Metodología de creación de una aplicación móvil Android . . . . . . . 17 2.4.1. Diseño gráco de la ventana . . . . . . . . . . . . . . . . . . . 18 2.4.2. Análisis, obtención y muestra de la información . . . . . . . . 20 2.4.3. Dotación de interacción . . . . . . . . . . . . . . . . . . . . . . 23 2.4.4. Pruebas de integración en la aplicación . . . . . . . . . . . . . 26 2.5. Decisiones de diseño adoptadas . . . . . . . . . . . . . . . . . . . . . 27 2.5.1. Representación de la información . . . . . . . . . . . . . . . . 27 2.5.2. Calendario............................. 28 2.5.3. Visordemapas.......................... 30 2.5.4. Elementos multimedia . . . . . . . . . . . . . . . . . . . . . . 32 2.5.5. Comunicación con GeoSisTur . . . . . . . . . . . . . . . . . . 33 ÍNDICE GENERAL vi 3. Conclusiones 35 3.1. Resultados Obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2. LíneasFuturas .............................. 35 3.3. ValoraciónPersonal............................ 36 II Anexos 38 A. Gestión del proyecto 39 A.1. Metodología de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . 39 A.2.Planicación................................ 40 A.3. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . 41 B. Análisis de Requisitos 43 B.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . 43 B.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . 45 C. Diseño y Modelo de datos 46 C.1. Diseño de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . 46 C.1.1. Prototipado de las ventanas de navegación . . . . . . . . . . . 46 C.1.2. Navegación de la aplicación . . . . . . . . . . . . . . . . . . . 47 C.2.Modelodedatos.............................. 47 D. Arquitectura del sistema 50 E. Manual de instrucciones Travel Blog 53 III Acrónimos, Figuras, Bibliografía 76 Acrónimos 77 Índice de guras 78 Bibliografía 79 Parte I Memoria Capítulo 1 Introducción El presente documento tiene como objetivo recoger toda la información relacionada con la realización de este Proyecto Fin de Carrera (PFC) titulado Aplicación móvil Android para cuadernos de viaje turísticos sincronizada con plataforma web . En este primer capítulo se dene el contexto, tanto profesional como tecnológico, en el que se ha desarrollado dicho proyecto. A continuación se exponen los objetivos planteados al principio del proyecto y la estructura en la que se organiza este documento. 1.1. Contexto profesional Este PFC se ha llevado a cabo en GeoSpatiumLab S.L. 1 , empresa especializada en el desarrollo de Sistemas de Información en los que la componente geográca resulta fundamental. GeoSpatiumLab surge como Spin-O de la Universidad de Zaragoza, entre cuyos objetivos está facilitar la transferencia de tecnología generada por el Grupo de Sistemas de Información Avanzados (IAAA), perteneciente al Departamento de Informática e Ingeniería de Sistemas. El Grupo de Sistemas de Información Avanzados es un grupo de I+D+i 2 de carácter multidisciplinar, pero con un marcado perl informático. Está adscrito al Instituto de Investigación en Ingeniería de Aragón (I3A) de la Universidad de Zaragoza, y además es Grupo de Investigación Consolidado reconocido por la DGA 3 (código T56). La actividad de investigación de este grupo está enfocada en las tecnologías de software abierto, distribuido e interoperable, para la creación de sistemas de información con datos georreferenciados (también denominados generalmente datos geográcos y ahora más comúnmente datos espaciales). El presente proyecto surge como una oportunidad de aplicar la tecnología desarrollada por las diferentes líneas de investigación del Grupo en un producto novedoso destinado a un sector en constante expansión como 1 http://www.geospatiumlab.es/ 2 Investigación, desarrollo e innovación 3 Diputación General de Aragón 1.2 Contexto tecnológico 3 es el turístico, y usando una tecnología en auge como es el desarrollo de aplicaciones móviles. 1.2. Contexto tecnológico Antes de profundizar en las cuestiones técnicas del proyecto, y para una mejor comprensión del desarrollo del mismo, es preciso presentar una breve descripción de las tecnologías y herramientas más importantes que han tenido cabida en la realización de este PFC. 1.2.1. Android Android 4 es un sistema operativo para dispositivos móviles tales como teléfonos inteligentes o tabletas. Está desarrollado por la Open Handset Alliance, una alianza comercial de 78 compañías tan importantes como Samsung, HTC, Dell, Intel, etc, para desarrollar estándares abiertos para dispositivos móviles, lideradas por Google. El sistema operativo Android se compone de aplicaciones que se ejecutan en un framework Java de aplicaciones orientadas a objetos, sobre el núcleo de las bibliotecas de Java en una máquina virtual Dalvik con compilación en tiempo de ejecución. Este sistema operativo contiene una base de datos relacional SQLite, de la que hablaremos más adelante. Java es un lenguaje de programación orientado a objetos, desarrollado por Sun Microsystems a principios de los años 90, y se trata del lenguaje utilizado para el desarrollo de aplicaciones para la plataforma Android. Además, Java es el lenguaje más popular en la comunidad de desarrolladores, por ello es una de las razones por las que el desarrollo de aplicaciones Android se ha puesto de moda en los últimos años. En Android, las aplicaciones desarrolladas para una versión concreta del sistema operativo son compatibles para dicha versión y para las posteriores. Es decir, a menor versión de la aplicación desarrollada, mayor será el número de dispositivos móviles con los que será compatible. La versión Android para móviles más avanzada al inicio del proyecto era la 2.3 (Gingerbread), pero como he comentado antes, el objetivo es llegar al máximo de dispositivos móviles, por lo que la versión elegida para el desarrollo del PFC es la 2.2 (Froyo). En la gura 1.1 se puede observar el porcentaje de uso para cada una de las versiones existentes en el momento del inicio del proyecto. Android ofrece una plataforma abierta de desarrollo, lo que proporciona a los programadores la capacidad de construir aplicaciones realmente interesantes e innovadoras. 4 http://www.android.com/ 1.4 Estructura del documento 10 • Anexo B. Análisis de requisitos. En este anexo se detalla en profundidad el conjunto de requisitos que se determinaron durante las labores de análisis. • Anexo C. Diseño y modelo de datos. En este anexo se detallan la fase de diseño y las decisiones en la organización de las entidades que forman el modelo de datos utilizado en el proyecto. • Anexo D. Arquitectura del sistema. En este anexo se recoge la arquitectura del sistema pensada para Travel Blog en detalle. • Anexo E. Manual de usuario de aplicación móvil Travel Blog. Una de las labores realizadas para la aplicación móvil desarrollada fue la confección de un manual de usuario. En este anexo se recoge dicho manual. Parte III. Acrónimos, Figuras y Bibliografía • Acrónimos • Índice de guras • Bibliografía Capítulo 2 Trabajo realizado: Travel Blog Este capítulo está dedicado a detallar todo el trabajo realizado a lo largo de este PFC. El nombre que se ha elegido para llamar a la aplicación que ha sido desarrollada durante el periodo que ha durado el PFC y a la cual se va a hacer referencia ha sido Travel Blog. A continuación, se muestra la situación previa desde donde parte el proyecto, así como un estudio sobre algunas aplicaciones ubicadas en el mismo ámbito que Travel Blog. Más tarde se explican cada una de las partes de las que consta la realización de un proyecto software, análisis, diseño e implementación, incluyendo la metodología que se ha aplicado para llegar a la elaboración de Travel Blog. 2.1. Situación previa y estudio de mercado En la empresa donde se ha desarrollado este PFC se cuenta con una plataforma web dedicada al turismo llamada GeoSisTur. Actualmente, una de las corrientes que existen en la actualidad tecnológica pretende llevar todo el contenido disponible en la web a la plataforma móvil. El módulo de cuadernos de viaje de GeoSisTur es uno de los contenidos que se desea importar al móvil, por ello se busca desarrollar una aplicación móvil, en principio para Android, que cumpla muchas de las funcionalidades del módulo, y además exista una comunicación entre la aplicación y la plataforma web. Como uno de los puntos fuertes del proyecto, y debido en gran parte a la poca disponibilidad de acceso a Internet mientras se viaja, ya sea por falta de cobertura o por tarifas desorbitadas, se pensó en que la aplicación tuviera la máxima funcionalidad en modo oine. Se buscaba crear una aplicación que disponga de unas cualidades de aspecto innovador y que fueran capaces de diferenciar la aplicación Travel Blog con otras ya existentes en el mercado. Precisamente por eso se analizaron también otras aplicaciones del mismo ámbito, la gestión y planicación de viajes por parte del usuario. 2.2 Análisis de la aplicación 12 2.1.1. Tourist Eye Tourist Eye 1 se trata de una aplicación móvil, que al igual que la que se desarrolla en este PFC, parte de complemento a un gran portal web turístico. El portal web es muy completo, y ofrece una gran cantidad de ventajas de cara al usuario para planicar su viaje. Aún así, usando la aplicación para Android, se puede ver que no han sabido llevar de una manera correcta el sistema creado en la web al móvil. Como ventajas, comentar que la aplicación da gran cantidad de información al usuario, y la interfaz es simple y sencilla. De otro modo, da la sensación de que el usuario dispone de poca libertad a la hora de crear lugares propios a compartir con el resto de la comunidad. Además, carece de un mapa global, algo que en la aplicación móvil a desarrollar se le ha dado una gran importancia. 2.1.2. Trip Journal Trip Journal 2 es una aplicación muy premiada en el área turística y que goza de gran prestigio. Visualmente es muy atractiva, con una interfaz muy cuidada y una navegabilidad agradable. Ofrece muchas de las funcionalidades denidas para este PFC. La gran diferencia radica en el modo de sincronización con Internet. Trip Journal carece de una plataforma web turística a modo de comunidad que la respalde, como son GeoSisTur o Tourist Eye, sin embargo, centra su atención en compartir la información creada por el usuario a través de otras plataformas sociales como Facebook, Picasa, Google Earth, etc. En la aplicación a desarrollar por el PFC, no se contempla este caso, pero es una idea muy atractiva para incluir en líneas futuras. Aparte, mencionar que dicha aplicación está disponible para las plataformas móviles más importantes del momento, Bada, iPhone, Symbian y Android, aunque también tiene el inconveniente de que se trata de una aplicación de pago. 2.2. Análisis de la aplicación En esta sección se presenta la fase de análisis, parte inicial de todo proyecto software, donde se presentan los requisitos, tanto funcionales como no funcionales de la aplicación móvil, así como una vista global de la arquitectura pensada para el sistema. 1 http://www.touristeye.es/ 2 http://www.trip-journal.com/ 2.2 Análisis de la aplicación 13 2.2.1. Denición de cuaderno de viaje Partiendo del análisis del módulo de mismo nombre de GeoSisTur, se puede denir un cuaderno de viaje como un diario o bitácora en el que el usuario puede relatar, día a día, sus experiencias vividas durante un viaje. Consta de un periodo acotado de acción, de una descripción (del diario completo) y de un conjunto de entradas para cada uno de los días del viaje, acompañadas de fotos, vídeos, recursos turísticos, etc., estos últimos con sus valoraciones y comentarios pertinentes. 2.2.2. Determinación de requisitos En primer lugar, como en cualquier proyecto software, se procede a determinar los requisitos que deberán satisfacer el sistema. Estos requisitos deberán ser cumplidos en su conjunto por la aplicación móvil, además, la aplicación desarrollada deberá cumplir el papel de aplicación base, sujeta a posibles cambios por parte del cliente. En este punto hay que resaltar que la aplicación va a ser un producto genérico concebido por la empresa con objeto de ser utilizada junto con GeoSisTur, plataforma dedicada a la construcción de portales turísticos , por lo que en la obtención de los requisitos no ha participado ningún cliente nal, sino que se han elaborado según un amplio concepto que se ha formado del producto. En el anexo Bse especican con mayor nivel de detalle los requisitos resumidos a continuación de la siguiente manera. Requisitos funcionales: Estos requisitos denen las acciones fundamentales que debe realizar el software al recibir información, procesarla y producir resultados. Funcionamiento oine. Gestión de cuadernos de viaje. Gestión de recursos turísticos. Gestión de recursos multimedia. Geolocalización de recursos. Localización de recursos en mapa de situación. Localización del usuario sobre el mapa. Visualización oine de una zona concreta del mapa. Visualización de contenido multimedia. Comentar y valorar recursos turísticos. 2.3 Diseño de la aplicación 14 Conexión con GeoSisTur. Búsqueda de contenido. Búsqueda de recursos turísticos. Búsqueda de lugares geográcos. Indicación de ruta desde origen hasta destino. Requisitos no funcionales: Los requisitos no funcionales marcan las características que debe poseer el sistema en cuanto a rendimiento, seguridad, portabilidad, y otros aspectos que no forman parte directamente del funcionamiento (entradas, procesamiento, salidas) del mismo. Estos requisitos son los siguientes: Creación de aplicación móvil para la plataforma Android de Google. Uso de tecnologías Open Source (Código Abierto) en el visor de mapas, concretamente OpenStreetMaps (OSM). Gestión y persistencia de objetos Java en base de datos SQLite a través de ORMLite. Conexión con servicios web externos mediante protocolo REST y formato de mensajes JSON. 2.3. Diseño de la aplicación Una vez denidos los requisitos que deberán cumplirse por la aplicación móvil, la siguiente tarea consiste en plantear el diseño de la solución. En primer lugar se presentará la visualización de la arquitectura del sistema a un nivel alto de abstracción, y a continuación se detallará el modelo de los datos utilizado. 2.3.1. Arquitectura del sistema El sistema está constituido por tres partes diferenciadas. La primera parte es la propia aplicación en sí, es decir, todo el código Java, clases, archivos de conguración, imágenes, etc, que forman el proyecto de programación. También se incluyen otras aplicaciones ya instaladas en el dispositivo móvil, como Gallery, Google Calendar o Camera. La segunda parte del sistema son las librerías externas a Android añadidas al proyecto, las cuales aportan nuevas herramientas al entorno de desarrollo. La tercera parte está constituida por las fuentes de datos en las que se apoya y se nutre la aplicación. Existen dos tipos de fuentes de datos: 2.3 Diseño de la aplicación 15 Internas: localizadas la propia memoria interna del dispositivo móvil, como la tarjeta de memoria SD 3 , donde se almacenan archivos tales como fotos, vídeos, rutas, etc, así como la base de datos SQLite, sistema de almacenamiento propio de Android y donde guardaremos todos los datos creados desde la aplicación. Externas: son todas aquellas fuentes de información ajenas al dispositivo móvil. La mayoría de ellas serán accesibles mediante servicios web, como el que mantendrá la comunicación con GeoSisTur, o como el que realiza la búsqueda de un lugar geográco a partir de una entrada de texto(Google Geocoding). A su vez, estas tres partes diferenciadas del sistema están comunicadas entre sí. La comunicación entre la capa de aplicación y la capa de librerías se realiza directamente o a través del Application Framework de Android. El Application Framework es la zona del sistema operativo donde se encuentran las herramientas que Android proporciona al desarrollador de aplicaciones. Se podría decir que esta zona de la arquitectura se encarga de la conexión entre la aplicación y el exterior. Alguna de las herramientas incluidas en el Application Framework se enumeran a continuación: Gestor de Activities. Sistema de Views. Gestor de recursos (iconos, audio, estilos, etc). Gestor de localización. Gestor de telefonía. La comunicación entre la capa de aplicación y las fuentes de datos va a depender del tipo de fuente de información. En el caso de las fuentes internas, la capa de aplicación utiliza librerías propias de Android o añadidas al proyecto para establecer la conexión. En el caso de las fuentes externas, la comunicación se establece mediante la red de datos disponible en el móvil. Se pueden ver los métodos de comunicación con las diferentes fuentes de datos en la sección 2.4.2. Esta breve introducción de la arquitectura del sistema que comprende este proyecto puede entenderse mejor observando la gura 2.1. En el anexo Bse especica con un mayor nivel de detalle la arquitectura del sistema, además de explicarse cada uno de los módulos de los que consta el sistema. 3 Secure Digital 2.3 Diseño de la aplicación 16 Figura 2.1: Arquitectura del sistema de la aplicación Travel Blog 2.3.2. Modelo de datos Tras la denición de un cuaderno de viaje, la fase de análisis en busca de los requisitos a cumplir por el sistema y el diseño de la arquitectura del sistema, es necesario denir la organización de las entidades que contienen la información. Por ello se dene el modelo de datos interno de la aplicación móvil. Lo primero es obtener cada una de las entidades que van a entrar en juego en el modelo de datos de la aplicación. Más tarde se denen las relaciónes existentes entre cada una de las entidades dentro del modelo de datos de la aplicación. Se puede ver el modelo de datos desarrollado entre las entidades obtenidas en la gura 2.2: Se puede observar que todo el contenido gira alrededor de la entidad entrada (Entry), cada una de las partes que forman un cuaderno de viaje (Travel Blog). Cada entrada aglutina la información recopilada en forma de los diferentes recursos, y forma parte un cuaderno de viaje. En el anexo Cse especica con un mayor nivel de detalle el modelo de los datos utilizado en el diseño de la aplicación, así como los métodos y atributos pertenecientes a cada entidad. 2.4 Metodología de creación de una aplicación móvil Android 17 Figura 2.2: Modelo de datos de la aplicación móvil Travel Blog 2.4. Metodología de creación de una aplicación móvil Android El desarrollo de la aplicación móvil se lleva el grueso del trabajo realizado durante el PFC. Antes de entrar en la metodología utilizada para el desarrollo de Travel Blog, mencionar que la fase a la que se relacion con el diseño gráco de la aplicación no podía ser realizada sin tener conocimiento alguno de los recursos grácos disponibles en Android. Por ello, en todo momento, la fase de implementación y de diseño gráco de la aplicación se han desarrollado a la par. Se iniciaron al mismo tiempo debido a que por la falta de conocimientos en programación de aplicaciones para móvil Android, antes de comenzar a diseñar partes de la aplicación que fueran inviables de llevar a cabo en la fase de desarrollo, se pensó en conocer las distintas opciones de diseño gráco que Android ofrecía. Una vez conocido lo básico de los recursos grácos proporcionados por el SDK 4 de Android, y tras diversos tests realizados modularmente con cada uno de ellos, se comenzó a diseñar una aproximación de interfaz gráca en base a lo que se había probado. En la gura 2.3 podemos ver alguna de las ventanas principales del diseño gráco de la aplicación. Además, contamos con la ventaja de que Android nos permite plasmar un diseño previo durante la fase de desarrollo de la aplicación, ya que cada una de las ventanas de navegación diseñadas se corresponden con una parte de código fuente 4 Software Development Kit 2.4 Metodología de creación de una aplicación móvil Android 18 independiente. Lo comentado anteriormente y otras muchas cualidades más de la organización de un proyecto Android, hacen que el desarrollo de aplicación se vuelva sencillo y modular. Por ello, la política de desarrollo de la aplicación que se ha seguido, se ha basado en la iteración de la siguiente metodología de programación para cada una de las ventanas de navegación obtenidas en la fase de diseño: Diseño gráco de la ventana mediante la edición del XML correspondiente y con la ayuda del asistente del entorno de programación. Análisis de la información necesaria a utilizar en dicha ventana de navegación, obtención y muestra de la misma. Dotación de interacción con el usuario a cada uno de los elementos grácos Android(botones, menú, barra de acción, etc). Pruebas de los distintos componentes de la aplicación. (a) Lista de cuadernos (b) Detalle de cuaderno (c) Galería multimedia Figura 2.3: Ventanas de la aplicación realizadas durante la fase de diseño 2.4.1. Diseño gráco de la ventana En una aplicación Android, la interfaz de usuario se construye a partir de objetos View o ViewGroup, grupo de varias Views. Estos objetos son las unidades básicas que conforman la interfaz de usuario en la plataforma Android. 2.4 Metodología de creación de una aplicación móvil Android 19 La clase View sirve como base para subclases llamadas widgets u objetos de la interfaz de usuario completamente implementados, como lo son botones o campos de texto. Mientras que la clase ViewGroup sirve como base para subclases llamadas layouts , que ofrecen diferentes tipos de estructura al diseño de la interfaz. Existen diferentes tipos de layouts como lineales, tabulares y relativos. Un objeto View es un elemento gráco de Android. Cada View tiene propiedades que almacenan parámetros de diseño y contenido para un área rectangular especíca de la pantalla. Algunos de estos parámetros pueden ser las dimensiones del objeto, el diseño, el estilo, posicionamiento respecto a otros Views, etc. Además, cada una de estas View hereda algún que otro parámetro del ViewGroup que lo contiene. Un objeto View es también un punto de interacción para el usuario y un receptor de eventos de interacción. En la sección 2.4.1 , donde se habla de la dotación de la interacción, comentaremos de manera general los eventos táctiles detectables y los correspondientes métodos de activación usados para crear la interacción deseada entre el usuario y la aplicación Android. El método más común de denir el diseño gráco y expresar la jerarquía de los elementos que forman la vista de nuestra aplicación es a través de archivos de diseño XML o layouts . Este archivo está compuesto por diferentes objetos View o ViewGroup formando una estructura que se puede entender como un árbol, donde las ramas son los objetos ViewGroup, y las hojas los objetos View. Todos en conjunto denen el aspecto gráco de una interfaz de la aplicación. En la fase de desarrollo de la aplicación de este PFC, cada uno de los archivos de diseño XML dene el diseño gráco de cada una de las ventanas de navegación obtenidas durante la fase de diseño. Aparte de denir el diseño de una ventana mediante archivos XML, existe otra manera de hacerlo. Esta manera consiste en denir directamente sobre el código fuente cada uno de los widgets a incluir en la interfaz. Es una forma menos intuitiva de diseñar interfaces, pero ofrece al programador una gran ventaja: dinamismo. Mientras que el archivo XML es un archivo estático, independiente de la ejecución de la aplicación, y que sólo se tiene en cuenta en la ejecución inicial de la ventana, el crear las interfaces directamente dentro del código fuente de la aplicación hace que la interfaz sea dinámica. El entorno de programación utilizado en este PFC, y que nombramos en el anexo A.3, incluye un editor de interfaz de ventanas en Android para los archivos de diseño XML, el cual nos puede dar una imagen previa del diseño denitivo. Aunque no sea una herramienta muy cómoda ni tampoco muy usable, sólo por el hecho de poder observar una imagen previa aproximada de la interfaz, nos ahorrará mucho más trabajo que compilando la aplicación y observando la interfaz en el dispositivo móvil. Además, nos permite conocer el aspecto gráco de todos los distintos widgets que incluye el SDK de Android. 2.4 Metodología de creación de una aplicación móvil Android 26 Pulsación doble - onDoubleTap Este evento es disparado cuando se realiza con un solo dedo y una doble pulsación simple en un breve periodo de tiempo sobre una misma zona, similar al doble click que se hace sobre el ratón de ordenador convencional. En Travel Blog se usa dentro de la visualización del mapa, donde nos proporciona un modo más de aumentar el nivel de zoom. Pulsación larga - onLongPress Este evento es igual que el evento que acciona el método onLongClick, explicado con anterioridad. En el mapa, este evento nos permite centrar el mapa en la zona pulsada, y nos ofrece la capacidad de registrar como POI propio del usuario la zona pulsada. 2.4.4. Pruebas de integración en la aplicación Como última fase, una vez se tiene a cada elemento de la ventana dotado de interacción, procedemos a realizar las pruebas de su correcto funcionamiento. Durante el desarrollo de la aplicación, básicamente se han realizado tres pruebas diferentes para cada una de las ventanas de navegación: - Prueba de cada widget independientemente. Se prueba que la acción a desempeñar por dicho elemento se realiza correctamente sin ningún tipo de error. - Prueba de cada elemento cuidando el funcionamiento del resto. Se prueba que la acción desempeñada individualmente por dicho elemento no afecta negativamente al comportamiento de ningún otro elemento presente en la interfaz. - Pruebas de integración de la ventana con el resto de ellas. Estas pruebas se reeren a la comprobación del correcto paso de información de una ventana a otra a través de Intents. Como un ejemplo concreto de la fase de pruebas realizadas, vamos a analizar un elemento de la aplicación, como es la galería de imágenes que desempeña la función de calendario y gestiona las entradas de un cuaderno de viaje. En este caso existen dos Listeners registrados en la galería. Uno de ellos controla la pulsación simple sobre cualquier ítem de la galería. El otro Listener controla que exista un ítem seleccionado en la zona central destacada de la galería. La primera prueba consiste en que para cada una de las dos acciones, se miren los datos de las variables y se comparen con los datos que se esperan conseguir. Esto lo podemos realizar gracias a la herramienta de depuración disponible en el entorno de programación. La segunda prueba consiste en comprobar que los demás elementos de la actividad funcionen de manera correcta. En nuestro caso se comprueba que para los dos tipos de eventos detectados por los listeners registrados en la galería, varios widgets cambien consecuentemente: 2.5 Decisiones de diseño adoptadas 27 La lista se carga con la lista de entradas pertenecientes al ítem de la galería seleccionado. La barra de texto que encabeza la galería contiene el año del día seleccionado. La barra de texto que encabeza la lista de entradas contiene el día y mes del ítem de la galería seleccionado. Y como última prueba, se supervisa que el comportamiento dentro de la aplicación sea el correcto. Por ejemplo, se comprueba que la galería, al iniciarse la Activity que la compone, muestre el primer día del periodo que engloba la duración del cuaderno de viaje. De igual manera se comprueba que, volviendo a esta Activity desde una Activity posterior, el ítem que señala la galería es el mismo que se había seleccionado en última instancia. Con estas tres pruebas se puede concluir que el funcionamiento del widget de la galería que realiza la función de calendario es el correcto y esperado. En caso que durante las pruebas se encuentre algún fallo en la aplicación, el entorno utilizado en este PFC proporciona herramientas que ayudan a la localización de fallos en la ejecución. A través de su herramienta de depuración se puede ir ejecutando instrucción a instrucción el código fuente, comprobando el cambio en el estado de los registros, el valor de las variables, etc, en busca de fallos. Aparte del depurador, Android ofrece una herramienta llamada LogCat. Esta herramienta proporciona al desarrollador un mecanismo para recolectar y ver los mensajes de salida del sistema de depuración. Siempre que algo extraño ocurra, se puede consultar LogCat en busca de un fallo inesperado. 2.5. Decisiones de diseño adoptadas A lo largo de esta sección se van a exponer los puntos críticos que han surgido durante la realización de Travel Blog y las decisiones de diseño e implementación que se han tomado para cada uno de los casos. 2.5.1. Representación de la información Uno de los principales problemas surgidos al inicio del proyecto, fue la falta de espacio para la representación de gran cantidad de información. La aplicación a desarrollar está orientada para su ejecución en smartphones, lo que obliga a todo programador de aplicaciones para móvil a usar metodologías y patrones de diseño para realizar una adecuación apropiada del tamaño del dispositivo móvil a la cantidad de información a mostrar. 2.5 Decisiones de diseño adoptadas 28 Además, por experiencias personales, se tiene muy en cuenta otros aspectos importantes como el tener toda la información necesaria accesible con el mínimo número de clicks, disfrutar de una navegación intuitiva y, pedir o mostrar la mínima información posible al usuario. Para solucionar estos problemas, en Travel Blog se han utilizado algunas herramientas concretas proporcionadas por Android que se enumeran a continuación: Listas y galerías: En Android, uno de los widgets más potentes proporcionados son las listas. Son secuencias de items que tienen la posibilidad de mostrar diferentes widgets embebidos en cada uno de esos items, y que permiten un desplazamiento en vertical automático. Las galerías podrían denirse como listas horizontales, pero están más dedicadas a la visualización de fotografías y no son tan potentes como las listas. Pero ambas potencian el aprovechamiento del espacio gracias al desplazamiento automático del que gozan ambos widgets . Menús: Existen dos menús proporcionados por el SDK de Android. El menú de opciones, emergente en la zona inferior de la aplicación tras la pulsación del botón Menú de Opciones, y el menú contextual, disponible después de una pulsación prolongada de uno de los items de una lista. Ambos nos permiten ocultar opciones que, primando la muestra de información, son necesarias para el aprovechamiento funcional de la aplicación. Barra de acción: Se trata de una barra superior donde se muestra el título y un número limitado de opciones diferentes. En Travel Blog se ha utilizado la librería GreenDroid para la implementación de la barra, siendo de este modo, algo sencillo y de apariencia más que agradable para el programador. La barra de acción es aprovechada para incluir las opciones más importantes que deben estar presentes en la Activity, como por ejemplo en Travel Blog el acceso a la Activity del visor del mapa. Dialogs: Un Dialog es un objeto que es mostrado sobre una actividad, quedando de una manera otante sobre ésta. Se puede decir que realiza el papel de ser una extensión de la pantalla. Los Dialogs permiten la muestra de una información adicional necesaria sobre la interfaz de usuario. En Travel Blog utilizamos Dialogs para mostrar alertas, presentar cuestionarios, expandir textos, seleccionar fechas, etc. 2.5.2. Calendario Uno de los primeros retos a desempeñar durante el desarrollo de la aplicación, fue la creación del calendario gestor de las entradas de un viaje. El calendario era una parte clave de la aplicación y algo que podría diferenciar el modo de gestionar los viajes respecto a otras aplicaciones. La primera opción que se tuvo fue usar el calendario que iba incluido como elemento Android, pero enseguida se rechazó por dos importantes razones: 2.5 Decisiones de diseño adoptadas 29 El calendario ocupaba toda la pantalla como si un casillero se tratara y no era escalable. Por lo tanto, no era lo que se buscaba, ya que en el diseño se había decidido mostrar el calendario además de otra información adicional. La mínima version Android necesaria para utilizar la vista de calendario incluida en el SDK era la 3.0 (Honeycomb), versión superior a la mínima pensada y además sólo soportada por tablets. Figura 2.7: Calendario temporal inicial de Travel Blog Como medida temporal, no queriendo que el desarrollo del calendario se convirtiera en un cuello de botella para el PFC, se decide utilizar una API ya creada que mostraba un calendario como una imagen, más bien estática, donde se representara la disposición de los días separados por semanas, para cada uno de los diferentes meses de un año, como si de una imagen clásica de calendario de pared se tratara. Los inconvenientes de esta idea de calendario es que adolece de poca funcionalidad y muestra demasiada información para lo que realmente se ha establecido como necesario. Además, carece de usabilidad para la gestión de las entradas de un viaje. Su única función es señalar los días que comprenden un viaje. En la gura 2.7 se pueden observar el diseño inicial del calendario. Más tarde, se toma la decisión de modicar el calendario de prueba. Se piensa en eliminar la información sobrante, ya que presentar todos los días de un mes resulta excesivo, y se piensa en dotarle de funcionalidad, mostrar la entradas correspondientes al día seleccionado. Tras haber implementado galerías de imágenes en otras Activities, se piensa que por su diseño gráco y usabilidad, se puede adecuar a la idea de calendario que se busca. 2.5 Decisiones de diseño adoptadas 30 Para cada viaje, se crea una galería cuyas imágenes son los días pertenecientes a dicho viaje. La ayuda del scroll horizontal del que gozan las galerías Android hace que no sea un gran problema el gestionar un viaje de muchos días de duración. Además, estando la galería con un día seleccionado, se muestran en una lista inferior todas las entradas correspondientes a ese día. Por lo tanto, se establece como solución nal al calendario gestor de entradas ya que se cumplen los objetivos que se buscaban: Información necesaria. Tamaño apropiado a la interfaz. Funcionalidad deseada de la gestión de las entradas. Intuitivo, usable y agradable grácamente. La implementación de la solución nal al calendario se puede observar en la gura 2.8. Figura 2.8: Calendario creado para la gestión de las entradas de un cuaderno 2.5.3. Visor de mapas Desde los inicios del proyecto, se establece que un visor de mapas es indispensable para Travel Blog. Es una herramienta de gran ayuda al turista que le permite ver en cada momento dónde se encuentra, localizar recursos y conocer el camino para llegar a un destino deseado. Desde el punto de vista de un turista, un mapa es indispensable. Por ello se le da prioridad y fácil accesibilidad al mapa en cualquier ventana de la aplicación a partir de una opción sobre la barra de acción. 2.5 Decisiones de diseño adoptadas 31 A continuación, se establecen unos requisitos al visor de mapas buscado para la aplicación: Mapa global: En la empresa donde se elabora el proyecto disponen unicamente de mapas propios de zonas concretas, como Zaragoza, Belchite, etc. Tratándose de Travel Blog, en principio, una aplicación móvil genérica, se busca que el visor de mapas muestre un mapa global, de todo el mundo. Mapa oine: Aparte de la visualización del mapa, la disponibilidad oine de éste se convierte en una funcionalidad muy deseada y que puede marcar diferencias con otras aplicaciones del mismo ámbito. Visor de mapas de código abierto: Bien es sabido que actualmente Google Maps goza de gran popularidad en todos los sentidos. Aunque también es cierto que el acceso a la API de Google Maps no sólo se ha convertido en una API de pago, si no que un desarrollador no tiene acceso al código fuente para crear mapas personalizados. Una vez denidos los requisitos para el visor de mapas, se busca una API que se ajuste lo máximo posible a ellos. Como elección, tras muchos análisis y pruebas con diferentes visores, se escoge una API llamada OSMDroid 9 . Se trata de un conjunto de herramientas para crear vistas e interaccionar con mapas OSM sobre Android. Es una API de código abierto cuyo código fuente es de libre acceso. Ésto hace posible la personalización del mismo y el conocimiento de su funcionamiento, algo que valoro mucho personalmente, ya que se trata de un área desconocida. Como fase de personalización del mapa, se han añadido los siguientes elementos acordes con Travel Blog, pudiéndose observar algunos de ellos en la ventana mostrada en la gura 2.9: Iconos personalizados para fotos, POI's, rutas, y otros elementos geolocalizados. Indicación del nivel de zoom en el que se encuentra el visor. Creación de un icono de posicionamiento sobre la pantalla para el registro de nuevos POI's. Búsqueda de lugares geográcos mediante entrada de texto. Muestra sobre el mapa de parte de la información de un elemento del usuario geolocalizado. Creación de un botón que indica la localización del usuario vía GPS o red de datos. Descarga del mapa visualizado en pantalla. 9 http://code.google.com/p/osmdroid/ 2.5 Decisiones de diseño adoptadas 32 Figura 2.9: Visor de mapas modicado para Travel Blog 2.5.4. Elementos multimedia El tratamiento de los datos multimedia, sobre todo fotos y vídeos, es un tema delicado, ya que son grandes archivos que hay que transmitir entre la aplicación y GeoSisTur en ambos sentidos. Se necesita diseñar una solución que miniminice la carga de datos pero sin que se vea afectado el contenido multimedia. Otras aplicaciones móviles, como la popular WhatsApp 10 o la analizada previamente Tourist Eye, comprimen las fotos y los vídeos de tal manera que ocupen pocos kilobytes y puedan transferirse más rápidamente. La calidad, obviamente, se ve perjudicada, pero suciente para la verse correctamente en una pantalla de teléfono móvil. La decisión tomada por las dos aplicaciones anteriores ha sido también la elegida para Travel Blog. En el sentido de la aplicación hacia GeoSisTur, antes de enviarse mediante mensajes JSON, se comprimen los archivos multimedia a ser transferidos. En el sentido contrario, el servicio web de GeoSisTur es quien hace la misma tarea 10 http://www.whatsapp.com/ 2.5 Decisiones de diseño adoptadas 33 para transferirlos a la aplicación móvil. 2.5.5. Comunicación con GeoSisTur Quizás, junto con el desarrollo del mapa de la aplicación, sea uno de los hitos más importantes que este PFC ha tenido que desempeñar. El diseño de la comunicación ha sido una tarea constante. Desde los primeros análisis, hasta la consecución de la aplicación, se ha ido entrando cada vez más en detalle. Pero no ha sido hasta haber nalizado con la parte oine de la aplicación, cuando la comunicación con GeoSisTur ha sido desarrollada. Al igual que con los mapas, lo primero de todo es buscar los requisitos a cumplir con la comunicación mediante servicios web. Se desea un protocolo sencillo que no deba implementar mucho más de lo disponible en el SDK de Android. El formato de los mensajes debe ser ligero para ayudar a la uidez de la comunicación. Mensajes de fácil tratamiento y que tengan algún tipo de soporte para trabajar con objetos Java. Comunicación síncrona. Por el momento no se tiene pensado en crear una comunicación asíncrona con GeoSisTur, aunque se puede dejar para líneas futuras. A continuación cito alguna de las principales conexiones con GeoSisTur: Login/Password. Nuevo registro de usuario. Actualización de cuadernos de GeoSisTur. Consulta y descarga de POI's de la comunidad GeoSisTur. Nuevo comentario. La elección ha sido la de usar el protocolo REST, mediante paso de mensajes JSON con la ayuda de la librería GSON para la creación y la traducción de esos mensajes en objetos Java. Con esta elección se cumplen todos los requisitos. En la gura 2.10 se puede observar un esquema de la arquitectura seguida para la conrmación de las credenciales en GeoSisTur. A continuación se enumeran las principales razones por las que se ha elegido como servicio web que establezca la comunicación con GeoSisTur a un servicio REST. 2.5 Decisiones de diseño adoptadas 34 petición HTTP JSON Internet respuesta [{”userlogin”:”ok”}] [{”user”:”sergio”,”pass”:”xxxx”}] Figura 2.10: Arquitectura de la comunicación de Travel Blog con GeoSisTur Ligereza: no contiene demasiadas marcas XML. Resultados legibles por humanos. Fácil de construir tanto del lado del cliente como del lado del servicio, no necesita de herramientas especiales. Soporte incluido en el SDK de Android (HTTP). Seguidamente se muestran las razones por las cuales se ha elegido JSON en detrimento de XML como el formato de los mensajes en el intercambio de datos con GeoSisTur. Utilizado y conocido dentro de la empresa. Formato ligero, compacto y ecaz para el intercambio de datos. Muy popular y extendido en el mundo de las aplicaciones para móvil. Fácilmente parseable con JavaScript mediante el comando eval(). Soporte incluido en el SDK de Android. Por último, se detallan las dos principales razones y ventajas que proporciona el uso de la librería GSON: Sencilla conversión de JSON a objeto Java: toJson() y fromJson(). Soporte para objetos complejos. Capítulo 3 Conclusiones En este capítulo nal de la Memoria se valorará el cumplimiento de los objetivos a la vista de los resultados obtenidos, se indicarán posibles líneas de trabajo como continuación del presente PFC, y se valorará la experiencia conseguida con su realización. 3.1. Resultados Obtenidos El resultado más palpable obtenido con la realización del proyecto es la misma aplicación móvil genérica desarrollada durante el periodo que ha durado el mísmo, sin olvidar la metodología que se ha seguido a la hora de la creación de aplicaciones móviles en Android, y el mundo de proyectos en esta novedosa área que se abren a partir de ahora. Este PFC ha estado enmarcado en un contexto de empresa, incluido dentro del producto turístico ya mencionado anteriormente GeoSisTur. Considerando que Geo- SisTur es una plataforma web genérica de creación de portales turísticos concretos, la aplicación que se ha desarrollado como resultado, puede adaptarse perfectamente a la personalización acorde a un portal turístico en concreto, debido a la modularidad e independencia de cada una de las partes del proyecto. Por consiguiente se puede armar que se han cumplido los objetivos propuestos, ya que la aplicación es completamente funcional cumpliendo la totalidad de los requisitos y ya probada satisfactoriamente durante el disfrute de un viaje, su principal cometido. 3.2. Líneas Futuras Durante la realización del proyecto han ido surgiendo múltiples vías de desarrollo que mejoren o añadan nuevas funcionalidades. A.3 Herramientas utilizadas 42 la funcionalidad nal. La forma en que los plugins interactúan entre sí es mediante interfaces o puntos de extensión; de esta forma las nuevas aportaciones se integran sin dicultad. Otra gran ventaja para la realización del proyecto es la integración de Eclipse con el sistema de versionado Subversion, que además sirve para la realización de copias de seguridad de los documentos y para la consulta del proyecto por parte de la empresa. Para la elaboración de este documento se ha utilizado L A TEX, un procesador de textos basado en un lenguaje de marcado. Permite escribir documentos centrándose en el contenido sin tener que preocuparse en el formato del mismo, como suele pasar en herramientas WYSIWYG es decir, Lo que ves es lo que obtienes, donde se requiere de una alta habilidad para el formateo de documentos, labor que se complica exponencialmente conforme va aumentando el tamaño del documento. Gracias a L A TEX este documento ha podido ser confeccionado de forma eciente y con resultados visuales nales de alta calidad. Además, para la edición, la confección de la memoria de este PFC se ha realizado con un plugin para Eclipse que proporciona soporte para L A TEX llamado TEXlipse. Otras herramientas utilizadas durante el desarrollo del proyecto han sido: Evolus Pencil : Diseño de ventanas Android. Microsoft Oce Visio : Creación de diagramas de clases. Microsoft Excel : Control de esfuerzos diario. Microsoft Word y PowerPoint : Elaboración de la documentación generada en el Grupo y creación de diagramas de arquitectura. Photoshop : Herramienta gráca para creación y edición de las imágenes utilizadas en la documentación, y para la creación de iconos y demás imágenes necesarias en la aplicación. GanttProject : Diagramas de Gantt usados para la planicación del proyecto. Anexo B Análisis de Requisitos En las sección 1.3 del capítulo 1de introducción, y con algo más de detalle en la sección 2.2.2, se han expuesto los requisitos que se determinaron para este proyecto en el momento de su concepción. Este anexo simplemente pretende dar una descripción más detallada de las características que debe cumplir el sistema software a construir. B.1. Requisitos funcionales Para la plataforma tecnológica objetivo de este proyecto se tiene los siguientes requisitos funcionales: RF-1 Gestión de encuestas. RF-2 Funcionamiento oine. RF-3 Muestra de los cuadernos de viaje por orden de fecha de acción. Los cuadernos que se muestran en la aplicación pueden ser propios del usuario (editables) o ajenos al usuario(no editables), descargados a través de GeoSisTur. RF-4 Gestión de cuadernos de viaje (Alta/Baja/Modicación). RF-5 Un cuaderno está formado por título, fecha de inicio, fecha nal, descripción del cuaderno, imagen de portada y entradas asociadas. RF-6 Mostrar información asociada a un cuaderno de viaje. • Título. • Imágen de portada. • Fechas de inicio y nal. • Descripción. B.1 Requisitos funcionales 44 • Entradas asociadas por día de cuaderno. RF-7 Gestión de entradas (Alta/Baja/Modicación). RF-8 Una entrada está formada por título, fecha de inicio, hora de inicio, descripción de la entrada, imagenes, videos, rutas y recursos asociados. RF-9 Mostrar información asociada a una entrada. • Título • Fecha y hora de inicio. • Imágenes y vídeos asociados. • Recursos asociados RF-10 Creación de eventos en Google Calendar a partir de la creación de una nueva entrada. RF-11 Gestión de recursos turísticos. RF-12 Un recurso turístico está formado por nombre, dirección postal, dirección web, teléfono de contacto, tipo de recurso, georeferencia (latitud,longitud) y imagenes, vídeos, comentarios y puntuación asociada. RF-13 Mostrar información asociada a un recurso. • Teléfonos de contacto. • Georreferenciación en el mapa. • Indicaciones para llegar desde la posición actual. • Página web. • Valoración de los comentarios asociados al recurso. • Comentarios asociados al recurso. RF-14 Un recurso puede ser creado por el usuario (editable) u obtenido a través de GeoSisTur (no editable). RF-15 Comentar y valorar recursos turísticos. RF-16 Creación y asociación de imágenes, vídeos o recursos turísticos nuevos o ya existentes a un cuaderno, entrada o recurso. RF-17 Asociación de rutas ya creadas a una entrada. RF-18 Gestión de recursos multimedia. RF-19 Muestra de las propiedades de un elemento multimedia. RF-20 Reproducción de multimedia y compartición por medio de e-mail, Bluetooth y otros medios disponibles en el dispositivo móvil. B.2 Requisitos no funcionales 45 RF-21 Mostrar información geográca sobre un mapa accesible desde un cuaderno, una entrada o un recurso de la aplicación. • Localización de recursos multimedia y turísticos georreferenciados. • Visualización de información de recursos, una pequeña imagen en el caso de recursos multimedia, y el título en el caso de recursos turísticos. • Localización del usuario. • Visualización del nivel de aumento de un mapa. • Descarga de tiles online para la visualización de un mapa de una zona concreta oine. • Muestra de una brújula. • Búsqueda de lugares geográcos. • Creación de lugares señalados sobre el mapa. • Muestra de los POIs creados por el usuario. RF-22 Conexión e intercambio de datos (actualización, descarga y consulta) con Geo- SisTur. • Búsqueda y descarga de cuadernos propios y ajenos. • Búsqueda y descarga de recursos turísticos. • Actualización de cuadernos de viaje del usuario. • Creación de POIs a partir de POIs del usuario. • Actualización de comentarios sobre un recurso. • Registro de nuevo usuario GeoSisTur. • Gestión del perl de usuario. RF-23 Mostrar Ayuda al inicio de la aplicación. B.2. Requisitos no funcionales La plataforma tecnológica objeto del presente proyecto tiene los siguientes requisitos no funcionales: RNF-1 Creación de aplicación móvil para la plataforma Android de Google. RNF-2 Uso de tecnologías Open Source (Código Abierto) en el visor de mapas, concretamente OpenStreetMaps (OSM). RNF-3 Gestión y persistencia de objetos Java en base de datos SQLite a través de ORMLite. RNF-4 Conexión con servicios web externos mediante protocolo REST y formato de mensajes JSON. Anexo C Diseño y Modelo de datos En este anexo se recoge todo lo que engloba la fase de diseño de la aplicación tras la obtención de los requisitos funcionales y se explicará con más en detalle la fase del diseño de las ventanas y la navegación a través de las mismas, asi como el modelo de datos utilizado para la estructura de información necesaria en Travel Blog. C.1. Diseño de la aplicación Durante la fase de diseño de la aplicación se han realizado dos tipos diferentes de tareas, una a continuación de la otra. La primera tarea ha sido la obtención de las ventanas de navegación de forma gráca a partir de la herramienta de creación de prototipados de interfaces grácas. La segunda tarea ha consistido en, a partir de las ventanas diseñadas, crear la navegación entre las mismas. C.1.1. Prototipado de las ventanas de navegación Evolus Pencil es la herramienta usada para esta tarea. Se trata de una herramienta de software libre para la elaboración de diagramas y de prototipado de interfaces de usuario. Durante el inicio de la fase de diseño se buscó una herramienta que permitiera crear pantallas Android, y Pencil cumplía todos los requisitos deseados. Pencil admite juegos de formas prediseñadas para la elaboración de diagramas de distintos tipos. El hecho es que uno de estos juegos cuenta con todas las formas básicas de diseño en Android y, además, al tratarse de un software WYSIWYG, el trabajo con Pencil se hace muy versátil y ameno. Pencil también permite varias formas de exportación del prototipado diseñado. Los resultados de dicha importación pueden ser en forma de imágenes independientes, ideal para incluir en documentación como en el caso de la memoria de este PFC, C.2 Modelo de datos 47 como también en forma de presentación HTML, realmente útil para la presentación al cliente de la navegación de las ventanas con un resultado muy profesional. Tal ha sido el descubrimiento de Pencil a la hora de crear el prototipado de las ventanas de una aplicación Android, que se ha adoptado dentro de la empresa para el uso en nuevos proyectos del mismo tipo. En la gura C.1 pueden verse algunos de los prototipos de ventana creados para el desarrollo de la aplicación Travel Blog. Figura C.1: Prototipos realizados con Pencil en la fase de diseño C.1.2. Navegación de la aplicación Tras la creación de los prototipos de pantalla de la aplicación, se realizó la conexión entre éstos. Aunque esta tarea se podía intuir de una manera aproximada, no fue tras el diseño de las pantallas cuando se estableció un plan de navegación ja para Travel Blog. En la gura C.2 se puede ver la navegación básica entre los diferentes prototipos de pantalla diseñados. C.2. Modelo de datos Una vez diseñadas las pantallas de navegación, necesitamos estructurar la información que éstas contienen mediante un modelo de datos. Dicho modelo es el que se puede ver en la gura C.3. A partir del modelo de datos diseñado a más alto nivel, se ha ido buscando la cantidad mínima necesaria de información para cada una de las entidades del modelo, con el n de dar una imagen de ligereza y usabilidad a Travel Blog. Podemos ver un esquema de los atributos que forman cada una de las clases en la gura C.4. C.2 Modelo de datos 48 Figura C.2: Navegación de ventanas entre las principales pantallas diseñadas La gran parte de los atributos son de sencilla explicación, pero existen algunos que merecen algo más de detalle: editable : Atributo de las entidades TravelBlog y Resource. Se reere al permiso que indica si es posible la modicación o agregación de la información en cada una de las dos entidades. ag : Atributo de la entidad TravelBlog que nos permite conocer si un cuaderno de viaje es nuevo o, por el contrario, ya existe y se va a proceder a su modi- cación. Su cometido es el de aprovechar la interfaz gráca y poder unicar la pantalla de creación con la pantalla de modicación de cuadernos. path : Presente en muchas de las entidades del modelo, representa la localización de una imagen o video dentro de la memoria del dispositivo móvil. Nos permite no tener que cargar con todo el peso del archivo cada vez que sea utilizado, si es que éste se encuentra en memoria. imgrec : Atributo de la entidad Resource, la cual denota el identicador de imagen representativa de cada tipo de recurso. En Android, las imagenes predenidas añadidas al proyecto pueden ser accedidas gracias a que disponen de un identicador asignado en el proceso de compilación de la aplicación. Dicho identicador es el indicado por este atributo y, a su vez, el indicado por el atributo rec de la entidad POIType. C.2 Modelo de datos 49 Figura C.3: Modelo de datos de la aplicación móvil Travel Blog Figura C.4: Detalle de los atributos de las entidades más importantes del modelo de datos Anexo D Arquitectura del sistema En este anexo se explica más en profundidad la arquitectura pensada para la aplicación Travel Blog, donde se detalla la interacción con la estructura que ofrece el sistema operativo Android y las comunicaciones con las fuentes de información externas. En la gura D.1 se puede observar el diagrama con la mayoría de los componentes del sistema operativo Android. Figura D.1: Arquitectura del sistema operativo Android 51 Básicamente, la arquitectura del sistema operativo Android se divide en cinco partes diferentes: Applications En esta parte se sitúan todas las aplicaciones instaladas por el usuario y las nativas del sistema. Todas estas aplicaciones están codicadas en lenguaje de programación Java. Es en esta zona está situada la aplicación desarrollada en este PFC Travel Blog. Application Framework Es la zona del sistema operativo donde se encuentran las herramientas que Android proporciona al desarrollador de aplicaciones. Se podría decir que esta zona de la arquitectura se encarga de la conexión entre la aplicación y el exterior a través de diferentes interacciones soportadas por Android como sensores en pantalla, antena GPS, etc. Alguna de las herramientas incluidas en el Application Framework se enumeran a continuación: • Gestor de Activities. • Sistema de Views. • Gestor de recursos (iconos, audio, estilos, etc). • Gestor de localización. • Gestor de telefonía. Libraries Android incluye un conjunto de librerías localizadas en esta parte de la arquitectura usadas por diferentes componentes del sistema. Estas capacidades se le proporcionan al desarrollador a través del Application Framework. A parte de éstas librerías, en el desarrollo de Travel Blog hemos necesitado otras ajenas al sistema Android como por ejemplo: • ORMLite: usada para el mapeo objeto-relacional de la base de datos SQLite. • MetadataExtractor: utilizada para obtener información detallada de archivos multimedia como la orientación, la posición geolocalizada, etc. • GeoJson: librería utilizada junto a JSON, proporcionada por Android, que nos permite la conversión y traducción de objetos Java en mensajes JSON para el intercambio de datos con servicios web. • OSMDroid: permite la visualización básica de mapas OSM en dispositivos Android. Esta librería ha sido editada para conocer el funcionamiento interno y la modicación de la misma de acuerdo a los requisitos elegidos para el visor de mapas de la aplicación. • GreenDroid: librería que ofrece al usuario un ahorro de tiempo y facilidad en la creación de la interfaz gráca de Android. En Travel Blog se ha utilizado únicamente para la creación de la barra de acción presente en muchas de las pantallas de la aplicación. 5 Cuadernos de viaje Ya hemos comentado que un cuaderno de viaje va a ser la entidad principal de la aplicación. En ella almacenaremos toda la información posible sobre cada una de nuestras escapadas. Inicialmente, nuestra lista de cuadernos de viaje se encontrará vacía al acabar de iniciar la aplicación. Para poder crear o disponer de nuestros cuadernos de viaje tenemos dos opciones que veremos en detalle más adelante, como son la creación desde cero de un cuaderno de viaje y la descarga de cuadernos alojados en GeoSisTur. Creación de un cuaderno Para la creación de un cuaderno de viaje existen dos modos de realizarlo: a través de la opción “MAS” en la barra de acción de la aplicación, o a través de “Nuevo Cuaderno” en el menú de opciones. Cada una de estas dos maneras de crear un cuaderno nos llevará a la pantalla de “Nuevo Cuaderno”, donde se nos piden los datos más básicos de un cuaderno de viaje. El número justo para que no se te haga pesada la creación de un cuaderno. Si se te hace pesado, puedes crear un cuaderno sin introducir ningún dato para dar agilidad a Travel Blog. Una vez creado nuestro cuaderno de viaje, aparecerá en la lista inicial con la imagen de portada, el título y el periodo de acción correspondiente. Nuevo Cuaderno Menú de opciones 6 Descarga Para realizar la descarga de cuadernos, antes debemos echar un vistazo a la sección “Conexión con GeoSisTur”, donde se explica paso a paso el proceso de inicio de la comunicación con el portal web. Teniendo ya una cuenta con GeoSisTur, en la lista de cuadernos de viaje de Travel Blog existe la opción “Descarga Cuadernos” accesible a través del menú de opciones. Solamente nos pedirán los datos de registro de nuestra cuenta GeoSisTur, y podremos acceder a los cuadernos que contiene el portal. Así podremos elegir los cuadernos a descargar, e incluso se cuenta con un buscador de cuadernos que, a través de una entrada de texto, encuentra los cuadernos de viaje cuyo título se corresponda con el texto introducido. Por ejemplo, si vamos a visitar Roma, con solo escribir Roma en el cuadro de texto aparecerán todos los cuadernos de viaje en cuyo título esté contenida la palabra Roma, y así poder disponer de una guía creada por un viajero como tú. Tras el tiempo de descarga, dependiendo del tamaño de la cantidad de cuadernos a descargar y del tamaño de cada uno de éstos, aparecerán en nuestra lista de cuadernos de viaje para su consulta y edición, si es que el cuaderno tiene los permisos necesarios. Modificación La modificación de un cuaderno puede realizarse a través del menú contextual en la lista de cuadernos de la aplicación, o a través de la opción “Modificar Cuaderno” del menú de opciones dentro de los detalles del cuaderno de viaje a modificar. Modificar Cuaderno Menú contextual 7 A través de ambas opciones se accede a la pantalla de modificación del cuaderno, una pantalla con los mismos campos que los que aparecen en la creación de un nuevo cuaderno, pero inicializados con la información existente del cuaderno para que puedas editarla. Detalles de cuaderno Una vez tenemos algún cuaderno en nuestra lista, podemos acceder a los detalles del cuaderno pulsando el ítem correspondiente en la lista. Si en vez de una pulsación simple, realizamos una pulsación continuada sobre dicho ítem, aparecerá un menú sobre la pantalla, llamado menú contextual, mostrándonos opciones que tendrán efecto sobre el cuaderno seleccionado de la lista: “Editar Cuaderno” [ver sección Modificación] y “Eliminar Cuaderno”, que nos eliminará dicho cuaderno previa confirmación. 8 En los detalles del cuaderno se puede ver toda la información correspondiente a dicho cuaderno, un calendario indicando los días de acción establecidos para dicho cuaderno de viaje, y una lista de entradas para cada uno de los días. Comentar que si la descripción del cuaderno se excede en más de 3 líneas, por razones de adecuación al tamaño de la pantalla, el resto no es mostrado. En tal caso, tras una pulsación sobre el texto perteneciente a la descripción, éste expande toda la información sobre una pantalla emergente. Ahora te toca a ti, esperamos que los detalles del cuaderno se vayan llenando de experiencias poco a poco a través de la creación de entradas de viaje. [Ver sección “Entradas de cuadernos de viaje”] Actualización Del mismo modo que nos decargamos en Travel Blog un cuaderno creado en GeoSisTur, podemos realizar la acción opuesta, cargar un cuaderno creado en Travel Blog en GeoSisTur. Para ello disponemos de la opción “Actualizar Cuadernos” disponible en el menú de opciones. Pero antes, asegurate que la información que va a ser volcada, no elimine ninguna información anterior que quieras conservar, pues el cuaderno actualizado se sobreescribe sobre el anterior. Entradas de cuaderno de viaje Ver/ocultar todas las entradas Entradas del día 7 Calendario 9 Una entrada de cuaderno, es cada una de las entidades que forman un cuaderno de viaje. Se puede asemejar una entrada en Travel Blog a la visita de un lugar en la vida real. En Travel Blog, cada una de las entradas de un cuaderno serán las encargadas de almacenar los recursos multimedia y turísticos de dicho cuaderno. Las entradas de un viaje pueden ser accedidas a través de los detalles del cuaderno correspondiente. En los detalles de dicho cuaderno, se muestran los días del período de acción en forma de hojas de calendario. Para cada una de las hojas de calendario del cuaderno viaje, existe una lista de entradas, donde por orden cronológico se sitúan las entradas perteneciente al día elegido. En la barra de acción también se puede ver la opción “OJO” en la que se activará y desactivará el listado de todas las entradas del cuaderno de viaje independientemente del calendario. Creación de una entrada Al igual que para los cuadernos de viaje, la creación de entradas de cuadernos es accesible a través la opción “MÁS” en la barra de acción o a través de la opción “Nueva Entrada” en el menú de opciones dentro del detalle de un cuaderno de viaje en concreto. Cada una de estas dos maneras de crear una entrada nos llevará a la pantalla de creación “Nueva Entrada”, donde se nos piden los datos más básicos de una entrada de cuaderno de viaje con el fin de agilizar el proceso. Cuando confirmamos la creación de dicha entrada, tenemos la opción de guardar dicha entrada como evento de Google Calendar, utilidad creada para la planificación de viajes con antelación y para que te sirva de recordatorio. Menú de opciones Nueva Entrada 10 Una vez creada nuestra entrada, aparecerá en la lista de entradas dentro del detalle del cuaderno de viaje correspondiente con la hora de inicio elegida. Modificación La modificación de una entrada puede realizarse a través del menú contextual en la lista de entradas, o a través de la opción “Modificar Entrada” del menú de opciones dentro de los detalles de la entrada a modificar. Menú contextual 11 Detalles de Entrada La primera vez que se acceda a los detalles de una entrada a través de la lista de entradas, aparecen los datos que has introducido durante la creación de la entrada. Ahora es el momento de rellenar la entrada añadiendo los diferentes tipos de recursos que se pueden añadir a una entrada de viaje. Recursos multimedia: A una entrada se le pueden asociar diferentes recursos multimedia a través de las opciones disponibles en el menú de opciones: - “Añadir Foto”: Permite la asociación de una sola fotografía a la entrada correspondiente. Esta fotografía puede tener dos orígenes: almacenada previamente en la memoria del dispositivo móvil, accesible desde diferentes aplicaciones como la Gallery de Android, o directamente desde la propia cámara de fotos del móvil. - “Añadir Video”: De forma análoga a añadir una fotografía, se asociar videos a una entrada. - “Añadir Ruta”: A través de un explorador de archivos, se asocia un archivo de extensión .gpx a la entrada correspondiente. Recursos turísticos: A una entrada se le pueden asociar también diferentes recursos turísticos o POIs como monumentos, restaurantes, hoteles, eventos, etc. [ver sección Detalle de Recurso turístico] - “Asociar Recurso”: Permite la asociación de recursos turísticos disponibles en GeoSisTur previo algún tipo de filtrado como texto, cercanía, tipo, etc. Así también permite la asociación de recursos turísticos creados por el propio usuario a través del mapa. [Ver sección Mapa] Estos recursos, una vez añadidos, aparecen en forma de galería, en el caso de fotos y vídeos, y en forma de listado en el caso de los recursos turísticos. Cada uno de estos recursos puede ser accedido mediante una pulsación simple sobre cualquiera de las colecciones, ya sea en la galería como en la lista de recursos. 12 Detalle de recurso turístico Un recurso turístico o POI (Point of Interest) puede ser desde un teatro, un producto típico o una ciudad, hasta un evento, monumento, etc. Todo POI contiene información detallada de situación geográfica y contacto. Cada recurso turístico puede ser accedido a través de los detalles de la entrada a la que ha sido asociado. Además de la información predefinida tal como teléfono, web, dirección postal, tipo, etc, el usuario puede editar dicho recurso turístico a través de la adición de fotografías propias o de comentarios valorando dicho recurso, siempre que los permisos de edición sobre el recurso lo permitan. En los detalles de un recurso turístico, toda la información básica es accesible a través de un menú propio de opciones. Además tiene su propia galería de imágenes, de la misma manera que una entrada, y se muestran los comentarios más significativos realizados por los usuarios de la comunidad de GeoSisTur. Por último, los comentarios pueden ser creados y añadidos por el usuario de Travel Blog, para que en todo momento se pueda tener en cuenta tu opinión. Galería de fotos y vídeos Galería Multimedia Listado de recursos asociados Detalle de recurso 13 Galería Multimedia La galería multimedia es una zona de Travel Blog dedicada especialmente a los recursos multimedia asociados a las diferentes entradas. Esta zona puede ser accedida a través de la opción “Galería Multimedia”. Esta opción es accesible desde los detalles de las tres entidades más importantes: detalles de cuaderno de viaje, detalles de entrada y detalles de recurso turístico. Dependiendo desde que zona se acceda, la galería multimedia se rellenaré de unos recursos multimedia u otros: • Si se accede desde los detalles del cuaderno, la galería multimedia muestra toda foto y video de las entradas que forman dicho cuaderno. • Si se accede a través de los detalles de la entrada, la galería muestra las fotos y videos asociados a dicha entrada. • Si se accede desde los detalles de un recurso, solo las fotos y videos asociadas a éste serán mostradas en la galería. También es posible acceder a través de las galerías de imágenes presentes en los detalles de entrada y de recurso. En la misma galería también se pueden realizar algunas tareas de gestión como las que se pueden ver en la imagen: • Añadir una nueva foto a la entrada. • Eliminar o disociar la foto central de la entrada. • Ver la información EXIF de la imagen mostrada, solo en caso de fotografías. • Geolocalizar en el mapa si la imagen lo permite. Si se realiza doble click sobre la imagen mostrada, ésta se reproduce según la aplicación Android nativa compatible con dicho fichero. Por ejemplo, si se trata de un video, al hacer doble click es reproducido por la aplicación nativa de vídeo. Por último comentar que la galería permite el paso de fotografías por deslizamiento horizontal, zoom mediante pellizco y navegación sobre la imagen mostrada. 14 Mapa El mapa es una de las partes principales de la aplicación debido a su utilidad de cara al viajero. Es accesible tanto en la opción “BRÚJULA” presente en la barra de acción de las pantallas principales, así como en la opción “Mapa” que podemos encontrar en el menú de opciones de las pantallas principales. En la pantalla del mapa nos encontraremos con una barra de escala, una brújula y el nivel de zoom actual para ayudar a la mejor comprensión de la zona a explorar. En la barra de acción existe una opción también accesible desde el menú de opciones que es la de localización. Permite al usuario hallar la localización donde se encuentra en ese mismo momento. La localización se basa en red de datos, o en GPS. Si queremos que se realice con éxito, al menos una de las dos opciones debe estar activada. El aumento y decremento del nivel de zoom se puede realizar de dos maneras: • Mediante los controles que aparecen cuando el mapa es tocado. • A través la pantalla multitáctil a través del gesto “pellizco”. Brújula Escala Localización Icono de Localización Nivel de Zoom Control de Zoom Icono de foto Icono de Recurso Reseña de foto Acceso al Mapa 21 Detalle de recurso turístico Galería Multimedia 22 Mapa Parte III Acrónimos, Figuras, Bibliografía Acrónimos API Application Programming Interface DGA Diputación General de Aragón GPS Global Positioning System HTTP HyperText Transfer Protocol I+D+i Investigación, desarrollo e innovación JSON JavaScript Object Notation NFC Near Field Communication ORM Object-Relational Mapping OSM Open Street Maps PFC Proyecto Fin de Carrera POI Point Of Interest REST Representational State Transfer SD Secure Digital SDK Software Development Kit SOAP Simple Object Access Protocol SQL Structured Query Language WSDL Web Services Description Language XML eXtensible Markup Language Índice de guras 1.1. Reparto de las versiones de Android a fecha de 3 de enero de 2012 . . 4 2.1. Arquitectura del sistema de la aplicación Travel Blog . . . . . . . . . 16 2.2. Modelo de datos de la aplicación móvil Travel Blog . . . . . . . . . . 17 2.3. Ventanas de la aplicación realizadas durante la fase de diseño . . . . . 18 2.4. Editor XML del entorno de programación utilizado para el diseño de la interfaz de usuario de TravelBlog . . . . . . . . . . . . . . . . . . . 20 2.5. Arquitectura de ORMLite . . . . . . . . . . . . . . . . . . . . . . . . 21 2.6. Acciones gestuales de interacción con Travel Blog: (a)-Pulsación simple; b()-Desplazamiento horizontal; c()-Desplazamiento vertical; d()- Aumento de nivel de zoom . . . . . . . . . . . . . . . . . . . . . . . . 25 2.7. Calendario temporal inicial de Travel Blog . . . . . . . . . . . . . . . 29 2.8. Calendario creado para la gestión de las entradas de un cuaderno . . 30 2.9. Visor de mapas modicado para Travel Blog . . . . . . . . . . . . . . 32 2.10. Arquitectura de la comunicación de Travel Blog con GeoSisTur . . . . 34 A.1. Cronograma nal del PFC. . . . . . . . . . . . . . . . . . . . . . . . . 41 C.1. Prototipos realizados con Pencil en la fase de diseño . . . . . . . . . . 47 C.2. Navegación de ventanas entre las principales pantallas diseñadas . . . 48 C.3. Modelo de datos de la aplicación móvil Travel Blog . . . . . . . . . . 49 C.4. Detalle de los atributos de las entidades más importantes del modelo dedatos.................................. 49 D.1. Arquitectura del sistema operativo Android . . . . . . . . . . . . . . 50 D.2. Arquitectura de la aplicación Travel Blog . . . . . . . . . . . . . . . . 52 Bibliografía [1] Plataforma GeoSisTur http://www.geosistur.com/ 1.2.4 [2] Mark L. Muprhy: The Busy Coders Guide to Android Development , v3.6. CommonsWare , 2011 ISBN: 978-0-9816780-0-9 [3] Mark L. Murphy: The Busy Coder's Guide to Advanced Android Development , v1.9. CommonsWare, 2010 http://commonsware.com/AdvAndroid/AdvAndroid-1_9-CC.pdf ISBN: 978-0-9816780-1-6 [4] Grant Allen and Mike Owens: The Denitive Guide to SQLite , Segunda edición. Apress, 2010 ISBN: 978-1-4302-3225-4 [5] Gray Watson: ORMLite Package , v4.25. 2011 http://ormlite.com/docs/ormlite.pdf [6] Android Developpers http://developer.android.com/index.html [7] Salvador Gómez: Tutorial Android por Sgoliver http://www.sgoliver.net/blog/?p=1313 [8] Preguntas y respuestas sobre programación http://stackoverflow.com [9] Cyril Mottier: Librería GreenDroid http://android.cyrilmottier.com/?p=240 [10] OSMDroid - OpenStreetMaps-Tools for Android http://code.google.com/p/osmdroid/ [11] Maps-Minus: OpenStreetMaps.org oine map viewer http://code.google.com/p/maps-minus/ 2.4.2 [12] OsmAnd: Navigation & routing based on Open Street Maps for Android devices http://code.google.com/p/osmand/ BIBLIOGRAFÍA 80 [13] JavaCodeGeeks: Android JSON Parsing with Gson Tutorial http://www.javacodegeeks.com/2011/01/android-json-parsing-gson-tutorial. html Nota: Las direcciones de Internet que aparecen en esta bibliografía están revisadas y accedidas a fecha 09/02/2012.