Herramientas para el desarrollo ................................. ....................................................... ...................................... ................ 14
4.2.1.
Equipos de desarrollo ................................................ ....................................................................... ............................... ........ 15
5. Manual de Android e instalación del entorno de trabajo ........................................ ........................................ 19 5.1.
Introducción a Android .............................. ..................................................... ............................................. ............................... ......... 20
5.2.
Breve historia ..................................................... ............................................................................ ............................................. ........................ 21
5.3.
Estructura de Android ................................. ....................................................... ............................................ ............................... ......... 22
5.4.
Estructura de una aplicación Android .......................................... .............................................................. .................... 25
5.5.
Ciclo de vida de una aplicación en Android ........................................... .................................................... ......... 29
5.5.1. 5.6.
Prioridad de procesos....................... procesos............................................. ............................................. ................................... ............ 32
Herramientas para el desarrollo ................................. ....................................................... ...................................... ................ 33
5.6.1.
Instalación de Eclipse ................................. ....................................................... ............................................. ......................... 33
Instalar plugin de Android para Eclipse Ecl ipse ............................... ................................................... .................... 34
5.6.4.
Completar la instalación .................................. ....................................................... ......................................... .................... 36
5.6.5.
Otras herramientas útiles ................................................... ......................................................................... ........................ 39
5.6.5.1.
Otras funcionalidades del emulador .......................................... .................................................. ........ 39
5.6.5.2.
Dalvik Debug Monitor Service ........................................................ .......................................................... 39
Este documento tiene como propósito detallar la labor realizada durante el periodo de ejecución del proyecto final de carrera, el cual consiste en una aplicación para dispositivos móviles Android . Esta aplicación presenta un diario de viaje, que permite documentar los viajes visitados, añadiendo información relevante para el usuario, fotos y enlaces a wikipedia, archivados por viaje y lugar, pudiendo localizar estos lugares visitados mediante su posición GPS y mostrarlos a través de Google Maps. Todo esto mediante Android , que es una plataforma de programación de software para dispositivos móviles creada por Google. El objetivo de esta aplicación es tener un recuerdo con imágenes, información y comentarios que hayamos introducido en los viajes realizados. Además, los usuarios podrán consultar datos de los lugares visitados en cualquier momento, ya que todos los dispositivos Android disponen de acceso a Internet. También, esta aplicación añade nuevas funcionalidades para interactuar con sus datos. Ya que el objetivo de realizar un proyecto fin de carrera no es sólo la aplicación en sí, sino el paso de estudiante a ingeniero, la estructura del documento sigue una línea temporal, dónde se explica al inicio del mismo los pasos previos que cualquier Ingeniero Informático debe realizar antes de comenzar la implementación, y concluyendo con las ideas y reflexiones obtenidas tras su finalización, tanto sobre la aplicación como a nivel personal en la etapa final como estudiante. Como último aspecto importante, este trabajo ha servido como primera toma de contacto con el mundo laboral, además de como finalización del ciclo de formación universitaria.
6
2.
Definición de Objetivos
7
Hoy en día es cada vez más habitual el uso de Internet, del GPS y la cámara en un dispositivo móvil, aunque alguna de estas opciones puede que ya se encontraran hace unos años en los móviles, incluso todas ellas, ha sido con la llegada de los smartphone cuando la usabilidad ha sufrido una mejora considerable, gracias sobre todo a las prestaciones de los dispositivos móviles con la introducción de procesadores de última generación, incluso saliendo los últimos con varios núcleos, lo que permite que el hardware instalado en los móviles haya obtenido una mejora considerable. Debido a esta mejora vimos interesante usar estas opciones para crear una aplicación que permitiera unir todas ellas, con la finalidad de mejorar la organización y el acceso a la información que un usuario haya obtenido de un viaje. El objetivo principal de este proyecto es desarrollar una aplicación que permita al usuario realizar un diario de viaje que organice la información recopilada por el usuario para así tener un recuerdo en su dispositivo móvil, introduciendo fotos y enlaces a wikipedia del lugar visitado, a la vez que podemos añadir comentarios. Para ello utilizamos la cámara de fotos, GPS y acceso a internet con los que cuentan estos dispositivos. La aplicación nos ayudará a localizar en el mapa algún lugar visitado previamente, y ver las imágenes capturadas con sus respectivos comentarios, leyendo toda la documentación enlazada con la Wikipedia, para así, dar la máxima facilidad posible al usuario que desee ver los viajes que ha realizado. En los primeros compases del diseño, hemos partido de varias ideas desde las cuales desarrollar el resto. En primer lugar, queríamos hacer uso de algunas de las funciones propias de este tipo de teléfonos. Para ello, partimos de la idea de otorgar una gran importancia al GPS que incluyen la mayoría de smartphones actualmente a la venta, así como hacer uso de Internet y la cámara. Partimos de la idea de ofrecer un producto simple e interesante desde el punto de vista del público. En primer lugar, tras comentar la aportación que se ha realizado y analizar temporalmente el Proyecto, se verán algunas características de los dispositivos móviles que hemos utilizado durante el proyecto y que usan la plataforma Android , como son el Samsung I5800 Galaxy 3 y el HTC Wirefire S. Dispondremos de una completa guía de instalación de Eclipse y su SDK (kit de desarrollo de software) y, asimismo, explicaremos como instalar el plugin ADT en Eclipse o en el entorno de desarrollo que estemos utilizando, necesario para empezar a crear aplicaciones propias en Android . Después, se explicarán cada uno de los artilugios que usaremos en nuestro proyecto y de los cuales está dotado el dispositivo, como puede ser el caso del GPS y la cámara, entre otros, y de qué forma se hace uso de ellos.
8
Para finalizar, se explicará la complejidad de desarrollar el diario de viaje y cómo a través de la cámara del teléfono móvil y el GPS, podremos localizar los distintos puntos visitados. Una vez explicado, se mostrará el resultado de probarlo en nuestro dispositivo móvil. Respecto a los objetivos personales, teniendo en cuenta que el mundo de la informática está en continua evolución, se busca aprender a utilizar las nuevas tecnologías puesto que aunque se termine la etapa de estudiante, un informático va a estar aprendiendo a usar nuevos lenguajes de programación o tecnologías durante toda su vida laboral. En este caso, el objetivo personal es aprender a programar para una plataforma en la que no se ha trabajado durante la carrera, dado que Android es un sistema operativo muy reciente en el que aún no se ha profundizado a nivel académico. Además Android es uno de los sistemas operativos móviles con mayor cuota de mercado dentro de los dispositivos móviles, aun siendo uno de los últimos en ser lanzados, lo que demuestra su buena adaptación dentro de este mundo móvil y pensamos que podría ser una buena salida laboral en este mercado tan competitivo que hay en estos momentos, por lo que también fue un aliciente por el cual nos decidimos a programar con esta plataforma.
9
3. Análisis de antecedentes y aportación realizada
10
Para la realización del Proyecto, se empieza recolectando cierta información de un manual de Introducción a Android con el título “Cur so programación A ndroi d ” (Salvador Gómez Oliver) al que se hace referencia en la bibliografía, ya que ninguno de nosotros había programado previamente con Android y no conocíamos los conceptos básicos ni la forma de comenzar la aplicación. Consideramos este manual lo suficientemente completo como para iniciarnos en Android , puesto que abarca todos los temas necesarios para empezar a desarrollar un aplicación en esta plataforma. Además de ello, este manual tocaba temas importantes para nuestra aplicación como “Localización geográfica” y “Mapas”, y aunque estos estaban desarrollados de una forma muy básica y el manual no toca otros temas que son base de nuestra aplicación, como la utilización de la cámara, ha sido imprescindible para nosotros en el desarrollo del proyecto gracias a la base que hemos obtenido sobre el desarrollo de aplicaciones Android . Pero nuestra gran fuente de información aportada ha sido Internet. Una buena parte de la documentación del proyecto ha sido recolectada de diversas webs y, aunque en la bibliografía están señaladas dichas páginas, hay que destacar http://developer.Android.com , por su amplio contenido e información que permite conocer bien como funciona Android y su API, tanto para los que estén empezando como para los que tengan algún conocimiento previo. Para poder devolver la localización de un punto de interés donde estemos, así como su información complementaria, veremos que el SDK de Android sirve de gran ayuda, y que haciendo uso de GoogleMaps (que será muy útil y necesario en nuestro proyecto) hace que programar esta aplicación, a pesar de su dificultad, sea un poco más ameno. Toda la información recolectada en internet y de los distintos libros consultados nos ha ayudado para aprender este lenguaje de programación nuevo para nosotros y saber cómo funciona, pero una vez que se obtienen estos conceptos bases, parte del código que se utiliza para desarrollar la aplicación ha sido ingeniada por nosotros para que se ajuste a la idea que diseñamos. Por supuesto no hemos creado la aplicación desde cero, se han utilizado trozos de código obtenido de las distintas fuentes de información que hemos consultado, pero sí que hemos ideado gran parte de la aplicación cuyo código esta implementado por nosotros (con esto no queremos decir que estas acciones no estén implementadas ya, si no que en nuestro caso las hemos implementado nosotros desde nuestras propias ideas para que se ajusten a nuestra aplicación). Por tanto, como creemos que sucede con cualquier proyecto informático, la aplicación ha sido desarrollada usando código de terceros y código implementado por nosotros para así poder llevar a cabo este proyecto de final de carrera.
11
4. Análisis temporal y de costes de desarrollo
12
4.1. Planificación En este apartado se ha analizado el tiempo dedicado a la realización del proyecto. Se especificará cuánto tiempo hemos estado investigando acerca del funcionamiento de Android , cuánto nos ha costado realizar la aplicación que hemos llevado a cabo en este Proyecto, el tiempo dedicado a escribir la memoria junto con los distintos manuales de uso que ésta incluye, así como las pruebas realizadas para comprobar que la aplicación funcionaba correctamente. Este proyecto fue iniciado a partir de Octubre de 2011. Estuvimos 2 meses realizando tareas de investigación. También instalamos las versiones del SDK de Android y empezamos a ver cómo funcionaban las aplicaciones de los primeros ejemplos más sencillos, como el típico “H ell o, Android ”. Debido a las prácticas de empresa que en ese momento hacíamos los dos y la cercanía de los exámenes de la convocatoria de Diciembre, se tuvo que aplazar un poco la realización del proyecto. A principio de Febrero y tras una documentación exhaustiva y que se detallará en la Bibliografía, comenzamos a desarrollar las primeras aplicaciones mas decentes en Android . Es necesario destacar que en ningún momento hemos dejado de documentarnos. Así mismo, aparte de ir anotando las horas dedicadas grupal e individualmente, se iban dando pinceladas a la realización de la memoria, anotando enlaces para la bibliografía y comentando el código de las aplicaciones básicas que realizamos. A comienzos de Marzo, y una vez aclarados algunos conceptos sobre los cuales teníamos dudas a la hora de implementar, la aplicación empezó a tomar una base sólida. Durante los meses de Abril, Mayo y Junio se realizó la parte importante de la aplicación, y se amplió de manera considerable todo el trabajo de investigación. Igualmente, se escribieron los manuales de usuario que contiene la memoria, tanto del uso de Android en general como de nuestra aplicación en particular, y de cómo realizar aplicaciones para este sistema operativo de Google. Sin lugar a dudas, nuestra experiencia nos dice que a pesar de la numerosa documentación que habíamos consultado, y del conocimiento de la herramienta, tiene un lugar importante la corrección de fallos en cuanto a tiempo se refiere. Una vez que la aplicación estaba casi lista, nos costó bastante tiempo la tarea de depurar el código y retocarlo de forma que consiguiera mostrar resultados óptimos. A continuación mostramos gráficamente los tiempos dedicados a cada apartado de este proyecto, desde todo el trabajo de investigación, hasta la realización de la documentación del mismo. En total, aproximadamente 345 horas de trabajo cada uno repartidas de la siguiente forma:
13
Tarea
Horas estimadas
Horas reales
Investigación Desarrollo de la aplicación Memoria Pruebas Total
220 280 90 30 620
270 300 110 15 695
Horas estimadas
Investigación Desarrollo de la aplicación Memoria Pruebas
Horas reales
Investigación Desarrollo de la aplicación Memoria Pruebas
4.2. Herramientas para el desarrollo El coste de nuestro proyecto ha sido nulo, debido a que ya teníamos cada uno un móvil con sistema operativo Android , un equipo para desarrollar la aplicación y todas las herramientas que hemos empleado para el desarrollo del software son de libre adquisición.
14
4.2.1. Equipos de desarrollo Hemos usado distintos equipos para las distintas fases del proyecto. Tanto las labores de implementación, como las de documentación, están sincronizadas a través de internet, por lo que no hemos tenido ningún tipo de problema para mantener la coherencia de las distintas fases. Los equipos usados son:
Equipo1:
CPU RAM Targeta gráfica Sistema Operativo
Intel Pentium M 760 processor (2.0 GHz, 533MHz FSB, 2MB L2 cache) 2GB DDR2 Intel Graphics Media Acelerator 900 Windows XP Profesional
Equipo2:
CPU RAM Targeta gráfica Sistema Operativo
Core i5-2410M (2,30 / 2,90 GHz Turbo , FSB 1333 MHz, 3 MB L2) 4GB DDR3 (1333MHz) Intel HD 3000 (HM65), hasta 1.696 MB Windows7 64bit Home Premium
4.2.2. Eclipse + Android SDK El conocido entorno de desarrollo supone la mejor herramienta para programar en Android , debido a su fuerte orientación JAVA. Incluye todas las librerías necesarias para el desarrollo de aplicaciones, así como una máquina virtual configurable para probar el funcionamiento. Si se emplean dispositivos físicos, el propio Eclipse puede instalar y ejecutar la aplicación mediante una simple conexión USB, ofreciendo además todo tipo de herramientas para facilitar la programación, localizar errores, etc. Además, es completamente gratuito y de código abierto.
Más información en: http://www.eclipse.org/ http://developer.Android.com/sdk/index.html
15
4.2.3. Dropbox Dropbox es un servicio de alojamiento de archivos multiplataforma en la nube, operado por la compañía Dropbox. El servicio permite a los usuarios almacenar y sincronizar archivos en línea entre computadoras, y compartir archivos y carpetas con otros usuarios.
Más información en: http://www.dropbox.com
4.2.4. Dispositivos físicos El uso de la máquina virtual incluida en Eclipse no permite la manipulación de los sensores, además el rendimiento de las aplicaciones queda muy por debajo del que se obtiene al ejecutarlo en un dispositivo real. Debido a esto, para el desarrollo de este proyecto hemos adquirido dos Smartphones de gama alta y diferente hardware para poder hacer las pruebas pertinentes. Ambos están actualizados al sistema operativo Android 2.2. Las especificaciones de ambos dispositivos, las hemos obtenido en la web http://www.gsmarena.com/ y son las siguientes:
Samsung I5800 Galaxy 3
2G Network 3G Network General Announced Status Dimensions Body Weight Type Size Display Multitouch
GSM 850 / 900 / 1800 / 1900 HSDPA 900 / 2100 2010, June Available. Released 2010, July 113.5 x 55 x 12.9 mm 109 g TFT capacitive touchscreen, 16M colors 240 x 400 pixels, 3.2 inches (~146 ppi pixel density) Yes - Touch Wiz 3.0 Vibration; MP3, WAV ringtones Yes Yes - DNSe (Digital Natural Sound Engine) microSD, up to 32GB, 1GB card included 512MB ROM, 256MB RAM Class 10 (4+1/3+2 slots), 32 - 48 kbps Class 10, 236.8 kbps HSDPA, 3.6 Mbps
16
WLAN Bluetooth USB Primary Features Camera Video Secondary OS CPU Sensors Messaging Browser Radio GPS Java Features Colors
Battery
Stand-by Talk time
Wi-Fi 802.11 b/g/n, Wi-Fi hotspot ( Android 2.2) Yes, v3.0 with A2DP Yes, microUSB v2.0 3.15 MP, 2048x1536 pixels, autofocus Geo-tagging, face and smile detection Yes, QVGA@15fps No OS, v2.1 (Eclair), upgradable to v2.2 Android Samsung S5P6422 667 MHz Accelerometer, proximity, compass SMS(threaded view), MMS, Email, Push Mail, IM HTML Stereo FM radio with RDS Yes, with A-GPS support Yes, via Java MIDP emulator Black, White - MP4/DivX/XviD/WMV/H.264/H.263 player - MP3/WAV/eAAC+ player - Organizer - Document editor (Word, Excel, PowerPoint, PDF) - Google Search, Maps, Gmail, YouTube, Calendar, Google Talk integration - Voice memo - Predictive text input Standard battery, Li-Ion 1500 mAh Up to 620 h (2G) / Up to 510 h (3G) Up to 15 h 30 min (2G) / Up to 7 h 15 min (3G)
HTC Wildfire S 2G Network 3G Network
General
Body
Announced Status Dimensions Weight
Display
Type Size
Alert types Sound Loudspeaker 3.5mm jack Card slot Memory Internal GPRS EDGE Data Speed
GSM 850 / 900 / 1800 / 1900 HSDPA 900 / 2100 HSDPA 850 / 1900 or HSDPA 2100 (Australia) 2011, February Available. Released 2011, May 101.3 x 59.4 x 12.4 mm 105 g - Touch-sensitive controls TFT capacitive touchscreen, 256K colors 320 x 480 pixels, 3.2 inches (~180 ppi pixel density) - HTC Sense 2.1 UI Vibration, MP3, WAV ringtones Yes Yes microSD, up to 32GB, 2GB included 512 MB ROM, 512 MB RAM (418 MB user-available) Up to 114 kbps Up to 560 kbps HSDPA, 7.2 Mbps; HSUPA, 384 Kbps
17
WLAN Bluetooth USB Primary Features Camera Video Secondary OS Chipset CPU GPU Sensors Messaging Browser Radio GPS Features Java Colors
Battery
Stand-by Talk time
Wi-Fi 802.11 b/g/n, Wi-Fi hotspot Yes, v3.0 with A2DP, EDR Yes, microUSB v2.0 5 MP, 2592 x 1944 pixels, autofocus, LED flash Geo-tagging, face detection Yes, VGA@24fps No OS, v2.3 (Gingerbread), upgradable to v2.3.5 Android Qulacomm MSM7227 600 MHz ARM 11 Adreno 200 Accelerometer, proximity, compass SMS(threaded view), MMS, Email, Push Email, IM HTML Stereo FM radio with RDS Yes, with A-GPS support Yes, via Java MIDP emulator Black, Silver, Brown, Lilac - SNS integration - Google Search, Maps, Gmail - YouTube, Google Talk, Picasa integration - MP3/AAC+/WAV player - Xvid/MP4/H.264 player - Organizer - Voice memo - Predictive text input Standard battery, Li-Ion 1230 mAh Up to 360 h (2G) / Up to 570 h (3G) Up to 7 h 10 min (2G) / Up to 5 h 50 min (3G)
18
5. Manual de Android e instalación del entorno de trabajo
19
5.1. Introducción a Android Android es una pila de software de código abierto que incluye un sistema
operativo, middleware, y aplicaciones clave con una serie de librerías API para poder desarrollar aplicaciones a las cuales se les pueden dar la forma y el funcionamiento específico para que pueda funcionar en teléfonos móviles.
Hasta hace poco, poder desarrollar aplicaciones para teléfonos móviles era dificilísimo porque se programaban bajo sistemas operativos propios y entornos de desarrollo cerrados, a los cuales era imposible acceder. Así mismo, los propios terminales priorizaban las aplicaciones nativas, haciéndolas prevalecer frente a aplicaciones que se hayan desarrollado por terceras partes. Esto suponía una barrera infranqueable para los desarrolladores de este tipo de aplicaciones. En Android las aplicaciones tanto nativas como las desarrolladas por terceras partes son escritas usando la misma API y ejecutadas en las mismas condiciones. Es por ello que en Android todas las aplicaciones son iguales sin hacer ninguna distinción ni discriminación.
Históricamente, los desarrolladores codificaban sus aplicaciones en lenguajes de bajo nivel, para lo que era necesario entender el hardware específico sobre el que iban a trabajar, y generalmente solían ser un dispositivo sencillo o un rango de dispositivos provenientes del mismo fabricante. En la actualidad, los avances realizados en el desarrollo de aplicaciones para terminales móviles, han hecho que se pueda programar con un nivel de abstracción para que el programador se aísle de la capa hardware y no estar pendiente de ella. Entre las características del sistema operativo Android destacamos:
Todas sus aplicaciones se programan en lenguaje Java y son ejecutadas en una máquina virtual específica diseñada para esta plataforma. Todo su software se ha realizado bajo una licencia Apache, de modo que el código es de libre distribución. También una de las causas primordiales por las cuales se ha escogido una licencia Apache, es porque este tipo de licencia permite que se realicen modificaciones sobre el software inicial y una vez que se
20
realicen los oportunos cambios, no exige que el software alterado se distribuya como software libre. Permite a las operadoras modificar a su gusto la plataforma, añadir nuevas funcionalidades y no tener que compartir el código ni permitir su uso a terceros. Así, de este modo, se puede entender como algunos operadores y fabricantes hayan visto con buenos ojos esta iniciativa y es por ello que se hayan sumado a Android . La principal causa de esta adhesión es que dichas compañías podrán modificar el código y desarrollar todo tipo de aplicaciones o trabajos sin la necesidad de verse obligados a compartir todo la elaboración producida. De todas formas, la licencia Apache propuesta por Android , permite que cualquier persona se pueda descargar, acceder al código fuente, modificarlo y redistribuirlo pero con el ligero inconveniente que a cualquier persona se le exime de este último punto.
A cualquier desarrollador que se plantee programar sobre esta plataforma, se le proporciona de forma totalmente gratuita un entorno de desarrollo, es decir una SDK que se puede instalar junto con un plug-in en uno de los IDE´s más famosos y conocidos como es Eclipse. Además se integra un emulador en el cual se pueden realizar todo tipo de pruebas sobre el programa elaborado y sí éstas han salido satisfactorias se puede importar el proyecto elaborado al propio dispositivo móvil.
La principal finalidad que busca Android desde el punto de vista del desarrollador, es que éste pueda sacar de sí lo mayor posible de la plataforma, poder controlar y aprovechar cualquier funcionalidad que se proporcione desde el sistema operativo, y que toda aplicación que se pueda crear sea portable, fácil de desarrollar y reutilizable. Con todo ello, se intenta buscar un estándar para el desarrollo de este tipo de aplicaciones. Por último, cabe destacar la gran facilidad que desde Android se ofrece para poder integrar todo tipo de aplicación con las aplicaciones Web de Google.
5.2. Breve historia En Julio de 2005, Google adquirió Android, Inc [37], una pequeña startup de California. En esos momentos, la compañía se dedicaba a la creación de software para teléfonos móviles. Una vez en Google, el equipo desarrolló un S.O. basado en Linux para dispositivos móviles. Más adelante, Google adaptó su buscador y sus aplicaciones para su uso en móviles. En septiembre del 2007, Google tenía varias patentes de aplicaciones sobre el área de la telefonía móvil. El 5 de noviembre del mismo año, se anunció la fundación de la Open Handset Alliance al mismo tiempo que la creación de la plataforma Android. La Open Handset Alliance está formada por un consorcio de 34 compañías de hardware, software y telecomunicaciones, entre las cuales se incluyen Google, HTC [38], Intel [39] y Motorola [40] entre otras, dedicadas a investigar estándares abiertos para dispositivos móviles. El primer teléfono en el mercado que posee Android es el T-Mobile G1 [41] (también conocido como Dream), lanzado el día 22 de octubre de 2008 que viene con la versión Android 1.0 preinstalada. Este móvil es el resultado conjunto de T-Mobile, HTC
21
y Google. Por último, desde el 21 de octubre de 2008, Android está disponible como código abierto [42]. Gracias a esto, cualquiera puede añadir extensiones, nuevas aplicaciones o reemplazar las existentes por otras dentro del dispositivo móvil
5.3. Estructura de Android El stack de software a grandes rasgos, está formado por: un núcleo de Linux, una serie de librerías escritas en código C/C++, un entorno de ejecución propio ( Android Run Time), un framework de aplicaciones y las propias aplicaciones. A continuación se puede ver el esqueleto de este sistema operativo, y debajo de la misma se explicarán cada una de las partes que lo conforman.
La estructura del sistema operativo es la siguiente:
El núcleo de Linux: es la capa más baja situada y es donde se sitúan los servicios básicos, es decir, en esta capa se establecen los drivers del hardware, la gestión de procesos y memoria, la seguridad, y las gestiones de redes y de energía. Todo ello está manejado por un kernel de Linux con versión 2.6, y cuya función principal es abstraer a las diferentes capas sucesivas que soporta la estructura de Android del hardware de la máquina. Aparte de las propiedades que puede dar dicho kernel de Linux, también hay que decir que precisamente dicho núcleo, incluye diversos drivers lo cual le hace semejante a cualquier otro kernel que corre en un ordenador personal. Por
22
otro lado, este kernel, al ser Linux cumple con las expectativas con las que Android se lanzará bajo licencia Apache.
Por encima del núcleo de Android se establecen una serie de librerías escritas en lenguaje C/C++, y al igual que el núcleo, estas librerías son iguales de básicas. Dentro de las librerías, las más importantes son las siguientes: o Libc: esta librería incluye todas las cabeceras y funciones según el
estándar de C.
o SQLite: es la librería que implementa un motor de base de datos. SQLite
es software libre, por lo tanto el código fuente es de dominio público.
o Surface Manager (Administrador de Superficies): es la que realiza toda la
gestión del acceso a los subsistemas de pantallas. Además es la encargada de gestionar todas aquellas pantallas de las diferentes aplicaciones activas que se encuentren en ese preciso instante.
o SSL & WebKit: ambas librerías son las encargadas de integrar un
navegador para Internet y de proporcionar seguridad cuando se acceda a ésta.
o Media: el principal uso de esta librería es para poder reproducir tanto
archivos de audio o video, así como los archivos fotográficos. Cabe destacar que en esta librería se proporcionan los códecs necesarios para poder reproducir los formatos más populares.
o OpenGL / ES y SGL: la última libre, la SGL, es la encargada de
proporcionar el motor gráfico de 2D. Sin embargo, la OpenGL / ES maneja los gráficos 3D en el caso de que el hardware del teléfono móvil lo disponga.
o FreeType: es la encargada de la renderización de fuentes, para mapas de
bits y vectores.
La siguiente capa, y que se sitúa en el mismo nivel que la anterior, es el entorno Run Time. Android de ejecución de Android , o la Android incluye un set de librerías base que proveen la mayor parte de las funcionalidades disponibles en
23
las librerías base del lenguaje de programación Java. Todas las aplicaciones se programan en Java y para poder ejecutarlas se ha creado específicamente para Android una máquina virtual, la Dalvik Virtual Machine. Lo particular de esta máquina virtual, es que ha sido especialmente optimizada y adaptada para las características de cualquier teléfono móvil. Cada aplicación Android corre su propio proceso, con su propia instancia en la máquina virtual Dalvik. Esta máquina virtual, ha sido escrita de forma que un dispositivo puede correr múltiples máquinas virtuales de forma eficiente. Dalvik ejecuta archivos en el formato Dalvik Executable (.dex), y no con el bytecode generado por Java, de forma que los .dex están optimizados para un uso mínimo de la memoria y pensados para procesadores pequeños. Dicha máquina virtual está basada en registros, y ejecuta las clases compiladas por el compilador Java y que se han transformado en el formato .dex por la herramienta “dx”. Para hacernos una idea
real de lo que sucede, y de la eficiencia de esta máquina virtual, se va a explicar un poco como se realiza todo el proceso. Una vez que se genera el bytecode de la aplicación escrita en Java, es decir, una vez que obtenemos los .class la máquina virtual genera un .dex con toda la agregación de estos códigos objeto, por hacer un símil sencillo, un .dex podría asemejarse a un archivo jar.
La penúltima capa dentro de la estructura del sistema operativo Android es la del Framework de Aplicaciones . A partir de aquí, las últimas capas de la plataforma, se sustentan sobre Java. En esta capa se proporcionan todas las clases necesarias para poder crear aplicaciones en Android . Del mismo modo, este framework proporciona un nivel de abstracción del acceso al hardware y la gestión de la interfaz del usuario y de los recursos de la aplicación. Los desarrolladores tienen acceso a las mismas API´s que las aplicaciones base, con el único objetivo de poder reutilizar los componentes utilizados para la aplicación realizada. En cuanto a las API´s más conocidas son las siguientes: o Administrador de Teléfono: destinada para que el desarrollador pueda
interactuar con las funcionalidades del teléfono, como son los mensajes SMS, llamadas,…
o Proveedor de Contenidos: con esta API, se pueden compartir los datos de
cualquier aplicación.
o Administrador de Ubicaciones: permite que las aplicaciones obtengan
información sobre la localización y posicionamiento de ésta.
o Administrador de Actividad: es la API encargada de gestionar el ciclo de
vida de las aplicaciones.
o Administrador de Ventanas: con ella se pasan a gestionar las ventanas de
las aplicaciones.
o Vista del Sistema: es con la cual se realiza toda la interfaz de usuario.
24
o La capa de Aplicaciones es la última capa del software, en la que se encuentran tanto las aplicaciones nativas provistas por Android como las
desarrolladas por terceras partes. Todas ellas, han sido construidas en esta capa y utilizando las mismas API´s y bajo el mismo lenguaje de programación, Java.
5.4. Estructura de una aplicación Android Para empezar a comprender cómo se construye una aplicación Android vamos a echar un vistazo a la estructura general de un proyecto tipo. Cuando creamos un nuevo proyecto Android en Eclipse se genera automáticamente la estructura de carpetas necesaria para poder generar posteriormente la aplicación. Esta estructura será común a cualquier aplicación, independientemente de su tamaño y complejidad. En la siguiente imagen vemos los elementos creados inicialmente para un nuevo proyecto Android:
En los siguientes apartados describiremos los elementos principales de esta estructura. Carpeta /src/
Contiene todo el código fuente de la aplicación, código de la interfaz gráfica, clases auxiliares, etc. Inicialmente, Eclipse creará por nosotros el código básico de la pantalla (Activity) principal de la aplicación, siempre bajo la estructura del paquete java definido.
25
Carpeta /res/
Contiene todos los ficheros de recursos necesarios para el proyecto: imágenes, vídeos, cadenas de texto, etc. Los diferentes tipos de recursos de deberán distribuir entre las siguientes carpetas:
Carpeta
Descripción
/res/drawable/
Contienen las imágenes de la aplicación. Para utilizar diferentes recursos dependiendo de la resolución del dispositivo se suele dividir en varias subcarpetas:
/res/layout/
Contienen los ficheros de definición de las diferentes pantallas de la interfaz gráfica. Para definir distintos layouts dependiendo de la orientación del dispositivo se puede dividir en dos subcarpetas:
Contiene la definición de las animaciones utilizadas por la aplicación. Contiene la definición de los menús de la aplicación. Contiene otros recursos de la aplicación como por ejemplo cadenas de texto ( strings.xml ), estilos ( styles.xml ), colores (colors.xml ), etc. Contiene los ficheros XML utilizados por la aplicación. Contiene recursos adicionales, normalmente en formato distinto a XML, que no se incluyan en el resto de carpetas de recursos.
Como ejemplo, para un proyecto nuevo Android, se crean los siguientes recursos para la aplicación:
26
Carpeta /gen/
Contiene una serie de elementos de código generados automáticamente al compilar el proyecto. Cada vez que generamos nuestro proyecto, la maquinaria de compilación de Android genera por nosotros una serie de ficheros fuente en “java ” dirigidos al control de los recursos de la aplicación.
El más importante es el que se puede observar en la imagen, el fichero R.java, y la clase R . Esta clase R contendrá en todo momento una serie de constantes con los ID de todos los recursos de la aplicación incluidos en la carpeta /res/, de forma que podamos acceder fácilmente a estos recursos desde nuestro código a través de este dato. Así, por ejemplo, la constante R.drawable.icon contendrá el ID de la imagen “icon.png ” contenida en la carpeta /res/drawable/. Veamos como ejemplo la clase R creada por defecto para un proyecto nuevo:
public final class R { public static final } public static final public static } public static final public static } public static final public static public static } }
class attr { class drawable { final int icon=0x7f020000; class layout { final int main=0x7f030000; class string { final int app_name=0x7f040001; final int hello=0x7f040000;
27
Car peta /assets/
Contiene todos los demás ficheros auxiliares necesarios para la aplicación (y que se incluirán en su propio paquete), como por ejemplo ficheros de configuración, de datos, etc. La diferencia entre los recursos incluidos en la carpeta /res/raw/ y los incluidos en la carpeta /assets/ es que para los primeros se generará un ID en la clase R y se deberá acceder a ellos con los diferentes métodos de acceso a recursos. Para los segundos sin embargo no se generarán ID y se podrá acceder a ellos por su ruta como a cualquier otro fichero del sistema. Usaremos uno u otro según las necesidades de nuestra aplicación. F ichero AndroidM anifest.xml
Contiene la definición en XML de los aspectos principales de la aplicación, como por ejemplo su identificación (nombre, versión, icono, …), sus componentes (pantallas, mensajes, …), o los permisos necesarios para su ejecución. Veremos más
adelante más detalles de este fichero. En el siguiente apartado veremos los componentes software principales con los que podemos construir una aplicación Android.
A la hora de construir una aplicación en Android , hay que tener en cuenta que dicha aplicación puede estar compuesta de un tipo específico de componente o de la combinación de ambos. Estos componentes son los que van a identificar y caracterizar a la aplicación que se llegue a crear, ya que en función de éstos la clase que se desarrolle heredará las características del componente, y por lo tanto pueden existir diferentes formas de comportamiento, en cuanto a la aplicación se refiere, según el tipo de componente que se decida a usar. Los diferentes tipos de componentes con los cuales podemos crear aplicaciones en Android son los siguientes:
Activity Es el componente más importante en cualquier aplicación Android , debido principalmente a que es la capa de presentación para todo tipo de aplicación. Cualquier pantalla que se muestre al usuario, será una extensión de la clase Activity. Y para dicha presentación se sirve de Views, para poder realizar la interfaz con la cual el usuario podrá interactuar. Está clase puede ser equivalente a lo que es un formulario en la arquitectura web.
28
Services Este componente, es totalmente opuesto al anteriormente explicado. La clase Services al contrario que la Activity, no interactúa para nada con el usuario, y es completamente invisible a los ojos del usuario. Se puede decir prácticamente, que este componente “corre” por debajo, en un segundo plano,
realizando cualquier tipo de procedimiento que está obligado a realizarse sin la necesidad de que sea visible al usuario. La clase Service por así decirlo, son las clases que se ejecutan en background.
Content Provider Los Content Provider , son principalmente utilizados para gestionar y almacenar las bases de datos de la aplicación. También permiten que cualquier aplicación almacenen los datos en un fichero o cualquier otro formato. La gran ventaja que presenta este tipo de componente, es que permite a cualquier aplicación acceder a los datos que están siendo utilizados por otras aplicaciones a la vez.
Intent Un Intent , es un simple mensaje, que se utiliza para determinar el objetivo de la aplicación, es decir, su propósito. La principal peculiaridad es la forma en la cual los Intent describen la tarea que se va a llevar a cabo y los datos necesarios para realizarla. En última instancia, es el sistema el que finalmente decide cual será el más indicado para realizar sus acciones. Este componente, está muy ligado al Activity , puesto que las Activities, realizan los cambios de vista o de interfaz por medio de los Intent .
Broadcast Receivers Con esta clase, la aplicación que se crea, está a la escucha de cualquier Intent proveniente de distintas aplicaciones. Al utilizar este componente, la aplicación puede empezar automáticamente y responder al Intent que está a la escucha. Se puede decir que la aplicación está a la escucha de un evento para llevar a cabo la acción a la cual está predestinada. Generalmente las aplicaciones que utilizan esta clase, se utilizan para lanzar eventos provenientes de cualquier tipo de Intent . Un claro ejemplo puede ser la gestión de las llamadas entrantes que recibe el dispositivo móvil.
5.5. Ciclo de vida de una aplicación en Android Los componentes que forman las aplicaciones en Android , tienen bien definido un ciclo de vida de manera que se puede saber en cualquier momento en que estado está la aplicación para poder gestionar los flujos de ésta en función de su estado.
29
A la hora de ejecutar una aplicación en Android , ésta se lleva a cabo en su propio proceso, de tal modo que Android es el encargado de gestionar todas las aplicaciones, arrancarlas o pararlas en función de los recursos que la aplicación necesite. Android aísla totalmente al usuario del dispositivo de la labor que el sistema
operativo está realizando para poder ejecutar la aplicación que el poseedor del teléfono desee. Android ejecutará tantos procesos en función de los recursos que tenga disponibles, los cuales pueden estar a la vez formados por más de una actividad ( Activity).
A diferencia de otros entornos, las aplicaciones en Android , no tienen el control sobre su propio ciclo de vida. En cambio, los componentes de los que está formada dicha aplicación están al tanto de los cambios de estado que ésta pueda generar. De modo que durante la ejecución puede suceder que una actividad pare mientras otra sea lanzada, de tal manera que el proceso es consciente del estado en cual se ha quedado para que en un futuro vuelva a dicho estado cuando el sistema le conceda el mando. El caso más conocido de ciclo de vida, es el del componente Activity, cuyo diagrama es el siguiente:
30
Como se puede observar en la figura anterior, los diferentes estados que conforman el ciclo de vida de una actividad son los siguientes:
onCreate: Es el estado en el cual da comienzo el ciclo de vida de la aplicación.
onDestroy: Estado en el que se da por finalizado el ciclo de vida.
onStart: Junto con el estado onStop forman el conjunto de estados en los cuales se maneja la actividad desde su comienzo. onStop: Es el estado en el cual permanece la actividad cuando ésta no tiene el mando para realizar sus procesos. Es similar al estado onPause.
31
onPause: Similar al estado anteriormente descrito. La actividad permanece en este estado cuando ésta no recibe el foco de atención por parte del sistema. onResume: Al igual que el estado onPause, ambos estados acotan el ciclo de vida de la actividad en función del foco de atención dispensado a la aplicación.
5.5.1. Prioridad de procesos Una vez visto el ciclo de vida de una aplicación en Android , y concretamente cuando una aplicación se crea, su flujo concluye cuando ésta finalice o cuando otra actividad necesite los recursos que la aplicación está consumiendo. La preferencia por parte de Android a la hora de priorizar determinadas aplicaciones en función de otras se debe en gran parte al tipo de componente que lo forma, ya que una aplicación puede ser más prioritaria respecto de otra. A la hora de programar una aplicación hay que tener en cuenta la prioridad que se le va a asignar puesto que en función de la prioridad la aplicación puede morir durante un proceso de ejecución importante. La importancia en cuanto a procesos se refiere es la siguiente, de mayor a menor prioridad: 1. Procesos activos. Son los procesos cuya importancia es crítica. Son aquellos que están albergados en aplicaciones que están continuamente estableciendo contacto con el usuario, y que generalmente son liquidados en última estancia. Este tipo de prioridad corresponde a: que se encuentran en un estado activo y que están respondiendo continuamente a eventos del usuario.
Activities
Activities, Services
o Broadcast Recivers, que se están ejecutando cuando
reciben un evento.
Componentes Services que se ejecutan tras un evento proveniente de una aplicación que se crea, comienza o se destruye.
2. Procesos visibles. Como su propio nombre indica, son componentes de tipo Activity que son visibles pero no están al mando. En extraños casos son matadas. 3. Procesos de servicio. Son aquellas aplicaciones cuyo principal componente de aplicación es un Service, y tienen menor prioridad que un Activity, en gran parte a que este tipo de procesos no están continuamente interactuando con el usuario y a que son consideradas actividades que transcurren en un segundo plano. Este tipo de procesos no son matados a menos que sean necesarios los recursos de los que dispone.
32
4. Procesos de segundo plano. A diferencia de los anteriores, son procesos que corren en un segundo plano y que no disponen de ningún servicio. 5. Procesos vacíos. Son aquellos procesos que se mantienen en cache para un posterior relanzamiento. relanzamiento.
5.6. Herramientas para el desarrollo En este apartado se va a comentar las herramientas y los pasos necesarios para poder desarrollar aplicaciones aplicaciones en Android . Es necesario conocer el sistema operativo así como el procesador sobre el cual se va a instalar el conjunto de herramientas necesarias. Este procedimiento es importante porque a la hora de instalar la SDK de Android , existen una serie de necesidades que no hay que pasar por alto. La SDK de Android es totalmente compatible con los principales sistemas operativos que existen en el mercado, es decir, Windows, Mac y Linux. A continuación es necesario disponer de una JDK, disponer a su vez del IDE de desarrollo Java Eclipse. Procedimientos para instalar las herramientas.
5.6.1. Instalación de Eclipse Si nuestro PC no dispone de un entorno de desarrollo compatible con Android SDK, recomendamos descargar Eclipse 3.4 (Ganymede), en la web oficial de Eclipse: http://www.eclipse.org/downloads.. http://www.eclipse.org/downloads No nos vamos a parar mucho en cómo instalar Eclipse ya que no es la finalidad de nuestro proyecto, simplemente vamos a explicar los pasos básicos para tenerlo funcionando en nuestro equipo.
33
Seleccionamos Eclipse Classic 3.7.2 para Windows, Linux o Mac, dependienfo del Sistema Operativo que tengamos y nos los descargamos en nuestro equipo. Descomprimimos el archivo .zip en el directorio que hemos seleccionado y ejecutamos el archivo eclipse.exe que se encuentra en la carpeta eclipse descomprimida. Finalmente, elegimos un espacio de trabajo donde elaborar nuestros proyectos.
5.6.2. Instalar SDK Android Bien, una vez que hemos cumplido los requisitos del apartado anterior, nos dirigimos al website dedicado para Android : http://developer.Android.com/sdk/index.html
Y una vez allí, nos descargamos la SDK en función de nuestro sistema operativo, bien puede ser Windows, Mac o Linux. A continuación, descomprimimos el archivo en cuestión, teniendo en cuenta la ruta en la cual se ha descomprimido dicho archivo. Concluido el proceso de instalación de la SDK, se procede a la instalación del plugin necesario necesario para Eclipse.
5.6.3. Instalar plugin de Android para Eclipse Ahora, el siguiente paso es iniciar Eclipse, para que de este modo podamos incluir el plugin necesario de Android , y así incluir la herramienta ADT ( Android Development Tools) la cual permitirá crear proyectos de Android , debuggarlos y ejecutarlos. Help->Install New Software… y en la Abierto el IDE Eclipse, en la pestaña Help->Install ventana nueva que aparece, pulsar el botón Add.
34
De nuevo aparecerá una nueva ventana en la cual en los campos Name se pude introducir por ejemplo ADT y en el campo Location la siguiente URL: https://dl-ssl.google.com/Android/eclipse/
Y una vez realizado, pulsar el checkbox o el botón Select All y pulsar Next.
35
Y a partir de ahí comenzará a descargarse el software necesario para comenzar a desarrollar aplicaciones. Por último Eclipse pedirá que se reinicie, para poder configurar los cambios realizados.
5.6.4. Completar la instalación Tras reiniciar Eclipse, los siguientes pasos a realizar son:
Referenciar SDK
Para poder crear proyecto, debemos referenciar la SDK en la pestaña Windows>Preferentes->Android ->Browse ->Browse y buscar el path sobre el que se encuentra la SDK.
Y en último lugar pulsar Apply y Ok.
Descargar los targets necesarios
Además del SDK de Android , también debemos descargar los llamados SDK Targets de Android , que no son más que las librerías necesarias para desarrollar en cada una de las versiones concretas de Android . Así, si queremos desarrollar por ejemplo para Android 1.6 tendremos que descargar su target correspondiente. Para ello, desde 1.6 Eclipse debemos acceder al menú Window ->Android SDK Manager, y en la sección SDK Packages seleccionar e instalar todos los l os paquetes deseados.
36
Configurar emulador AVD y actualizar plugin
A la hora de probar y depurar aplicaciones Android no no tendremos que hacerlo necesariamente sobre un dispositivo físico, sino que podremos configurar un emulador Virtual Virtual Device, o AVD) donde poder realizar fácilmente o dispositivo virtual ( Android estas tareas. Para ello, nos vamos a Windows->ADV Manager y en la sección Virtual Devices podremos añadir tantos AVD como se necesiten (por ejemplo, configurados para distintas versiones versiones de Android ). ).
A continuación, pulsamos sobre el botón New, y aparecerá la siguiente ventana.
37
Para configurar el AVD tan sólo tendremos que indicar un nombre descriptivo, el target de Android que utilizará, y las características de hardware del dispositivo virtual, como por ejemplo su resolución de pantalla, el tamaño de la tarjeta SD, o la disponibilidad de GPS. Y por ultimo comenzará un proceso de actualización de la SDK.
38
5.6.5. Otras herramientas útiles Como bien se ha podido apreciar en el apartado anterior la SDK de Android , incluye diversas herramientas y utilidades que permiten al usuario poder crear, testear y analizar las propias aplicaciones. Otra herramienta que aporta la SDK es el emulador. El cual es una propia máquina virtual destinada a ejecutar las aplicaciones de Android , es por ello la manera más cercana de poder conocer cómo sería un dispositivo móvil con dicho sistema operativo. Éste a su vez, dispone de una variedad de posibles maneras de mostrarse como interfaz gráfica, es decir, dispone de distintos tamaños de pantalla, resoluciones. Además de proveer de una buena conexión a Internet, en cuanto a rapidez y latencia respecto a las aplicaciones, y de permitir recibir llamadas y SMS, obviamente simulados. Como añadido a las características anteriormente habladas, existe una funcionalidad que permite al emulador de Android contactar y realizar operaciones mediante una conexión Telnet. A través del puerto 5554 se puede entablar todo tipo de órdenes con el emulador. También existen otro tipo de funcionalidades no menos importantes pero que merecen la pena describirlas.
5.6.5.1.
Otras funcionalidades del emulador
Dentro del emulador, existe la posibilidad de poder utilizar imágenes que puedan simular memorias internas, flash o de otro tipo. Las diferentes tipos de imagen son los siguientes:
Imagen de sistema:
son el tipo de imagen necesaria para que el emulador pueda arrancar, de modo que sólo son de lectura y obtienen información sobre la manera de ejecutarse éste.
Imagen de runtime:
Imagen temporal:
a diferencia de las anteriores, éstas permiten escribir además de la posibilidad de leer de la imagen correspondiente. Y principalmente se utilizan para guardar datos de la sesión, como pueden ser aplicaciones instaladas. Al igual que las imágenes que simulan almacenamientos extraíbles. la característica principal de estas imágenes es que al acabar la ejecución, es decir, al apagar o cerrar el emulador, se eliminan por completo. Y la utilidad que tienen, es para hacer las labores de caché y para realizar una copia del sistema.
5.6.5.2.
Dalvik Debug Monitor Service
Aparte del emulador, existen otras herramientas que facilitan la programación de cualquier aplicación en Android . De estas herramientas cabe destacar la Dalvik Debug Monitor Service o DDMS.
39
En primera instancia, el emulador, te permite ver qué aspecto presenta la aplicación, cómo se comporta y poder interactuar con la misma, pero realmente no sabes lo que realmente está pasando dentro. De este modo, la DDMS es una herramienta que permite “debutar” la aplicación y conocer en todo momento que está sucediendo dentro de los entresijos de la aplicación que se está ejecutando. De esta manera, con esta herramienta, se tiene una versión fidedigna de la ejecución de la aplicación, porque se pueden acceder a los log, conocer de manera primordial la gestión de recursos, y la simulación de envío de SMS así como de llamadas entrantes y geolocalización. Para poder acceder a esta herramienta basta con pulsar la pestaña Window-> Open Perspectiva-> DDMS. Y aparecerá una perspectiva similar a la siguiente imagen:
5.6.5.3.
Android Debug Bridge
Para finalizar, la Android Debug Bridge o ADB, es una herramienta que mediante una arquitectura cliente servidor permite conectarte desde tu máquina al dispositivo Android . Esta herramienta te permite copiar archivos, instalar aplicaciones o ejecutar comandos para acceder a la shell. Para poder utilizar las utilidades que nos facilita esta herramienta, basta con acceder mediante la línea de comandos hasta el path en el que se encuentra la SDK, y acceder a la carpeta tools y una vez allí, ejecutar los posibles comandos.
40
De entre esos comandos, los más comunes son los siguientes:
adb shell: con este comando se puede acceder al directorio root del terminal y desde ese punto se podrán lanzar diversos comandos contra el dispositivo. Como por ejemplo, acceder al sistema para poder borrar las aplicaciones instaladas. adb push [local][remoto]: con este comando se pueden enviar archivos al dispositivo desde nuestra propia máquina. adb pull [remoto][local]: el comando contrario al anterior, con él, nos descargamos archivos desde el dispositivo a la máquina. adb install [path/aplicacion.apk]: con este comando, se permite instalar aplicaciones en el dispositivo, indicándole sólo la ruta desde donde se encuentra el paquete compilado de la aplicación(.apk). adb reboot: comando con el que se reinicia el emulador.
41
6.
Manual de usuario
42
6.1. Presentación del Proyecto “DIARIO DE VIAJE ” es una aplicación que está desarrollada para que el usuario
pueda almacenar información sobre un viaje que ha realizado y todos los lugares que ha visitado durante el viaje. El objetivo principal de la aplicación es que el usuario pueda documentar los viajes que realiza, tanto de forma escrita con comentarios, como de forma visual con fotografías y posiciones geográficas representadas en un mapa de los lugares en los que ha estado. En definitiva la idea es tener una aplicación que permita acceder fácilmente y tenga ordenada toda la información que el usuario ha guardado de un viaje. Conceptos básicos de la aplicación:
VIAJE: Periodo de tiempo continuo durante el cual el usuario se encuentra en un lugar o en varios lugares. LUGAR: Hace referencia a un sitio en concreto donde el usuario ha estado durante el viaje. Este concepto puede hacer referencia a monumentos, edificios, parques, restaurantes, museos,..., es decir todos aquellos lugares de interés que el usuario crea conveniente recordar durante el viaje o eventos que se han producido durante el viaje como el encuentro con unos amigos, estancia en un concierto, etc.
6.2. Ventana de la Lista de Viajes (Ventana Principal) Una vez se tiene instalada la aplicación en el móvil el usuario puede acceder a ella. La pantalla principal está dividida en dos partes, a las que se acceden desde las pestañas que se encuentra en la parte superior de la pantalla. L a pestaña “Viajes” muestra una lista de los viajes que el usuario ha realizado, tal como puede observarse en la figura 6.1. La primera vez que se usa la aplicación, esta lista está vacía.
43
Cada elemento de la lista corresponderá con un viaje realizado, el cual contendrá la siguiente información:
Nombre del viaje Fecha de inicio y fin del viaje Estado del viaje
El estado del viaje indica si un viaje se ha realizado o se está realizando, la aplicación solo permite que haya un viaje “ En curso” y este debe ser en tiempo real, es decir, el viaje que se encuentra activo debe te ner la “Fecha Fin” inferior o igual a la
fecha actual, una vez que se supera esa fecha el viaje automáticamente cambiara su estado a “Finalizado”.
Desde esta misma ventana se tiene la opción de poder crear un nuevo viaje pulsando el botón “+ Nuevo Viaje” siempre y cuando no haya ningún viaje “ En curso”, si no la aplicación mostrará una ventana emergente que comunicará que no se puede iniciar un nuevo viaje y que debes cerrar antes el viaje que está activo. Se tiene la opción de desplegar un menú contextual al dejar pulsado durante un instante uno de los viajes, ver figura 6.2, apareciendo las siguientes opciones:
Editar : Si se marca esta opción se pueden modificar los datos del viaje
seleccionado, con la limitación de que el viaje tiene que estar activo, si éste ha finalizado no se pueden modificar sus datos.
Eliminar : Se eliminará el viaje seleccionado.
44
F inalizar Viaje : Se tiene la opción de finalizar un viaje en cualquier momento,
aunque en un principio se hubiera puesto una fecha de final del viaje superior. Si se selecciona esta opción el viaje pasará al estado “ Finalizado”, y se cambiar la fecha de final del viaje que aparece en la lista por la fecha actual. Esta acción es irreversible, si se finaliza un viaje no podrá volver a estar activo.
Además podemos cambiar a la pestaña “ Fotos” la cual nos muestra un
determinado número de carpetas, una por cada viaje realizado. Cada carpeta nos muestra todas las fotos que se han realizado en un viaje. Véase la figura 6.4. La única opción que apare ce en esta ventana al pulsar el botón “ménu” que contienen todos los dispositivos con el sistema operativo Android, es la de salir de la aplicación. ” 6.3. Ventana de “Nuevo Vi aje A esta ventana se accede al pulsar el botón “ + Nuevo Viaje” de la pantalla
principal, y muestra un formulario que debe rellenar el usuario. Los campos del formulario son los siguientes:
Nombre : Dará nombre al viaje y será el nombre que aparece en la lista de viajes
de la pantalla principal. El usuario es quien según su criterio pondrá nombre al viaje, dependiendo de qué tipo de viaje se está realizando. Se puede estar visitando una ciudad o un sitio cuyo nombre sea menos especifico, como puede ser un viaje por la costa del sol, donde en este caso las ciudades que se visitan
45
corresponderán con los lugares visitados del viaje, o por el contrario el viaje corresponde con una ciudad y seria el nombre del viaje.
F echa I nicio : Corresponderá con la fecha en la que se inicia el viaje.
F echa F in : Corresponderá con la fecha en la que finalizará el viaje, en caso de
que el usuario decida finalizar el viaje antes de llegar a esta fecha, la nueva fecha de fin del viaje corresponderá con la actual. Los dos campos relacionados con las fechas ( Fecha Inicio y Fecha Fin ) cumplen los siguientes dos requisitos:
Ni la F echa I nicio ni la Fecha Fi n pueden ser menor que la fecha actual. La F echa F in no puede ser menor que la F echa I nicio .
En caso de que se produjera alguno de estos dos casos explicados no se permitiría crear el viaje, y se le comunicaría al usuario para que introdujese las fechas correctas. Por último se tiene el botón “Crear ” o “ Actualizar ” dependiendo como se haya
accedido a está ventana, si es para la creación de un nuevo viaje que se quiere realizar o es para actualizar los datos de un viaje en curso, en este último caso el formulario aparecería con los datos actuales del viaje, y el usuario modificaría los que creyera convenientes. Véase las figuras 6.3 y 6.4.
46
6.4. Ventana de la Lista de Lugares Esta ventana muestra una lista de los lugares que se han visitado en un viaje. Para acceder a ella hay que seleccionar un viaje de la lista en la pantalla principal. Véase figura 6.5.
La lista de lugares que se muestra en esta ventana consta del nombre del lugar, la fecha en la que se estuvo y una fotografía del lugar que el usuario tiene la opción de poner en la lista. La selección de la foto se realiza mediante un menú contextual, dejando pulsado un lugar de la lista que despliega un menú similar al de la pantalla principal, Véase figura 6.6, y que contiene las siguientes opciones:
Editar : Si se marca esta opción se pueden modificar los datos del lugar
seleccionado, con la limitación de que el viaje tiene que estar activo, si es un viaje ha finalizado no se pueden modificar sus datos.
Eliminar : Se eliminará el lugar seleccionado, antes se pedirá una confirmación
mediante una ventana emergente.
Añ adi r F oto : Esta opción permite al usuario seleccionar una foto y asignarla al
lugar seleccionado de la lista, para tener más información si el usuario lo desea. Al seleccionar esta opción se abre la galería de fotos que se tenga instalada en el móvil donde aparecen todas las fotos realizadas por el usuario no solo con esta aplicación y este buscaría alguna foto realizada en ese lugar para añadirla a la lista.
47
Quitar Foto : Es la opción que permite al usuario quitar alguna foto que se
hubiera seleccionado.
Existe un botón en la ventana llamado “+ Nuevo Lugar ” que al pulsarlo lleva al
usuario a una ventana con un formulario que al rellenarlo permite añadir un nuevo lugar que se visitará durante el viaje, esta vista se explicara a continuación. Durante esta pantalla si el usuario pulsa el botón “menú” del móvil se despliega un menú inferior que permite por un lado volver a la pantalla principal (Lista de Viajes) y por otro lado cambiar la vista de la ventana a la de “mapa”, esta última opción abre un
mapa sobre el cual aparecen marcadas las posiciones de todos los lugares que el usuario a visitado durante el viaje, en esta vista también se puede desplegar un menú, él cual permite cambiar la capa del mapa a la de “ satélite”. Véase figura 6.7 y 6.8 .
48
Las posiciones de los lugares visitados aparecen marcadas sobre el mapa con un icono y corresponde con las coordenadas de cada lugar visitado que se han obtenido mediante el GPS del móvil, esto se explicará posteriormente en este apartado. Al pulsar sobre uno de los marcadores se despliega una ventana que indicará al usuario el lugar que es mediante su nombre y la opción de ir a la ventana de ese lugar visitado con información más detallada, nombre, fecha, fotos,.... Véase figura 6.9.
49
6.5. Ventana de “Nuevo Lugar” Es la ventana que permite crear un nuevo lugar que se va a visitar durante el viaje, se accede a ella desde la ventana que contiene la lista de los lugares visitados en un viaje, Véase figura 6.10. La ventana contiene un formulario que se rellena con información del lugar. Los campos del formulario son los siguientes:
Nombre : Nombre del lugar, es el que aparecerá en la lista de lugares y en la
información detallada del lugar.
Ubicación : Este botón permite obtener las coordenadas del lugar mediante el
GPS del móvil. Al pulsarlo se accede a un mapa que contiene un botón en la parte superior derecha que hay que pulsar para obtener la posición actual del usuario y que esta sea representada en el mapa. Una vez que el usuario puede ver la posición representada en el mapa se le da opción de aceptar si está de acuerdo con la posición. Si el usuario acepta se utilizaran las coordenadas para marcar el lugar en el mapa explicado en el apartado anterior. Véase figura 6.11.
Descripción : Se da la opción al usuario si lo desea de poder dar una breve
descripción para tener información del lugar que se va a visitar.
50
Al pulsar el botón “Crear ” se añadirá un nuevo lugar visitado al viaje y se pasa ra
a la ventana de ese nuevo lugar donde se podrá obtener información más detallada, como comentarios sobre el lugar, el contenido que la wikipedia contiene del lugar y las fotografías realizadas por el usuario del lugar.
6.6. Ventana “Lugar” Al crear o seleccionar un lugar, se mostrará una pantalla que consta de las pestañas descripción, wikipedia y fotos, Véase figura 6.12. También incluyen dos opciones en el menú:
Home : Para ir a la pantalla principal
Cámar a: Para acceder a la cámara y poder añadir fotos que se asignaran al lugar
que hemos abierto. En la primera pestaña que nos encontramos, denominada “ descripción ”, se
mostrarán algunos de los datos que hemos rellenado al crear el lugar, como son:
Nombre : Nombre del lugar.
Imagen : Imagen del lugar. Es la misma foto que asociamos a la lista de lugares.
Fecha : Fecha en la que hemos visitado el lugar. Esta fecha está comprendida
entre la fecha de inicio y fecha final del viaje. Esta fecha es tomada automáticamente por la aplicación cuando es creado el lugar.
51
Descripción : Breve descripción del lugar que el usuario puede introducir si lo
desea. En esta pantalla podemos ir añadiendo comentarios, opiniones o datos de interés del lugar mediante el botón “+ Comentario”, que se irán añadiendo a una lista de
comentarios. Al mantener pulsado un comentario se desplegará un menú contextual, con las siguientes opciones:
Editar : Esta opción permite modificar el comentario seleccionado.
Eliminar : Se borrará el comentario seleccionado.
La segunda pestaña, “ wikipedia ” nos muestra el artículo que la enciclopedia
libre tiene del lugar que hemos seleccionado anteriormente. Ver la figura 6.13. Cada vez que accedemos a esta pestaña y hasta que no obtengamos confirmación por el usuario, la aplicación nos preguntará si la información mostrada es correcta; si el usuario está de acuerdo con la información que se muestra podrá aceptar, entonces el enlace se guardará de forma automática y a partir de ahora será el que se muestre siempre que decidamos volver a consultar esta pestaña. En el caso de no ser correcta la información, el usuario tendrá la opción de buscar el enlace adecuado y confirmarlo. Ver la figura 6.14.
52
Y por último, la tercera pestaña, “ Fotos ” muestra una galería de fotos, que son
todas las fotos que el usuario realizo de ese lugar accediendo a la cámara desde esta misma ventana, si se selecciona una foto de la galería esta se muestra en la pantalla. Cuando una imagen se está visualizando en la pantalla se puede pulsar en ella y aparecen dos botones que le dan la opción al usuario de rotar la fotografía a la derecha o a la izquierda, pasado un breve periodo de tiempo los botones desaparecen pudiendo volver a pulsar en la fotografía para que aparezcan. Ver figura 6.15.
53
7.
Diseño e implementación
54
7.1. Diseño En este apartado explicaremos el diseño de nuestra aplicación, mostraremos la estructura interna, los componentes que hemos usado para desarrollarla, así como la forma en que estos se unen y comunican entre sí. Hay que destacar que Android se caracteriza por usar el patrón MVC (Modelo Vista Controlador), por lo que la interfaz, el funcionamiento y los datos de la aplicación están separados en partes distintas y unidos mediante código. La vista, que sería la interfaz, está compuesta básicamente por archivos “.XML” y en determinados momentos cuando es necesario modificar algo de la vista de forma dinámica hacemos uso de código Java. El controlador, que sería el funcionamiento de la aplicación, está desarrollado por completo en Android (entendiendo que aquí se usa el lenguaje Java con todos sus método y clases si es necesario), esta parte es la que responde a eventos e interacciones por parte del usuario de la aplicación. Y por último el modelo, que hace referencia a los datos usados, que los almacenaremos en una Base de Datos, en nuestro caso nos hemos decidido por SQLite3, cuyas ventajas para este tipo de proyectos (proyecto para dispositivo móvil) son varias, entre las que destacan el hecho de no tener que hacer uso de un servidor y el poco espacio que necesita, además de que ya viene incorporada con el SDK de Android . La aplicación está diseñada para que se almacene información sobre uno o varios lugares visitados durante un periodo de tiempo determinado por el usuario y posteriormente se pueda acceder a esa información. La aplicación permite mantener ordenados los viajes que se realizan y acceder fácilmente a toda la información que contienen, consultando en cualquier momento todo aquello que el usuario guardó durante el viaje. Se vuelven a recordar en este capítulo los conceptos básicos de la aplicación:
VIAJE: Periodo de tiempo continuo durante el cual el usuario se encuentra en un lugar o en varios lugares. LUGAR: Hace referencia a un sitio en concreto donde el usuario ha estado durante el viaje. Este concepto puede hacer referencia a monumentos, edificios, parques, restaurantes, museos,..., es decir todos aquellos lugares de interés que el usuario crea conveniente recordar durante el viaje o eventos que se han producido durante el viaje como el encuentro con unos amigos, estancia en un concierto, etc.
55
Toda la aplicación gira en torno a estos dos conceptos que están relacionados entre sí y a los que se les va añadiendo información. Se pueden crear todos los viajes que el usuario quiera realizar, con la condición de que no puede haber ninguno activo al iniciar uno nuevo ya que esta aplicación está pensada para viajes en tiempo real, es decir, el usuario va recopilando información en el mismo momento en que está viajando. Dentro de un viaje se van añadiendo los distintos lugares que el usuario ha visitado. Por lo tanto, un viaje tiene dos estados:
Finalizado: cuando un viaje ha terminado, y no podremos añadirle imágenes ni
ningún tipo de información, sólo podremos consultarlo.
En cur so : cuando un viaje está activo, es decir, se puede seguir recopilando
información sobre éste, con la condición como ya se ha comentado anteriormente, que solo puede haber un viaje activo. Con la creación de un “ viaje ” nuevo se recopila información general de
éste por
parte del usuario a través de un formulario, este formulario recoge:
Nombre del viaje : el usuario dará el nombre que crea que mejor representa a ese
viaje.
Descripción : Se dará una breve descripción del viaje.
F echa de in ici o y fi n : Periodo de tiempo durante el cual se estará viajando,
aunque el usuario puede modificar estas fechas, respetando ciertas condiciones, como la de que no puede crear un viaje nuevo con la fecha de inicio inferior a la actual, o que la fecha final sea menor que la fecha inicial. Si el usuario incumple alguna condición será advertido mediante una notificación. Además el usuario tiene la opción de finalizar el viaje activo en el momento que desee, debido a que el viaje se ha acortado por cualquier motivo, por lo que la fecha de fin pasara a ser la actual y el viaje pasara al estado de “Finalizado ”.
56
Una vez que se tiene un viaje activo se pueden añadir los distintos lugares o eventos que se van realizando durante el viaje, aquí es donde se recopila la mayor parte de la información. La primera parte que recoge información es un formulario en el que se deben rellenar los siguientes campos:
Nombre : es el nombre del lugar que estamos visitando.
Posición del l ugar mediante GPS : Se muestra de forma grafica a través de un
mapa que marcará la posición actual del usuario, esto es así porque como ya se ha comentado la aplicación está pensada para que sea en tiempo real, por lo que el usuario debe estar en el lugar que se añade, en el momento que quiere recopilar información del mismo. Una vez que el GPS ha obtenido la posición se pide confirmación al usuario de la posición para que esta sea almacenada.
Descri pción del l ugar : algo genérico que describa el lugar, ya que como se
explicará más adelante el usuario tiene la opción de añadir todos los comentarios que desee del lugar visitado. Como ya se ha comentado, la idea de la aplicación es la recopilación de información sobre los lugares visitados, para que el usuario pueda recordar su estancia teniendo toda la información ordenada y fácilmente accesible. El grueso de esta información corresponde con los lugares concretos visitados o los eventos que se han llevado a cabo:
FOTOS: Corresponde con las fotos que el usuario ha realizado del lugar.
MAPA: Muestra la posición del lugar sobre un mapa.
COMENTARIO: Son los comentarios que ha realizado el usuario sobre el lugar
que ha visitado y ha creído conveniente recordar.
WIKIPEDIA: Es la información que contiene la enciclopedia libre “wikipedia”
sobre el lugar que se ha visitado y que la aplicación muestra en una de sus pestañas. Para la información almacenada en la aplicación se ha utilizado la base de datos SQLite3, incorporada en el SDK de Android , se trata de un sistema de gestión de bases de datos relacional. A diferencia de los sistemas de gestión de bases de datos cliente-servidor, el motor de SQLite no es un proceso independiente con el que el programa principal se comunica. En lugar de eso, la biblioteca SQLite se enlaza con el programa pasando a ser parte integral del mismo. El programa utiliza la funcionalidad de SQLite a través de
57
llamadas simples a subrutinas y funciones. Esto reduce la latencia en el acceso a la base de datos, debido a que las llamadas a funciones son más eficientes que la comunicación entre procesos. El conjunto de la base de datos (definiciones, tablas, índices, y los propios datos), son guardados como un sólo fichero estándar en la máquina host. Este diseño simple se logra bloqueando todo el fichero de base de datos al principio de cada transacción. En su versión 3, SQLite permite bases de datos de hasta 2 Terabytes de tamaño, y también permite la inclusión de campos tipo BLOB, que son elementos utilizados en las bases de datos para almacenar información de gran tamaño que cambian de forma dinámica. En nuestro proyecto ha sido necesario crear 3 tablas para almacenar la información de los viajes realizados. Las tablas con sus respectivos campos, son las siguientes:
Tabla NuevoViaje: Almacena la información relevante a un viaje. o id: Es la clave primaria y se autoincrementa al añadir un nuevo viaje. o nombre: Indica el nombre del viaje y es obligatorio rellenar este campo. o fechaInicio: Fecha en la que se inicia el viaje. o fechaFin: Fecha en la que finaliza el viaje. o descripción: Es una breve descripción del viaje. o activo: Indica si un viaje esta activo o no (sólo puede haber un viaje
activo)
Tabla NuevoLugar: Almacena la información relevante a un Lugar. o id: Es la clave primaria y se autoincrementa al añadir un nuevo lugar. o nombre: Indica el nombre del lugar y es obligatorio rellenar este campo. o ubicación: almacena las coordenadas GPS del lugar. o descripción: Es una breve descripción del lugar. o wikipedia: Es la dirección web de la wikipedia donde se encuentra
información relevante del lugar visitado. o foto: contiene la ruta hacia la foto que se muestra. o idViaje: Es el identificador del viaje al que pertenece el lugar visitado.
Con este campo relacionamos la tabla lugares con los viajes.
58
Tabla Comentarios: Almacena los comentarios de los lugares visitados. o id: Es la clave primaria y se autoincrementa al añadir un comentario o comentario: es cada uno de los comentarios que podemos añadir en un
lugar. o idLugar: Es el identificador del lugar al que pertenece el comentario. Con este campo relacionamos la tabla comentarios con los lugares. Estas tablas las hemos creado con el siguiente código SQL: CREATE TABLE NuevoViaje (id INTEGER PRIMARY KEY AUTOINCREMENT, nombre TEXT NOT NULL, fechaInicio DATE, fechaFin DATE, descripcion TEXT, activo INTEGER); CREATE TABLE NuevoLugar (id INTEGER PRIMARY KEY AUTOINCREMENT, nombre TEXT NOT NULL, lugar TEXT, descripcion TEXT, wikipedia TEXT, foto TEXT, idViaje INTEGER); CREATE TABLE Comentarios (id INTEGER PRIMARY KEY AUTOINCREMENT, comentario TEXT NOT NULL, idLugar INTEGER);
Viajes
1
Visita
1:N
Lugares 1
Escribe 1:N
Comentarios
59
LEYENDA Entidades fuertes Entidades débiles Entidades débil en existencia
7.2. Implementación En este apartado explicaremos y mostraremos parte del código de la aplicación, obviamente no vamos a mostrar todo el código porque no creemos que eso sea necesario y daremos por entendido la forma de cómo funcionan y son llamados los métodos del SDK de Android , ya que se explico en el apartado 5. Comentaremos la parte del código que es la base de la aplicación, no será común mostrar el código completo de las clases que hemos implementado, si no lo normal será seleccionar la parte del código más relevante y es la que se explicará, así como de una forma genérica, el software que hemos usado para implementarla. El software serán métodos y clases de Java y del SDK de Android , como ya hemos comentado en otro apartado de esta documentación. Por otro lado también hablaremos del lenguaje de marcas extensibles XML (siglas en inglés de eX tensible M arkup L anguage ), que es un lenguaje de marcas desarrollado por el Worl d Wide Web Consorti um (W3C). Deriva del lenguaje SGML y permite definir la gramática de lenguajes específicos (de la misma manera que H T M L es a su vez un lenguaje definido por SGML) para estructurar documentos grandes. En nuestro caso en concreto es muy utilizado en Android para realizar la interfaz. Android proporciona un amplio conjunto de objetos View en el paquete Android.view . Estos objetos varían entre construcciones familiares como EditText , Spinner , TextView y Button hasta elementos más especializados como AnalogClock , Gallery , DatePicker , TimePicker y VideoView . Comenzamos explicando la pantalla principal de la aplicación, de la que destacamos la lista de “viaj es realizados ” que muestra el “nombr e del vi aje ”, la “fecha de inicio” y la “fecha fi n ” del viaje y por último el “estado ” en que se encuentra el viaje, en curso o finalizado. Archivo main.xml
60
El ultimo método que explicamos de la clase principal es cargarLista(), un método privado que es el encargado de listar los viajes en la pantalla. En primer lugar creamos un ArrayList de NuevoViajeBean , que es un Bean , es decir, un objeto que nos ayuda a manejar los datos necesarios para crear un nuevo viaje. Una vez creado el ArrayLista lo inicializamos con todos los viajes que tenemos almacenados en la base de datos y a continuación los recorremos para comprobar cuál es el viaje que se encuentra activo en estos momentos y comprobar si ese viaje debe finalizarse o no debido a que haya superado la fecha en que finalizaba el viaje. Si es así
63
el estado del viaje cambia a Finalizado como el del resto de viajes si los hubiera , si no se mostrará como activo . De esta forma los viajes se finalizan de forma automática cuando se traspasa la fecha que puso el usuario como final del viaje, aunque se da la opción, como ya se ha explicado, que el usuario finalice el viaje antes de la fecha que marcó como fin, si así lo deseara. Finalmente creamos un nuevo objeto de la clase Adaptador, que es una clase que hemos creado y explicaremos a continuación, a la que le pasamos el array viajes y a continuación a la lista de viajes ( listaViajes ) le cambiamos mediante el método setAdapter() el adaptador que viene por defecto por el recién creado por nosotros, para personalizar así la forma como se mostrarán los distintos elementos de la lista, es decir mostrar la información de los distintos viajes, que hemos decidido que fuera el nombre , fecha de ini cio , fecha fi n y estado del viaje. De la clase Adaptador destacamos el método getView() que es donde se establecen los datos que se quieren mostrar en cada elemento de la lista. Aunque como se ve a continuación en el código también se encuentra el constructor que inicializa el contexto que hace referencia a la activity desde la que se llama a esta clase, en este caso concreto desde la actividad principal DiarioDeViaje.java, y también se inicializa la variable datos con el parámetro que se le pasa datos , que es la lista de todos los viajes realizados hasta el momento. Al haber llamado igual tanto a las variables como a los parámetros que se pasan hemos tenido que utilizar la palabra reservada en Java this. Esto último ha sido una simple apreciación para el lector, ya que esto no corresponde a este apartado, ni siquiera a este proyecto, ya que el objetivo no es hacer un manual de java si no usar java(concretamente el SDK de Android , que está escrito en Java) para realizar un proyecto. A continuación encontramos los métodos getCount(), getI tem() y getItemI d(), que junto con getView() son necesarios implementar debido a que extendemos de la clase BaseAdapter. El primero de ellos, getCount(), devuelve un valor de tipo int con el tamaño del array que inicializamos en el constructor, en caso de tener que usarlo esto se traduce para nuestra aplicación en el número de viajes que llevamos realizados. El método getI tem(in t arg0) devuelve un objeto, que en nuestro caso correspondería con un viaje realizado, concretamente el viaje que se ha seleccionado en la lista, devolvería el Bean correspondiente con ese viaje, y por tanto tendríamos un objeto con toda la información del viaje seleccionado. El tercer método getI temI d(int arg0) devulve el id del viaje que se ha seleccionado. Son métodos de relativa importancia, ya que la información que devuelven es necesaria en caso de tener que manipular los distintos viajes que se realizan. A continuación se muestra el código completo de la clase Adaptador y a continuación se explicará el método getView(), que como ya se ha dicho es el más destacado de esta clase.
64
public class Adaptador extends BaseAdapter { private Context context = null; private ArrayList datos = null; public AdaptadorP(Context context, ArrayList datos){ super(); this.context = context; this.datos = datos; } @Override public int getCount() { // TODO Auto-generated method stub return datos.size(); } @Override public Object getItem(int arg0) { // TODO Auto-generated method stub return datos.get(arg0); } @Override public long getItemId(int arg0) { // TODO Auto-generated method stub return arg0; } public View getView(int arg0, View arg1, ViewGroup arg2) { // TODO Auto-generated method stub LayoutInflater
Lo primero que hacemos en el método getView() es añadir a la interfaz un nuevo archivo .xml, en este caso lista_personalizada.xml mediante la clase LayoutInflater, que personalizará cada elemento de la lista, este archivo será explicado a continuación. Después lo que se añade es el nombre del viaje, se comprueba si éste está en curso o finalizado para indicarlo mediante texto y también para cambiar el color de fondo de ese elemento de la lista, para distinguir visualmente entre uno u otro (rojo significa finalizado y verde en curso). Y por último se añade la fecha de inicio, la fecha de finalización y la descripción del viaje. Para personalizar la lista de viajes se usa el archivo lista_personalizad.xml , el cual se utliza desde el método getView() de la clase adaptador.
Con este archivo XML queremos personalizar la forma como se muestran el nombr e, estado, fecha de ini cio y l a fecha fi n de cada viaje que ha realizado el usuario. Esta información se va a dividir en dos bloques, en primer lugar se quiere mostrar en la parte superior de cada elemento de la lista el nombre del viaje y el estado en que se encuentra por ello se crea un primer bloque a partir de un , en este caso hay que destacar que no se usa un debido a que se quiere modificar la posición de los elementos dentro de este bloque, por un lado el nombre del viaje en la parte izquierda del bloque, esto es por defecto, y por otro lado el estado en el que se encuentra el viaje, ya sea en cur so o finalizado , en la parte derecha como puede verse en el código con la línea Android:layout_alignParentRight= "true", dentro del objeto TextView que corresponde con el estado del viaje. En segundo lugar, el bloque que muestra las fechas del viajes que se ponen con un simple . La lista de lugares visitados, que son los lugares que se han visitado en cada viaje realizado, tiene una implementación muy similar a la lista de viajes explicada anteriormente pero variando los elementos que se muestran, que en este caso es el nombre, descripción y una sola fecha (fecha en la que se visito el lugar) y con la mayor diferencia que es la posibilidad de mostrar una imagen del lugar en la lista. Para ello en el menú contextual de la lista hay la opción de “Añadir Foto” , que al pulsar sobre ella abre la galería de fotos donde se puede seleccionar una . A continuación se muestra el trozo de código que lo implementa. case R.id.Foto:
Intent inte = new Intent(Intent.ACTION_PICK , Android.provider.MediaStore.Images.Media. INTERNAL_CONTENT_U RI ); code = SELECT_PICTURE ; startActivityForResult(inte, code); break;
67
Este trozo de código se encuentra dentro del método que genera el menú contextual onContextItemSelected() de la clase Viaje.java , que no hemos visto necesario explicar su implementación. Lo que se hace es comprobar dentro del menú si la opción seleccionada era la de añadir una foto y si es así lanzar un intent mediante el método startActivityForResult() que abrirá la galería de fotos. Cuando se selecciona una foto de la galería se llama al método onActivityResult() que es el encargado de procesar la respuesta. Lo único que se hace en este método es volver a llamar al método cargarLista() para que actualice de nuevo la lista de lugares visitados mostrando también la foto que se ha seleccionado. protected void onActivityResult(int requestCode, int resultCode, Intent data){ if(requestCode == SELECT_PICTURE ){ cargarLista(); } }
NuevoViaje.java
Esta es la clase que se encarga de rellenar el formulario necesario para la creación de un nuevo viaje, esta clase recibe una serie de datos por parte del usuario, como es el nombre que quiere dar al viaje y las dos fechas que delimitaran el periodo de tiempo que durará el viaje. De esta clase hemos destacado el efecto que se produce al pulsar sobre los campos que solicitan las fechas y que es la aparición de una ventana emergente, denominado selector de fechas, para que el usuario pueda introducir las fechas de una forma grafica y no mediante texto utilizando el teclado, además de la ventaja de ser más cómodo e intuitivo para el usuario, tiene la ventaja de que nos aseguraremos que el usuario introduzca los valores de fechas con el formato adecuado. private EditText fechaInicioEdit = null; private EditText fechaFinEdit = null; private private private private
Calendar calendar = null; int year = 0; int month = 0; int day = 0;
calendar = Calendar.getInstance(); year = calendar.get(Calendar.YEAR); month = calendar.get(Calendar.MONTH ); day = calendar.get(Calendar.DAY_OF_MONTH ); lanzarEvento(fechaInicioEdit); lanzarEvento(fechaFinEdit); }
Lo primero que vamos a ver es el método onCreate() . Lo primero como siempre es definir el archivo XML que contiene la interfaz que para esta actividad es nuevo_viaje.xml. Después inicializamos las variables fechaInicioEdit y fechaFinEdit con los objetos view correspondientes que están en el archivo XML recién cargado, además de inicializar la variables necesarias para obtener la fecha actual. Una vez que se tienen todas la variables que son necesarias inicializadas, se llama al método privado lan zarE vento(Vi ew v) encargado de lanzar el selector de fechas cuando corresponda. private void lanzarEvento(View v){ v.setOnClickListener(new OnClickListener() { @Override public void onClick(View v) { // TODO Auto-generated method stub showDialog(DATE_DIALOG_ID ); } }); v.setOnFocusChangeListener(new OnFocusChangeListener() { @Override public void onFocusChange(View v, boolean hasFocus) { // TODO Auto-generated method stub if(hasFocus){ showDialog(DATE_DIALOG_ID ); } } }); }
Este método se encarga de comprobar cuando se selecciona alguno de los campos de fechas que tiene el formulario para crear un nuevo viaje y poder hacer visible el selector de fechas. Para ello se utilizan dos eventos sobre el objeto View pasado por parámetro, que son setOnclickListener() y setOnFocusChangeListener(). Se necesita llamar a los dos por las siguientes razones, si solo se pusiera el método que se ejecuta cuando se cambia el focus (FocusChangeListener ) si se quiere modificar una fecha que en ese momento tiene el focus no se lanza el selector de fechas, y por el contrario si solo se tuviera el evento que se lanza cuando se hace click (clickListener ) habría que pulsar dos veces sobre el campo fecha, porque en una primera pulsación el campo correspondiente obtiene el focus y en una segunda pulsación es cuando se entiende
69
como el efecto de hacer click . Por todo lo explicado anteriormente son necesario los dos eventos, así si el usuario cambia el focus entre los dos campos de fechas ( fecha de inicio y fecha fi n ) se lanza el segundo evento ( setOnFocusChangeListener() ) y se muestra el selector, además se comprueba que los dos objetos View sean los que contienen el focus mediante la condición hasFocus, para evitar que si se cambia el focus a otro campo que no sea uno de fechas no se lance el selector. Finalmente cuando uno de los dos eventos, dependiendo de la acción del usuario, llama al método showDialog(int id) que es el que hace visible el selector de fechas y para ello se ejecuta de forma implícita el código que contiene el método protegido onCreateDialog que es el que realmente abre la ventana emergente (selector de fechas). protected Dialog onCreateDialog(int id){ Dialog d = null; switch (id) { case DATE_DIALOG_ID : d = new DatePickerDialog(this, mDateSetListener, year, month, day); break; default: break; } return d; }
Este método es el encargado de gestionar todos las ventanas emergentes (se denominan en Android Dialog, como puede ser el selector de fechas) que se abren en la actividad correspondiente. Por tanto comprueba cual es el Dialog al cual se está llamando y crea un nuevo Dialog que es el que se devuelve y será mostrado. NuevoLugar.java
Al igual que sucedía en la clase NuevoViaje.java esta clase se encarga de gestionar los datos introducidos por el usuario en un formulario. De esta clase, como pasaba con la clase anterior, vamos a explicar parte del código y lo más destacado es la obtención de la posición del lugar que se visita mediante coordenadas GPS y representarla de forma gráfica en un mapa utilizando la API de google y el GoogleMaps. public class NuevoLugar extends Activity { private Button ubicacion = null; public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout. nuevo_lugar ); ubicacion = (Button) findViewById(R.id.ubicacion_id ); ubicacion.setOnClickListener(new OnClickListener() {
70
@Override public void onClick(View arg0) { // TODO Auto-generated method stub Intent intent = new Intent(contexto, MapaUbicacion.class); startActivity(intent); } });
El código anterior solo es una parte de la clase NuevoLugar.java, del que vamos a explicar el campo ubicación que aparece en la aplicación al crear un nuevo lugar visitado en un viaje. Para ello en el método onCreate() en primer lugar y como siempre se hace referencia al archivo XML que contendrá la interfaz que se mostrará en la aplicación. A continuación creamos un objeto de tipo Button, el cual inicializamos con el botón creado en archivo XML al que hemos hecho referencia anteriormente mediante el método findViewById(). Una vez que tenemos la variable ubicación creada cambiamos, utilizando el método setOnClickListener() , la acción que se lleva a cabo al pulsar sobre el botón. Esta acción es la de ejecutar una nueva activity con el nombre MapaUbicación. private MapView mapa = null; private MapController controlMap = null; private LocationManager locManager = null; private LocationListener locListener = null; private private private private
Esta nueva activity es la que se encarga de obtener mediante coordenadas GPS la posición actual del usuario y mostrar sobre un mapa, para ser visualizada. Para mostrar cómo se hace se van a explicar los métodos más importantes de la activity. En primer lugar tenemos, como se muestra más arriba, el método onCreate() que además del ya comentado método setContentView(), que en esta activity añade un mapa que usaremos para representar las coordenadas y que se explicara más adelante el archivo XML que se emplea, se hace uso de la clase LayoutInflater, que junto con los métodos inflate() y addContentView(), nod sirve para añadir dos botones sobre la interfaz original ya mencionada que contiene el mapa de Google, uno de ellos para obtener las coordenadas y el otro para aceptar si el usuario está de acuerdo con la posición que se ha recibido en el mapa. A continuación se asigna a los dos botones ya mencionados, ubicación y aceptar, las acciones que se llevaran acaba al pulsar sobre ellos mediante el método setOnClickListener(), en este caso se, la acción que se realiza al pulsar, se ha implementado en un método a parte que se explicara más adelante. Por último, dentro del método onCreate(), se tiene lo más importante dentro de este método y que es la inicialización de las variables locManager y locListener , que ayudándonos de una clase interna llamada MiLocationListener() podemos hacer uso del GPS del dispositivo. private class MiLocationListener implements LocationListener{ @Override public void onLocationChanged(Location location) { // TODO Auto-generated method stub comprobarRecibeCoordenadas = true; } @Override public void onProviderDisabled(String provider) { // TODO Auto-generated method stub comprobarDispositivo = false; } @Override public void onProviderEnabled(String provider) { // TODO Auto-generated method stub comprobarDispositivo = true; } @Override
72
public void onStatusChanged(String provider, int status, Bundle extras) { // TODO Auto-generated method stub } }
Esta clase interna , que se encuentra dentro de la clase MapaUbicación, contiene cuatro métodos de los que hemos usado tres y que son llamado de forma implícita cuando se produce algún evento relacionado con ellos. El primero es llamado cuando se produce un cambio de coordenadas, el segundo cuando el GPS esta desactivado y el tercero cuando el GPS esta activo. Para saber si se ha producido alguno de estos casos que acabamos de describir, usamos las variables comprobarRecibeCoordendas y comprobarDispositivo. public void onClick(View v) { // TODO Auto-generated method stub switch (v.getId()) { case R.id.ubicacion: if(comprobarDispositivo){ if(!comprobarRecibeCoordenadas){ Toast.makeText(contexto, "Coordenadas no disponibles", Toast.LENGTH_LONG ).show(); }else{ loc = locManager.getLastKnownLocation(LocationManager .GPS_PROVIDER); latitud = loc.getLatitude()*1E6; longitud = loc.getLongitude()*1E6; Toast.makeText(contexto, "logitud: " + longitud + " latitud: " + latitud, Toast.LENGTH_LONG ).show(); drawable = this.getResources().getDrawable(R.drawable. marc ador ); geoPoint = new GeoPoint(latitud.intValue(), longitud.intValue()); MyOverlay itemizedOverlay = new MyOverlay(drawable); mapOverlays = mapa.getOverlays(); OverlayItem overlayItem = new OverlayItem(geoPoint, "Hola", "Hola"); itemizedOverlay.addOverlay(overlayItem); mapOverlays.add(itemizedOverlay); aceptar.setVisibility(1); controlMap.setCenter(geoPoint); controlMap.setZoom(16);
73
} }else{ Toast.makeText(contexto, "El GPS esta desactivado", Toast.LENGTH_LONG ).show(); } break; case R.id.boton_aceptar : locManager.removeUpdates(locListener); Intent intent = new Intent(contexto, NuevoLugar.class); startActivity(intent); break; default: break; } }
En el método onClick() se implementa, como ya se ha comentado, la acción que se lleva a cabo al pulsar sobre los botones ubicación y aceptar. En cuanto al primero, lo que se hace es comprobar la variable comprobarDispositivo , inicializada en la clase privada MiLocationListener, para saber si el GPS esta activado o no, en caso negativo se informa al usuario, si no se comprueba la otra variable, comprobarRecibeCoordenadas, también inicializada en la mencionada clase interna que nos dirá si se están recibiendo coordenadas GPS, si no es así, se comunicara al usuario que aún no hay coordenadas disponibles debido a que el GPS está intentando obtenerlas. Una vez que se obtienen, se almacenan en las variables latitud y longitud, y con la ayudad de las clases Drawable y GeoPoint del SDK de Android y una nueva clase interna llamada MyOverlay se dibuja sobre el mapa con un marcador (un icono gráfico) la posición que se ha obtenido. Posteriormente se hace visible sobre la pantalla el botón aceptar, para que el usuario de su conformidad sobre la posición y por ultimo se centra el mapa sobre el punto recientemente localizado. La otra opción del método onClick(), es la de pulsar el bóton aceptar para confirmar que es la posición deseada y dejar esta pantalla. Antes de abandonarla se utiliza el método removeUpdates() para parar que el GPS siga buscando coordenadas, puesto que al salir de esta pantalla que contiene el mapa ya no es necesaria la función del GPS, y evitar así un gasto de batería adicional. A partir de ahora explicaremos parte del código que usamos para almacenar la información de los lugares visitados, como es el uso de la cámara, la pestaña donde se pueden ver las fotos realizadas y la información que contiene la enciclopedia libre Wikipedia sobre el lugar visitado.
74
CAMARA : case R.id.camara_id Date fecha = new Date(); String file = fecha.getDay() + "-" + fecha.getMonth() + "-" + fecha.getYear() + "_" + fecha.getHours() + "-" + fecha.getMinutes() + "-" + fecha.getSeconds() + ".jpg"; rutaFoto = new File(rutaLugar, file); Intent i = new Intent(MediaStore.ACTION_IMAGE_CAPTURE ); Uri output = Uri.fromFile(rutaFoto); i.putExtra(MediaStore. EXTRA_OUTPUT , output); startActivity(i); break;
Este código se encuentra dentro del método onOpti onsItemSelected() que es el que se encarga de llevar a cabo una acción cuando se pulsa una opción en el menú de la pantalla. Al optar por la opción de la cámara se ejecuta el código anterior. En primer lugar se obtienen la fecha y la hora actual, que corresponderá a la fecha y hora en que se realiza la foto y se almacena en una variable llamada file, esta variable es la que utilizaremos para nombrar la fotografía que se realice. A continuación obtenemos la ruta donde almacenar la foto, a partir de la variable rutaLugar que ya tenemos inicializada dentro de la clase donde se encuentra el código y que corresponde con una carpeta creada para esta aplicación cuando se instala por primera vez, y con la variable anterior file terminado en .jpg para que corresponda con un formato de imagen. Una vez se tiene la ruta lanzamos la cámara a través de una de las aplicaciones que tenga nuestro móvil, por defecto, Android siempre trae una aplicación para la cámara, en el caso de que hayamos instalado nosotros una de terceros, la aplicación preguntará con cual queremos abrir, para abrir la cámara usamos un intent y le indicamos la ruta donde guardar el archivo, finalmente lanzamos la actividad. WIKIPEDIA
Para obtener la información de wikipedia nos apoyamos en el nombre que el usuario le da al lugar en el momento de crearlo y junto con la dirección "http://es.m.wikipedia.org/w/index.php?title=Special%3ASearch&search=" que vimos que era la que utilizaba wikipedia para redireccionar al artículo que se está buscando y si no coincide la palabra buscada con un artículo te redirecciona a los artículos relacionados o que más se ajustan a la palabra buscada donde puedes elegir el correcto, para ello también añadimos una notificación y un botón que aparece la primera vez que quieres ver la información en la wikipedia , la notificación te pregunta si estás de acuerdo con el artículo mostrado para que aceptes con el botón, en caso contrario
75
puedes buscar el artículo que describe el lugar visitado y aceptas. En el momento que se acepta el artículo que se encuentra a la vista es el que se mostrará en sucesivas visitas a la pestaña de wikipedia . Lo hicimos finalmente de esta manera porque aunque estuvimos buscando alguna api de wikipedia que pudiéramos usar aplicándola a nuestra aplicación y dentro de nuestro código no la encontramos finalmente y nos decidimos por esto. Para poder usar nuestra aplicación como un navegador web mostrando así información de internet y no tener que usar un navegador externo a nuestra aplicación para ver contenido de la web hay que definir un elemento WebView en un archivo .xml, este elemento lo definimos en el archivo lugar.xml que es donde se define toda la vista para la pantalla donde se muestra la información de un lugar. public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);
setContentView(R.layout. lugar ); myWebView = (WebView) findViewById(R.id.webview ); myWebView.loadUrl(cadena); myWebView.setWebViewClient( new verMiWeb()); }
En el método onCreate() a parte de las líneas de código que se pueden ver hay varias líneas de código más que no hemos puesto porque no son relevantes para explicar el funcionamiento de la información que se muestra de la wikipedia y que si la hubiéramos puesto ocuparía demasiado espacio, por lo tanto hemos puesto lo necesario para explicar lo deseado. En primer lugar inicializamos la variable myWebView con el elemento que se encuentra en el archivo Lugar.xml. Para cargar el artículo de wikipedia correspondiente en nuestra aplicación usamos el método loadUrl que recibe la variable cadena, esta variable está inicializada con la dirección mencionada anteriormente más el nombre que se le dio al lugar por parte del usuario, estas dos cadenas se unen usando un método privado dentro de la misma clase donde va el método onCreate(). Finalmente tenemos la llamada al método setWebViewClient () que recibe una clase privada que hemos implementado, y que sirve para evitar que se abra un navegador externo a nuestra aplicación, gracias a este método siempre estaremos navegando por internet dentro de nuestra aplicación. FOTOS
Para visualizar las fotos hemos creado una galería. En el sdk de Android se encuentra un componente que nos sirve para implementar la galería de fotos, y se denomina Gallery, este componente lo creamos en el archivo Lugar.xml y lo llamamos desde la clase Lugar.java similar a lo que sucedía con el elemento WebView para crear el navegador interno de nuestra aplicación.
76
public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout. lugar ); Gallery gallery = (Gallery)findViewById(R.id.gallery ); gallery.setAdapter(new ImageAdapter(this)); gallery.setOnItemClickListener(this); }
Lo primero es asociar el archivo Lugar.xml a nuestra actividad. A continuación inicializamos la variable gallery con el elemento que hemos creado en el archivo .xml, una vez inicializado utilizamos el método setAdapter() para cambiar el adaptador de la galería por uno personalizado por nosotros. Finalmente mediante el método setOnItemClickListener() implementaremos la acción a llevar a cabo cuando se seleccione una foto de la galería, esta acción será la de colocar la foto en la pantalla para verla. public View getView(int position, View convertView, ViewGroup parent)
{ ImageView imageView = new ImageView(this.contexto); FileInputStream fd; try { fd = new FileInputStream(fotos[position]); Bitmap bitmapFoto BitmapFactory.decodeFileDescriptor (fd.getFD());
De la clase interna ImageAdapter que sirve para personalizar la galería a nuestro gusto destacamos el método getView() que es el que configura cada fotografía para que se previsualice en el elemento Gallery. En primer lugar inicializamos la variable imageView que es donde se almacenarán cada una de las fotos que se visualizarán. Después creamos un objeto de tipo File con el que obtenemos la ruta de la imagen a colocar en la galería, lo hacemos con la ayuda de la lista fotos que contiene las rutas de todas las fotos que se hicieron con la cámara desde la pantalla de un lugar concreto. A
77
continuación se crea un objeto Bitmap para poder trabajar con una imagen, este objeto se crea a partir del archivo anterior, posteriormente se utiliza este bitmap para crear uno nuevo pero con la escala deseada, para poder reducir el tamaño original de una foto y pueda previsualizarse en la galería. Finalmente se asocia el último Bitmap creado al elemento ImageView que hemos formado al principio, para que aparezcan en la galería mediante la utilización del método setImageBitmap() y por ultimo cambiamos el ancho y alto de la galería con el método setLayoutParams().
78
8.
Pruebas
79
El SDK de Android permite integrar dispositivos virtuales para probar la aplicación en el entorno de desarrollo Eclipse. Queda a disposición del usuario crearse cuantos emuladores quiera y con las características que se desee. Esta flexibilidad permite entre otras cosas, establecer la versión de sistema operativo en la que se ejecutara, el tipo de pantalla, su resolución, cantidad de memoria... Para realizar las pruebas hemos creado un emulador que implementa la versión 2.2 otro con la versión 2.3 de Android , puesto que estas son las más comunes entre los terminales Android . En todo momento se realizaban pruebas en uno y otro emulador para poder observar las diferencias de ejecución entre una versión y otra. Las diferencias entre velocidades de ejecución y acceso a Internet eran casi siempre mínimas, siendo lo más destacable los cambios a nivel de interfaz debido a la leve diferencia de resolución de pantallas, permitiendo de esta manera ajustar mejor el tamaño y apariencia de la información a mostrar para una correcta presentación. Cada vez que acabábamos una parte de la aplicación, la probábamos en cada uno de los emuladores para su correcto funcionamiento. Esta comprobación era principalmente en cuanto a interfaz y cumplimiento de funcionalidades, puesto que las pruebas se realizaban sobre un emulador. De esta manera la optimización de código se deja para la fase final de la aplicación cuando ya pueda ser probada en un dispositivo real. En nuestro caso no tuvimos problemas para probar la aplicación en el emulador de Android a excepción de la cámara, puesto que no se puede ejecutar ninguna cámara desde el emulador, sin embargo si es posible emular coordenadas GPS para simular un punto del mapa. Una vez terminada la aplicación y habiendo sido probada en el emulador nos decimos por hacer una prueba real de la misma. La única forma de llevar a cabo una prueba de nuestra aplicación es realizar un diario de viaje en vivo, por tanto tomamos el móvil y salimos por alguna de las zonas turísticas de Sevilla probando así la aplicación. De esta manera probamos la localización GPS de una forma real y también la cámara que fue algo que no puedo realizar en el emulador. Este viaje lo realizamos en la ciudad de Sevilla, en primer lugar creamos un nuevo viaje al que se le dio el nombre de Sevilla, en relación a la ciudad que estábamos visitando, se introdujeron las fechas en las que se visitó, fecha de incio y fecha de fin del viaje, ambas fechas coincidieron en nuestro caso ya que realizamos la prueba real de la aplicación en un solo día. Una vez creado el viaje, visitamos los distintos lugares turísticos, para cada uno de ellos se crea un nuevo lugar en la aplicación rellenando el nombre, descripción y obteniendo la posición GPS del mismo. Y se iban realizando las fotos de cada lugar. Los lugares visitados fueron:
80
-
Ayuntamiento de Sevilla Catedral de Sevilla Reales Alcázares de Sevilla Archivo de Indias Plaza de toros de Sevilla Torre del Oro Parlamento de Andalucía
La siguiente imagen es una captura de la aplicación con las posiciones GPS representadas en el GoogleMaps con los lugares visitados.
81
Estas son algunas de las fotos realizadas durante la prueba real de la aplicación.
82
83
9.
Ampliaciones
84
Esta aplicación está preparada para futuras ampliaciones, las cuales pueden ser tanto de mejora de la interfaz como de incorporación de nuevas funcionalidades. Una de las mejoras más interesante que vemos para este proyecto es la creación de un servicio web, este servicio mostraría de forma online lugares turísticos para que el usuario de la aplicación pudiera saber que puede visitar en su alrededor y la información del mismo. Se ha pensado que este servicio web se construiría con la ayuda de aquellos usuarios que quisieran colaborar, los usuarios deberían registrarse y al documentar un lugar turístico, se daría la oportunidad al usuario de subir ese lugar si lo desea, guardándose así la posición GPS del lugar, comentarios que ha hecho el usuario, enlace de wikipedia y alguna fotografía que quisiera subir. Una vez creado el servicio web con zonas turísticas se podría crear una opción de “ indicación ” dentro del mapa que te indica la posición del lugar, a semejanza con el “Google M aps ”, para mostrar la ruta desde la posición que se encuentra el usuario hasta
el lugar turístico al que se quiere ir. En cuanto a la interfaz de la aplicación somos conscientes de las mejoras que se pueden realizar. Al estar realizando un proyecto de fin de carrera hemos puesto mayor interés en la parte funcional de la aplicación y por supuesto en la documentación de la misma, ya que el objetivo de un proyecto fin de carrera es el demostrar que se tiene los conocimientos necesarios para llevar a cabo un proyecto y no el proyecto en sí, aunque esta última parte siempre es importante, pero sabemos que en un mundo laboral real este aspecto sería fundamental y que la mejora de la parte visual de la aplicación sería lo primero en mejorar para una posible comercialización. Como se acaba de comentar el objetivo de un proyecto fin de carrera es la demostración de que se tiene los conocimientos para diseñar y llevar a cabo un proyecto, en nuestro caso informático, y es donde se pone mayor interés. Por tanto el no llevar a cabo estas mejoras comentadas anteriormente no es por falta de ambición si no por falta de tiempo real.
85
10. Conclusiones
86
La finalización del proyecto final de carrera representa uno de esos momentos de la vida en los que merece la pena echar la vista atrás y hacer balance de todo lo pasado. No sólo significa el fruto de varios meses de desarrollo, sino que su entrega simboliza también la conclusión de toda una carrera a través de muchos años de entrega, sacrificio y duro trabajo. Las sensaciones que tenemos tras acabar este Proyecto Fin de Carrera son muy positivas. Nuestro objetivo principal, aprender todo lo posible sobre el desarrollo de aplicaciones para móviles bajo la plataforma Android ha sido cumplido. El desarrollo de Android , nos ha servido para tener una base de cara a futuros desarrollos, que seguro serán mucho más rápidos y ágiles. También hemos podido comprobar que es posible desarrollar una aplicación desde cero utilizando exclusivamente herramientas libres. Para un estudiante esto supone unas posibilidades impensables hace escasos años. Tener todas las herramientas disponibles en internet, y sin coste, permite que cualquier desarrollador interesado pueda programar aplicaciones sin tener que pertenecer a una empresa o universidad. Además, la distribución digital, la simplificación de conceptos en el sector, la proliferación de dispositivos móviles con grandes capacidades hardware y las facilidades para el desarrollo de los mismos, permiten que las aplicaciones lleguen a cualquier parte del mundo en el momento en el que terminen su desarrollo, casi sin costes de distribución. Desarrollando este proyecto hemos disfrutado, investigado y aprendido mucho sobre un tema que nos apasiona y que hasta ahora era desconocido a nivel técnico para nosotros. Además, hemos encontrado un sector en el que no nos importaría que se desarrollase nuestro futuro laboral. No obstante, a pesar del objetivo fundamental que supone la realización del proyecto, también hemos aprendido otros conocimientos:
Soltura con lenguajes de programación vistos durante el estudio de la carrera universitaria (Java, Xml). Manejo de la API de Android. Programar aplicaciones para teléfonos móviles. Desarrollo de aplicaciones de nueva generación con un gran futuro por delante. Avanzar en la investigación, tan importante en el mundo laboral. Redacción y publicación de documentos técnicos.
Y, en definitiva, consideramos que este Proyecto ha puesto a prueba nuestros conocimientos y nuestra capacidad de aprendizaje con un resultado positivo, y esperamos que el Tribunal lo considere de la misma forma, permitiéndonos obtener el título de Ingeniero Técnico en Informática de Sistemas.
87
Por último, queremos agradecer en primer lugar a nuestro tutor Dr. José Ramón Portillo Fernández todo el tiempo que nos ha dedicado guiándonos en la elaboración de esta documentación, y en segundo lugar pero no menos importante a nuestros familiares y amigos por todo el tiempo que le hemos quitado durante el periodo en el que hemos realizado este proyecto. Gracias a todos.
