Control automático de Bluetooth en dispositivos móviles con Android

Escuela Técnica Superior de Ingeniería Informática Universitat Politècnica de València Control automático de Bluetooth en dispositivos móviles con Android Proyecto Final de Carrera Ingeniería Informática Autor: Julián Zaragoza Bellotti Director: Miguel Ángel Mateo Pla 19 de septiembre de 2012 Resumen En la presente memoria, se detalla una manera de abordar el problema de la autonomía de los dispositivos (el cuál definiremos más adelante en el presente documento): El diseño e implementación de una aplicación para el sistema operativo Android que consiga economizar el consumo de la batería mediante la automatización del encendido y apagado del adaptador Bluetooth del dispositivo móvil. La aplicación se basará en un sistema de reglas (básicas o avanzadas), que combinadas entre ellas, harán que la aplicación encienda o apague el Bluetooth. La idea es implementar un editor de reglas simple, mediante una interfaz gráfica clara e intuitiva, que mediante un asistente pueda crear reglas sencillas. También tendrá una opción de creación avanzada de reglas, basadas en un simple editor de texto y un lenguaje de definición de reglas. Para poder construir las reglas avanzadas es necesario crear una serie de reglas básicas, las cuales deben ser creadas mediante el asistente anteriormente mencionado. Las reglas se basarán en geolocalización, dispositivos cercanos, tiempo y estado de la batería. Las reglas se almacenarán en la memoria del dispositivo (Interna o externa), y además también existirá la opción de exportarlas a un archivo .zip, el cuál también se podrá importar posteriormente. De esta manera es posible guardar una copia de seguridad de nuestra base de reglas en caso de borrado de memoria / formateo / cambio de dispositivo. Para poder llevar a cabo todo esto, se hará uso de guías de diseño para Android, y además, de ayudas en la interfaz gráfica que ayuden al usuario a tener una experiencia con la aplicación lo más intuitiva posible. Palabras clave: Android, reglas, dispositivo, móvil, exportar. Índice general 1. Introducción 6 1.1. Objetivos ............................. 6 1.2. Puntodepartida ......................... 9 2. Descripción del entorno 10 2.1. Bluetooth ............................. 10 2.2. Android .............................. 14 2.2.1. Definición ......................... 14 2.2.2. Arquitectura........................ 15 2.2.3. Anatomía de las aplicaciones Android . . . . . . . . . . 17 2.2.3.1. Componentes de una aplicación . . . . . . . . 17 2.2.3.2. Ciclo de vida de una actividad: . . . . . . . . 19 3. Definición del problema 20 3.1. Definición del problema . . . . . . . . . . . . . . . . . . . . . . 20 4. Análisis 22 4.1. Requisitos............................. 22 4.1.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . 22 4.1.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . 23 4.1.3. Requisitos de implementación . . . . . . . . . . . . . . 24 4.2. Actores............................... 24 4.3. Casosdeuso............................ 26 4.3.1. Modelo de casos de uso . . . . . . . . . . . . . . . . . . 37 5. Diseño 38 5.1. Diagrama de paquetes . . . . . . . . . . . . . . . . . . . . . . 38 5.2. Reglas ............................... 40 5.3. Diseño de la Interfaz Gráfica de Usuario. . . . . . . . . . . . . 42 5.4. Gramática ............................ 52 2 Índice general Índice general 6. Implementación 53 6.1. Implementación de las reglas . . . . . . . . . . . . . . . . . . . 53 6.2. Exportar e importar reglas. . . . . . . . . . . . . . . . . . . . 60 6.3. Reglasavanzadas ......................... 60 6.4. Interfazgráfica .......................... 61 6.5. Seccióndeayuda.......................... 62 7. Ejemplos de funcionamiento 65 8. Conclusiones 69 9. Definiciones 71 3 Índice de figuras 2.1. Arquitectura del sistema Android . . . . . . . . . . . . . . . . 17 2.2. Ciclo de vida de las actividades en Android. . . . . . . . . . . 19 4.1. Modelo de casos de uso . . . . . . . . . . . . . . . . . . . . . . 37 5.1. Diagrama de paquetes . . . . . . . . . . . . . . . . . . . . . . 39 5.2. Diagrama de clases de las reglas . . . . . . . . . . . . . . . . . 41 5.3. Diagrama de clases de Activities . . . . . . . . . . . . . . . . . 43 5.4. Tabla de numeración de Activities . . . . . . . . . . . . . . . . 44 5.5. Diseño de la interfaz de DashboardActivity . . . . . . . . . . . 44 5.6. Diseño de la interfaz de HelpActivity . . . . . . . . . . . . . . 45 5.7. Diseño de la interfaz de BatteryActivity . . . . . . . . . . . . 45 5.8. Diseño de la interfaz de AdvancedActivity . . . . . . . . . . . 46 5.9. Diseño de la interfaz de LocationActivity . . . . . . . . . . . . 47 5.10. Diseño de la interfaz de AddLocationActivity . . . . . . . . . . 48 5.11. Diseño de la interfaz de ClockRuleActivity . . . . . . . . . . . 49 5.12. Diseño de la interfaz de StandardActivity . . . . . . . . . . . . 50 5.13. Diseño de la interfaz de BluetoothPreferencesActivity . . . . . 51 5.14. Diseño de la interfaz de AboutDialog . . . . . . . . . . . . . . 52 5.15. Gramática del lenguaje de definición de reglas avanzadas . . . 52 6.1. Fragmento de la interfaz Rule . . . . . . . . . . . . . . . . . . 53 6.2. Fragmento de la clase BatteryRule.java . . . . . . . . . . . . . 54 6.3. Fragmento de la clase TimeRule.java . . . . . . . . . . . . . . 55 6.4. Fragmento de AddLocationActivity.java, referenciando la geolocalización............................ 56 6.5. Fragmento de StandardActivity.java, referenciando la geolocalización ............................. 57 6.6. Fragmento de AddLocationActivity donde se localiza el mapa 58 6.7. Fragmento de BluetoothService.java . . . . . . . . . . . . . . . 59 4 Índice de figuras Índice de figuras 6.8. Fragmento de ComplexRule.java donde se lanza el procesador delenguajes............................ 61 6.9. dashboard_background.xml . . . . . . . . . . . . . . . . . . . 62 6.10. help.xml, con la vista ViewPager . . . . . . . . . . . . . . . . 63 6.11. Fragmento de HelpActivity.java . . . . . . . . . . . . . . . . . 64 7.1. Añadir regla de tiempo . . . . . . . . . . . . . . . . . . . . . . 65 7.2. Añadir regla de batería . . . . . . . . . . . . . . . . . . . . . . 66 7.3. Añadir regla avanzada . . . . . . . . . . . . . . . . . . . . . . 67 7.4. Exportación e importación de reglas . . . . . . . . . . . . . . . 67 7.5. Ayuda de la aplicación . . . . . . . . . . . . . . . . . . . . . . 68 5 Capítulo 1 Introducción 1.1. Objetivos En el Proyecto de Final de Carrera (descrito en la presente memoria), se va a realizar una aplicación para el sistema operativo Android, el cuál controle el principal problema de los dispositivos móviles avanzados hoy en día: La autonomía de la batería. La aplicación deberá conseguir alargar la autonomía de la batería mediante un tratamiento automatizado del encendido y apagado del adaptador Bluetooth del dispositivo. Para conseguir automatizarlo, es necesario que el usuario sea capaz de transmitir a la aplicación aquellas situaciones en las que le interese que la conexión Bluetooth esté habilitada, y aquellas en las que no. Definir un conjunto de reglas que el dispositivo sea capaz de identificar, será la manera de conseguir que el usuario se comunique con la máquina, y le transmita sus preferencias a la hora de la activación y desactivación. Ese conjunto de reglas deberá estar diferenciado en dos tipos: Reglas simples yreglas avanzadas. Las reglas simples sólo podrán ser creadas mediante diálogos y Activities de Android (Lo cuál explicaremos más adelante en el presente escrito), los cuales permitirán la introducción de los datos mediante cuadros de texto, selectores y demás herramientas gráficas clásicas. Las reglas básicas que están establecidas como objetivo para la siguiente aplicación son: Regla de tiempo: Regla que basa la activación o desactivación en el paso del tiempo. Los parámetros temporales que tendrá en cuenta la regla serán el rango de fechas, el día o días de la semana, y el rango de horas a la que será efectiva. Si se dan todas las condiciones dentro de la regla, el adaptador Bluetooth se activará. Regla de proximidad: Regla que basa al activación o desactivación en 6 Capítulo 1. Introducción 1.1. Objetivos la proximidad o lejanía de un punto concreto en el espacio. Es decir, basa su activación en la geolocalización del dispositivo y su posición con respecto a un lugar de referencia. Regla de dispositivos conocidos: Regla que basa la activación o desactivación en la detección de dispositivos conocidos alrededor del dispositivo móvil. Si existe algún dispositivo que esté dentro de una lista definida por el usuario, el Bluetooth se activará. Regla de batería: Regla que activa o desactiva el Bluetooth según el nivel de batería o si el dispositivo se está alimentando. El usuario podrá definir reglas basadas en las anteriores definiciones, y éste deberá decidir entre dos maneras de aplicarlas si hay contradicciones entre ellas: Prioridad al encendido: Ante conflicto, se dará prioridad al encendido del Bluetooth, es decir, el valor de ’true’ (encendido) y ’false’ (apagado) de cada una de las reglas es unido mediante ’OR’ lógicas. Prioridad al apagado: Ante conflicto, se dará prioridad al apagado del Bluetooth, es decir, el valor de encendido/apagado de las reglas es unido mediante ’AND’ lógicas. Si el usuario no desea este tipo de relación entre reglas y desea una combinación más compleja con operadores AND y OR combinados, deberá crear una regla avanzada. Las reglas avanzadas se crearán mediante un editor de texto integrado en la propia aplicación, en el cuál se tendrán que escribir las reglas relacionadas mediante paréntesis y los operadores AND / OR. Si la regla está escrita correctamente con respecto al mini-lenguaje creado para la ocasión, entonces podrá tratarse como una regla más y dará un valor de Bluetooth encendido / Bluetooth apagado. A su vez, las reglas complejas también pueden relacionarse con otras mediante prioridad al encendido y prioridad al apagado. Para evitar que puedan ’molestar’ las reglas básicas en estos casos, todas las reglas (Aunque estén creadas) tienen la opción de ser activadas o desactivadas. Esta opción sera efectiva a nivel alto de regla, es decir, si es una regla compleja, y alguna de sus reglas está ’desactivada’, las tratará como activadas, pero la regla simple en sí no contará en la prioridad general (Ya que para poder utilizar una regla en una combinación avanzada, la regla ya tiene que existir previamente). La idea, es que el usuario ’medio’ sea capaz de crear reglas sencillas, y el usuario ’avanzado’ puede también crear reglas avanzadas según sus necesidades. De todas formas, se intentará que el usuario tenga la mayor ayuda 7 1.1. Objetivos Capítulo 1. Introducción posible por parte de la aplicación para explicar todos esto conceptos necesarios para su uso, los cuales son complejos de inicio para quien utilice la aplicación. Para ello, se va a tratar de crear una interfaz gráfica de usuario lo más sencilla e intuitiva posible, tomando patrones de diseño de Android, y haciendo hincapié sobre todo en la parte de creación básica de reglas (la que por definición se orienta al usuario medio). Si los usuarios aún así no son capaces de comprender el funcionamiento del programa, también podrán disponer de una ayuda avanzada accesible en todo momento desde la ’Action Bar’ superior (Definición 1 en la página 71). En esta ayuda, la cuál se presentará en forma de “páginas” desplazables mediante gestos, mostrará tanto explicaciones como capturas de pantalla con indicaciones. También se hará un esfuerzo en conseguir un diseño agradable al usuario, de forma que el aspecto general de la aplicación tenga un aspecto grafico de aplicación para Android, pero alejándose lo más posible del aspecto de componentes ’por defecto’, muy común en aplicaciones presentes en ’Google Play’ (Definición 2 en la página 71) realizadas por desarrolladores independientes ’amateur’. Las reglas se almacenarán (en formato XML) dentro del propio dispositivo, o , en caso de existir, en la memoria SD. Pero estas reglas se perderían en caso de borrado de los datos de la aplicación (En las preferencias de Android) o en caso de cambio de dispositivo. Esto es especialmente crítico en el caso de las reglas avanzadas, pues puede que el tiempo de elaboración de una de estas reglas sea alto y no sea agradable volver a realizarla. Para ello, se añadirá una opción de exportar e importar en las preferencias generales de la aplicación: Al exportar, se generará un archivo ’zip’ con todos los ficheros XML de la aplicación, y éste podrá ser guardado en cualquier lugar del sistema de archivos (que tenga permisos). Por su parte, al importar, se copiarán los ficheros del .zip importando dentro de la memoria en la cuál la aplicación los guarde (sea la memoria interna o la tarjeta SD). Una vez definidos los objetivos de la aplicación en sí, hace falta definir la manera en la que se comprobarán las reglas. Para ello, se hará una comprobación cada cierto período de tiempo aplicando la prioridad que el usuario haya seleccionado. Habrá que llegar a un compromiso entre tiempo de comprobación y consumo de batería, ya que no podemos permitir que la propia comprobación de las reglas acabe consumiendo más energía en el dispositivo que el propio uso del adaptador Bluetooth. 8 Capítulo 2. Descripción del entorno 2.2. Android desarrolladores de hardware, software y operadores de servicio. Está basado en el kernel de Linux, y actualmente la gran mayoría del código de Android está liberado bajo licencia Apache. 2.2.2. Arquitectura Android está formado por varias capas que facilitan al desarrollador la creación de aplicaciones. La distribución en capas permite acceder a capas más bajas mediante el uso de librerías, evitando la programación a bajo nivel por parte del desarrollador. Como nos cuenta [Condesa2011], cada una de las capas utiliza elementos de la capa inferior para realizar sus funciones, formando una pila: Kernel Linux: El núcleo del sistema operativo Android está basado en el kernel 2.6 de Linux, similar al que se puede utilizar en distribuciones de Linux, pero con ciertas modificacioens, como optimización para un mayor rendimiento. El programador no accede al kernel directamente, sino que debe utilizar librerías disponibles en capas superiores. Se encarga de gestionar los recursos del dispositivo ( energía, memoria...) y del sistema operativo en sí (Procesos, comunicación, red... etc). También están incluidos los drivers de los componentes que tenga el dispositivo móvil. Librerías: Son las bibliotecas nativas de Android. Están escritas en C/C++ y compiladas para la arquitectura hardware específica del dispositivo. Están hechas normalmente por el fabricante, el cuál se encarga de que estén presentes en el dispositivo antes de su venta. Las liberías proporcionan funcionalidad a las aplicaciones para tareas repetidas con frecuencia, evitando tener que codificarlas cada vez y garantizando que se realicen de manera eficiente. Entre las librerías incluidas habitualmente se encuentran: OpenGL, bibliotecas multimedia (audio, video, e imagen), Webkit, SSL, FreeType, SQLite... Entorno de ejecución (Runtime): Es una sub-capa formada por librerías. El componente principal es la máquina virtual Dalvik, ya mencionada anteriormente. Framework de aplicaciones : Formada por las clases y servicios que utilizan directamente las aplicaciones para realizar sus funciones. La mayoría de los componentes de esta capa son librerías Java que acceden a recursos de las capas inferiores a través de Dalvik. Las más importantes son: Activity Manager: Se encarga de administrar la pila de actividades de nuestra aplicación y su ciclo de vida. Una actividad es lo que equivaldría a una ‘ventana’ en un sistema operativo convencional para PC como Windows, o Linux con escritorio gráfico (Gnome, KDE, XFCE, LXDE... etc), con la 15 2.2. Android Capítulo 2. Descripción del entorno particularidad de ocupar la pantalla entera y ser apilable, pudiendose así mostrar otras actividades relacionadas (o no) posicionándose ‘encima’. Windows Manager: Se encarga de organizar lo que se mostrará en pantalla. Básicamente, crea superficies en la pantalla que posteriormente pasarán a ser utilizadas por las actividades. Content Provider: Es la librería que encapsula los datos que se compartirán entre las aplicaciones, de manera que tiene el control sobre el acceso a la información. Views: Una vista es un elemento básico del cual parten todos los elementos básicos que mostrarán las actividades: Botones, cuadros de texto, listas... etc. Notification Manager: Engloba los servicios para notificar al usuario cuando algo requiera su atención mostrando alertas en la barra de estado. Esta librería también permite la utilización de sonidos, activar la vibración del dispositivo, o utilizar leds en caso de existir. Package Manager: Permite obtener información sobre los paquetes instalados en el dispositivo Android, y también se encarga de la instalación de nuevos paquetes. Los paquetes de Android tienen la extensión ‘.apk’, y contienen los binarios ‘.dex’ y todos los recursos dependientes de éste. Telephony Manager: Esta librería permite realizar llamadas o enviar y recibir SMS/MMS, aunque no puede reemplazar o eliminar la actividad que se muestra cuando una llamada está en curso. Resource Manager: Permite la gestión de todos los elementos que están incluidos en la aplicación pero fuera del código. Location Manager: Permite determinar la posición geográfica del dispositivo Android mediante GPS o redes disponibles y trabajar con mapas. Sensor Manager: Permite manipular los elementos de hardware del teléfono tales como acelerómetro, giroscopio, sensor de luminosidad, sensor de campo magnético, brújula, sensor de presión, sensor de proximidad, sensor de temperatura... Cámara : Esta librería proporciona la posibilidad de utilizar las cámaras del dispositivo para tomar fotografías o vídeo. Multimedia: Permite reproducir y visualizar vídeo, imágenes y audio. Aplicaciones : Es la capa de más alto nivel. En ella se incluyen todas las aplicaciones del dispositivo, tanto las que tienen interfaz gráfica de usuario como las que no, las nativas (programadas en C/C++) y las administradas (En Java). También se encuentra la aplicación principal del sistema: el Home o Launcher, que es la que permite ejecutar otras aplicaciones mostrándolas en forma de lista, y proporcionando al usuario una serie de escritorios donde colocar accesos directos, Widgets de escritorio.... etcétera. 16 Capítulo 2. Descripción del entorno 2.2. Android Figura 2.1: Arquitectura del sistema Android 2.2.3. Anatomía de las aplicaciones Android 2.2.3.1. Componentes de una aplicación Una aplicación Android, tal y como cuenta [ADevelopers2012b], está compuesta por los siguientes elementos: Activity (Actividad): Según su definición en Android Developers, es un componente de aplicación que provee una pantalla sobre la cuál el usuario puede interactuar para conseguir un objetivo (por ejemplo, llamar por teléfono, hacer una fotografía, enviar un correo electrónico, ver un mapa... etcétera). Cada actividad proporciona una ventana en la cual dibuja su interfaz de usuario. La ventana, normalmente se adapta a la totalidad de la pantalla. Una aplicación se compone, normalmente, de múltiples actividades interrelacionadas entre ellas. Lo común es que exista una actividad principal que se abra en cuanto se ejecute la aplicación. Cada Activity puede iniciar otras actividades si la lógica del programa lo requiere. Cada vez que una actividad se inicia, la anterior Activity se para (pasa al estado ‘stopped’ visto más adelante), pero la preserva dentro de la ‘pila de actividades’, por debajo de la nueva. Sin embargo, si el usuario pulsa el botón atrás del dispositivo Android, la Activity que estaba en pantalla se desapila, mostrando la que había anteriormente. 17 2.2. Android Capítulo 2. Descripción del entorno Posteriormente en este documento se detallará más acerca del ciclo de vida de una actividad. Service (Servicio): Un servicio es un componente que puede realizar operaciones ejecutándose en segundo plano, sin proporcionar ninguna interfaz gráfica. Un servicio puede ser iniciado por otro componente de aplicación y seguirá ejecutándose en segundo plano aunque el usuario cambie a otra aplicación. Adicionalmente, un componente puede unirse a un servicio para interactuar con él mediante comunicación interprocesos. Un servicio tiene dos formas: •Started (iniciado): Ocurre cuando un componente de aplicación (como una actividad) inicia un servicio con la llamada ‘startService()’ . Una vez iniciado el servicio, éste se ejecuta en segundo plano indefinidamente aunque el componente iniciador sea destruido. Normalmente se utiliza para realizar una sola operación que no devuelva nada al iniciador. •Bound (Enlazado) : Ocurre cuando un componente de aplicación inicia un servicio con la llamada ‘bindService()’. Un servicio enlazado ofrece una interfaz cliente - servidor que permite a los componentes interactuar con él, enviar peticiones, obtener resultados... etcétera. Un servicio enlazado sólo está en ejecución mientras exista algún componente enlazado con él. Se pueden enlazar múltiples componentes a un servicio, pero en cuanto todos sean destruidos, el servicio también se destruirá. Aunque existen dos formas a priori diferenciadas, un servicio también puede funcionar de ambas formas a la vez (Puede ser iniciado con ‘startService()’ pero puede permitir ser enlazado a posteriori). Esto depende de un grupo de métodos, los cuales pueden ser sobreescritos para propocionar una o ambas funcionalidades. BroadcastReceiver (Receptores de difusión): Se trata de un componente destinado a detectar y reaccionar ante eventos, mensajes globales del sistema u otras aplicaciones que manden un mensaje (Mediante ‘Intents’, el cuál es un mecanismo de paso de mensajes entre procesos además de iniciador de acciones). ContentProvider (Proveedores de contenido) : Un Content Provider es el encargado de manejar el acceso a información estructurada. Se encarga de encapsular la información, y ofrecer mecanismos para definir 18 Capítulo 2. Descripción del entorno 2.2. Android la seguridad de la información. Son la interfaz estándar que conecta los datos de un proceso con código en ejecución de otro proceso. Cuando quieres acceder a información por medio de un Content Provideer, puedes usar el objeto ‘ContentResolver’ dentro de la aplicación. Android incluye una serie de proveedores de contenido por defecto para manejar audio, vídeo, imágenes e información personal de contacto. Con algunas restricciones, son accesibles por cualquier aplicación de Android. 2.2.3.2. Ciclo de vida de una actividad: Como hemos indicado anteriormente, Android maneja las actividades como una pila: Cuando se crea una actividad, se coloca en lo más alto de la pila y se convierte en la Activity en ejecución. En la siguiente figura, extraída de [ADevelopers2012], podemos observar como los diferentes métodos del ciclo de vida de una actividad dan lugar a diferentes estados de ésta: Figura 2.2: Ciclo de vida de las actividades en Android. 19 Capítulo 3 Definición del problema 3.1. Definición del problema Durante muchos años, la telefonía móvil y la informática han ido evolucionando a pasos agigantados. Mientras los ordenadores han seguido un camino en el que se desea conseguir cada vez más y mejores prestaciones, los dispositivos móviles se han centrado en ofrecer mejores servicios consiguiendo el menor consumo energético posible. Durante un tiempo, las PDA llegaron a ser las reinas dentro de la informática ‘de bolsillo’, con una relación consumo / prestaciones aceptables para la época. Sin embargo, la popularidad de los Smartphones, los cuales integran las PDA con los teléfonos móviles, ha favorecido la desaparición de estos dispositivos, quedando en el recuerdo de muchos y muchas. En la actualidad, hay dos grandes familias de sistemas operativos para smartphones y tablets: iOS de Apple (Para iPhone, iPad y iPod), y Android (Sobre el cuál nos centraremos más adelante). Por su parte, Blackberry continúa con su gama de smartphones y su sistema operativo propio, y Microsoft intentó remontar en el mundo de los smartphones con Windows Phone (Un buen producto, pero tardío con un mercado ya copado), y en el de los tablets modernos con la Microsoft Surface y Windows 8 de sistema operativo (Resaltando el hecho de que a principios de la década de los 2000, fue Microsoft la que lanzó su Tablet PC, con más bien poco éxito). Por su parte, Android (Desarrollado por Google, aunque originario de la Open Handset Alliance), ha conseguido hacerse un hueco gracias a su flexibilidad ante las diferentes características de los dispositivos, a costa de aumentar el coste temporal en el desarrollo de aplicaciones. Volviendo al consumo de los dispositivos, las baterías han conseguido aumentar su capacidad durante los últimos años, consiguiendo teléfonos móviles clásicos que consiguen permanecer sin necesidad de carga durante más de una o incluso dos semanas. 20 Capítulo 3. Definición del problema 3.1. Definición del problema Sin embargo, la mayor exigencia de los smartphones en cuanto a potencia, también hacen que la duración de la batería se acorte radicalmente a pesar de los avances comentados anteriormente. Es por ello, que cada vez es más común la utilización de aplicaciones o herramientas que, ya sea automatizando algunos procesos o accediendo a parámetros como control de voltaje, de velocidad de procesador... etc, nos permitan alargar sensiblemente el período hasta la siguiente recarga. En la presente memoria, se detalla esta manera de abordar el problema de la autonomía de los dispositivos: El diseño e implementación de una aplicación para el sistema operativo Android que consiga economizar el consumo de la batería mediante la automatización del encendido y apagado del adaptador Bluetooth del dispositivo móvil. Para poder resolver este problema, debemos también lidiar con otros directamente relacionados con los dispositivos Android: La fragmentación de dispositivos. Existen dispositivos con Bluetooth, sin Bluetooth, con diferente comportamiento al tratar con el adaptador Bluetooth... etcétera. Con un poco de experiencia en el desarrollo Android, se puede intuir que, sin disponer de la gran cantidad de dispositivos existentes, es prácticamente imposible hacer funcionar una aplicación en el cien por cien de los dispositivos, por lo menos, de inicio. Siempre habrá algún dispositivo que, por alguna diferencia en el hardware , tratamiento del ciclo de vida... etcétera, el programa fallará o no funcionará como es esperado. Es por ello, que el diseño inicial del programa tiene un peso muy importante como solución, así como mantener el propio software aunque esté publicado ya en la plataforma “Google Play” e ir corrigiendo fallos y bugs. 21 Capítulo 4 Análisis En esta parte de la memoria, hablaré del trabajo de diseño de la aplicación. En primer lugar, se presentan los requisitos de la aplicación tanto funcionales, como no funcionales y de implementación. Tras ello, se presentarán los actores que influyen en la aplicación, y posteriormente, los casos de uso de la aplicación. Una vez hecho esto, se mostrará el modelo de casos de uso de la aplicación. 4.1. Requisitos 4.1.1. Requisitos funcionales El usuario deberá poder arrancar el servicio de encendido/apagado de Bluetooth. Para ello, bastará con abrir la aplicación y observar el icono de ésta en la bandeja del sistema. El usuario deberá poder detener el servicio de encendido/apagado de Bluetooth. Para ello, bastará con presionar la opción ’salir’ en el menú principal (dashboard 5) de la aplicación. El usuario podrá crear ’reglas de Bluetooth’ en el modo ’estándar’. Las reglas que podrá crear serán de tiempo, de lugar, de dispositivo o de batería. El usuario podrá crear ’reglas de Bluetooth’ en el modo ’avanzado’. Para ello, deberá conocer previamente la sintaxis del lenguaje de especificación de reglas definido en la ayuda de la aplicación. El usuario debe poder editar ’reglas de dispositivo’ tanto en el modo ’estándar’ como en el ’avanzado’. 22 Capítulo 4. Análisis 4.1. Requisitos El usuario podrá eliminar cualquier regla en el modo ’estándar’. La aplicación deberá poder guardar las reglas en la memoria del dispositivo, sea interna o externa. Al crear o editar una regla de tiempo, el usuario podrá introducir tanto fecha inicial y final, como día de la semana como hora inicial y final, el los cuales el dispositivo Bluetooth permanecerá encendido. Al crear o editar una regla de batería, el usuario podrá introducir el nivel de batería ’umbral’. Al crear o editar una regla de dispositivo, el usuario podrá buscar dispositivos cercanos, y al seleccionar uno de ellos, el sistema deberá ser capaz de almacenarlo como ’dispositivo conocido’. Al crear o editar una regla de dispositivo, el usuario deberá poder eliminar dispositivos conocidos. Al crear o editar una regla de lugar, el usuario deberá poder eliminar lugares conocidos. Al crear o editar una regla de lugar, el usuario podrá localizarse y, si lo desea, mandar al sistema almacenar la ubicación como conocida. El sistema debe ser capaz, en función de las reglas definidas por el usuario, activar o desactivar el dispositivo Bluetooth en concordancia con éstas. El usuario deberá escoger entre dar prioridad a las reglas que mandan encender el Bluetooth o las que mandar apagarlo. El usuario de la aplicación podrá abrirla directamente desde el escritorio y de forma rápida. El usuario, podrá exportar en un fichero todas las reglas u otra información de la aplicación. De esta manera podrá transportarlo o realizar una copia de seguridad. 4.1.2. Requisitos no funcionales La aplicación deberá tener una interfaz intuitiva, acompañada de una ayuda detallada en la justa medida para ser fácil de entender y útil. La aplicación deberá mejorar el consumo de batería, es decir, no debe consumir más batería de la que ahorra. 23 4.2. Actores Capítulo 4. Análisis La aplicación deberá consumir poca memoria RAM y ocupar poco espacio en la memoria interna/externa del dispositivo. 4.1.3. Requisitos de implementación La aplicación deberá ser desarrollada para el sistema operativo Android, a partir de la versión 2.1 (Eclair). A su vez, la densidad o resolución de pantalla no deberá influir en el funcionamiento de la aplicación. La aplicación no deberá ejecutarse en los dispositivos Android que no dispongan de un adaptador Bluetooth. La aplicación deberá ajustarse a los patrones de diseño de Android, presentes en el apartado de diseño de Android Developers. 4.2. Actores Los actores que tienen cabida en los casos de uso de esta aplicación son los siguientes: Actor Usuario Identificador USU1 Descripción Persona usuaria de la aplicación móvil Android. Características Usuario de Smartphone o tablet con sistema operativo Android 2.1 o superior, que disponga de la aplicación ’Bluetooth Administrator’. Relaciones Referencias ARSE1, DETSE1, ELIREG1, CAMPRIO1, EXPOREG1, IMPOREG1 Autor Julián Zaragoza Fecha 05/08/2012 Versión v1 Atributos Nombre Descripción Tipo Vacío Vacío Vacío Comentarios El usuario será genérico, es decir, no se tiene en cuenta su nivel de conocimiento acerca de Android, Bluetooth... etcétera. 24 Capítulo 4. Análisis 4.3. Casos de uso 3 El usuario solicita añadir una regla de dispositivo 4 La aplicación muestra el diálogo de añadir una regla de dispositivo 5 El usuario selecciona añadir un dispositivo conocido. 6 La aplicación muestra el diálogo de añadir un nuevo dispositivo 7 El usuario selecciona el dispositivo y marca la regla para guardar. 8 La aplicación guarda la regla en el sistema 9 La aplicación vuelve al panel de edición estándar. Cursos Alternos 7b Si ya hay una regla con ese nombre, vuelve a 4. 5b Si ya hay añadido algún dispositivo que sea de nuestro agrado, se pasa al paso 7. Caso De Uso Edición de regla estándar EDREST1 Actores Usuario Básico Tipo Primario Referencias Precondición El servicio de comprobación de Bluetooth estará iniciado en segundo plano. Postcondición La regla definida será almacenada por el sistema y podrá ser comprobada. Autor Julián Zaragoza Fecha 05/08/2012 Versión v1 Propósito Edición de una regla del dispositivo. Resumen El usuario modificará una regla. Curso Normal (Básico) 31 4.3. Casos de uso Capítulo 4. Análisis 1 El usuario entra en el modo de edición estándar 2 Se muestra el panel de edición estándar 3 El usuario selecciona la regla que quiera editar, y solicita su edición. 4 La aplicación muestra el diálogo de la regla propia, con los datos actuales de ésta. 5 El usuario modifica los datos que considere. 6El usuario solicita guardar la regla. 7 La aplicación guarda la regla en el sistema 8 La aplicación vuelve al panel de edición estándar. Cursos Alternos 6b Si ya hay una regla con ese nombre, vuelve a 4. Caso De Uso Creación de regla avanzada REAVA1 Actores Usuario Avanzado Tipo Primario Referencias Precondición El servicio de comprobación de Bluetooth estará iniciado en segundo plano. Postcondición La regla definida será almacenada por el sistema y podrá ser comprobada. Autor Julián Zaragoza Fecha 05/08/2012 Versión v1 Propósito Creación de una regla avanzada del dispositivo. Resumen El usuario creará una regla avanzada. Curso Normal (Básico) 1 El usuario entra en el modo de edición avanzado 2 Se muestra el panel de edición avanzado 32 Capítulo 4. Análisis 4.3. Casos de uso 3 El usuario escribe una regla según la sintaxis definida en la ayuda de la aplicación 4El usuario comprueba la regla 5 El sistema reconoce la regla como válida. Marca la regla como validada. 6El usuario solicita guardar la regla. 7 La aplicación guarda la regla en el sistema 8 La aplicación vuelve al panel de edición estándar. Cursos Alternos 5b Si la regla no es válida, se marca como no validada. 6b Si ya existe una regla con ese nombre, se vuelve a 6 Caso De Uso Eliminación de regla ELIREG1 Actores Usuario Tipo Primario Referencias Precondición Debe existir en el sistema alguna regla. Postcondición La regla elegida dejará de existir en el sistema. Autor Julián Zaragoza Fecha 06/08/2012 Versión v1 Propósito Eliminación de cualquier regla del dispositivo. Resumen El usuario eliminará una regla del sistema, sea estándar (lugar, tiempo, dispositivo o batería) o avanzada. Curso Normal (Básico) 1 El usuario entra en el modo de edición estándar. 2 Se muestra el panel de edición estándar. 33 4.3. Casos de uso Capítulo 4. Análisis 3 El usuario selecciona la regla que desea eliminar 4El usuario pulsa la acción de eliminar 5 El sistema pregunta si desea realmente eliminar la regla 6 El usuario confirma la eliminación de la regla 7 La aplicación elimina la regla del sistema Cursos Alternos 6b Si el usuario no confirma la eliminación de la regla, se pasa a 2. Caso De Uso Cambiar de prioridad CAMPRIO1 Actores Usuario Tipo Primario Referencias Precondición El usuario debe estar en el panel de edición estándar. Postcondición Autor Julián Zaragoza Fecha 06/08/2012 Versión v1 Propósito Cambiar la prioridad de las reglas cambiará de ’prioridad encendido’ a ’prioridad apagado’. Resumen Si la prioridad está a encendido (Es decir, ante un conflicto de dos reglas que se contradigan en un momento del tiempo, se de prioridad a la activación del Bluetooth), se cambiará a apagado o viceversa. Curso Normal (Básico) 1 El usuario pulsa el interruptor de cambio de prioridad 2 Se muestra la prioridad contraria a la que funcionaba anteriormente. Cursos Alternos 34 Capítulo 4. Análisis 4.3. Casos de uso Caso De Uso Exportar reglas EXPOREG1 Actores Usuario Tipo Primario Referencias Precondición El usuario debe estar en el Dashboard Postcondición Autor Julián Zaragoza Fecha 06/08/2012 Versión v1 Propósito Guardar las reglas contenidas en el sistema en un archivo. Resumen El usuario podrá elegir un lugar en el espacio de archivos del dispositivo para guardar un fichero .zip con la información de las reglas contenidas. Curso Normal (Básico) 1 El usuario entra en las opciones del sistema. 2 El usuario elige la ruta donde se guardará el fichero 3 El sistema guarda el archivo en ese lugar. Cursos Alternos 3b Si no hay permisos de escritura en ese lugar, se notifica y se vuelve a 2. Caso De Uso Importar reglas IMPOREG1 Actores Usuario Tipo Primario Referencias Precondición El usuario debe estar en el Dashboard. Postcondición Autor Julián Zaragoza Fecha 06/08/2012 Versión v1 Propósito Importar las reglas desde un archivo hasta la memoria del dispositivo Resumen Curso Normal (Básico) 35 4.3. Casos de uso Capítulo 4. Análisis 1 El usuario entra en las opciones del sistema. 2 El usuario selecciona la ruta en la que está el archivo .zip con las reglas. 3 El sistema descomprime las reglas en la memoria interna. Cursos Alternos Caso De Uso Edición regla avanzada EDREGAV1 Actores UsuarioAvanzado Tipo Primario Referencias Precondición El usuario debe estar en el panel estándar. Postcondición Autor Julián Zaragoza Fecha 06/08/2012 Versión v1 Propósito Importar las reglas desde un archivo hasta la memoria del dispositivo Resumen Curso Normal (Básico) 1 El usuario selecciona la regla avanzada 2El usuario selecciona ’editar’ 3 El sistema muestra la pantalla de regla avanzada con los datos de la regla. 4 El usuario edita la regla y selecciona guardar 5 El sistema guarda la regla Cursos Alternos 5b Si la regla no es correcta, el sistema avisa y pregunta si quiere guardar igualmente. 36 Capítulo 4. Análisis 4.3. Casos de uso 4.3.1. Modelo de casos de uso Una vez presentados los actores y los casos de uso, podemos mostrar el Modelo de Casos de Uso de nuestra aplicación. Figura 4.1: Modelo de casos de uso 37 Capítulo 5 Diseño En el apartado de diseño vamos a mostrar la arquitectura de la aplicación y su diagrama de clases como paso posterior a la definición de requisitos y casos de uso. También se mostrará un esquema de las pantallas de la aplicación con el flujo lógico entre ellas. 5.1. Diagrama de paquetes A continuación vamos a mostrar el diagrama de los paquetes que van a componer nuestra aplicación Android. Los paquetes básicos utilizados son: Bluetoothadmin, Bluetoothadmin.libs, Bluetoothadmin.logic, Bluetoothadmin.parser y Bluetoothadmin.services. 38 Capítulo 5. Diseño 5.1. Diagrama de paquetes Figura 5.1: Diagrama de paquetes Vamos a describir los paquetes de la aplicación: Bluetoothadmin : Es el paquete principal de la aplicación y el resto de paquetes están incluidos en él. Las clases que se encontrarán dentro de este paquete serán las ’Activities’, es decir las pantallas gráficas de la aplicación. Bluetoothadmin.libs : En este paquete se alojarán todas las clases importantes de la aplicación incluyendo reglas, explorador de archivos, listeners de Bluetooth, listeners de posición y librerías para guardar en memoria. Bluetoothadmin.parser : Aquí estarán las clases del parser del minilenguaje del modo avanzado de la aplicación, es decir, el analizador léxico y el sintáctico. Bluetoothadmin.services : Será el paquete donde se alojen los servicios en segundo plano de la aplicación. 39 5.2. Reglas Capítulo 5. Diseño Bluetoothadmin.logic : Aquí se alojarán las clases estáticas de la aplicación, las cuales se encargarán de guardar cierta lógica para el correcto funcionamiento. Con esta estructura se realizará la implementación de la aplicación, asegurando cierta independencia entre los tipos de clases y mejorando el entendimiento del código fuente del software que se va a realizar. 5.2. Reglas En esta parte vamos a presentar los diagramas de clases para mostrar la estructura de las reglas de la aplicación. 40 Capítulo 5. Diseño 5.3. Diseño de la Interfaz Gráfica de Usuario. Si se selecciona Home, se irá a 1 (DashboardActivity). Si se pulsa aceptar, se guardará la regla y se volverá a 10 (StandardActivity). Si se pulsa AND, se añade la palabra reservada ’and’ al editor de texto. Si se pulsa OR, se añade la palabra reservada ’or’ al editor de texto. Si se pulsa ’(’ se añade el símbolo reservado ’(’ al editor de texto. Si se pulsa ’)’ se añade el símbolo reservado ’)’ al editor de texto. Si se pulsa ’+’ se añade el nombre de la regla del desplegable al editor de texto. LocationActivity : Es la pantalla en la que se crea la regla de lugar. En ella aparece una lista de lugares conocidos, de la cuál se ha de escoger uno para la regla. Si no hay lugares conocidos, se deberán añadir en AddLocationActivity. Figura 5.9: Diseño de la interfaz de LocationActivity El flujo de control de esta actividad es el siguiente: Si se pulsa Estándar, se vuelve a 10 (StandardActivity). Si se pulsa Avanzado, se pasa a 4 (AdvancedActivity). Si se selecciona el interrogante, se procede a ir a 2 (HelpActivity). 47 5.3. Diseño de la Interfaz Gráfica de Usuario. Capítulo 5. Diseño Si se selecciona Home, se irá a 1 (DashboardActivity). Si se pulsa aceptar, se guardará la regla y se volverá a 10 (StandardActivity). Si se pulsa +, se irá a 6 (AddLocationActivity). AddLocationActivity : Es la actividad donde puede seleccionarse un lugar y añadirlo a la lista de lugares conocidos. Figura 5.10: Diseño de la interfaz de AddLocationActivity El flujo de control de esta pantalla es: Si se pulsa Estándar, se vuelve a 10 (StandardActivity). Si se pulsa Avanzado, se pasa a 4 (AdvancedActivity). Si se selecciona el interrogante, se procede a ir a 2 (HelpActivity). Si se selecciona Home, se irá a 1 (DashboardActivity). Si se pulsa aceptar, se guarda el lugar y se vuelve a 5 (LocationActivity). ClockRuleActivity : Se trata de la pantalla para crear reglas de tiempo. En ella pueden añadirse rangos de días y/o horas, además de días de la semana donde será efectiva la activación del Bluetooth. También hay configuraciones predefinidas que rellenan las opciones automáticamente. 48 Capítulo 5. Diseño 5.3. Diseño de la Interfaz Gráfica de Usuario. Figura 5.11: Diseño de la interfaz de ClockRuleActivity Si se pulsa Estándar, se vuelve a 10 (StandardActivity). Si se pulsa Avanzado, se pasa a 4 (AdvancedActivity). Si se selecciona el interrogante, se procede a ir a 2 (HelpActivity). Si se selecciona Home, se irá a 1 (DashboardActivity). Si se pulsa Aceptar, se vuelve a 10 (StandardActivity) pero habiendo añadido la regla. StandardActivity : Se trata de la Activity de más importancia de toda la aplicación. Es la pantalla de creación de reglas estándar, y también una de las más complejas. En ella, se pueden crear, editar, y borrar reglas. La interfaz será como muestra la Figura 3.13. 49 5.3. Diseño de la Interfaz Gráfica de Usuario. Capítulo 5. Diseño Figura 5.12: Diseño de la interfaz de StandardActivity La lógica de la actividad es la siguiente: Si se pulsa Estándar, se vuelve a 10 (StandardActivity). Si se pulsa Avanzado, se pasa a 4 (AdvancedActivity). Si se selecciona el interrogante, se procede a ir a 2 (HelpActivity). Si se selecciona Home, se irá a 1 (DashboardActivity). Si se selecciona el +, se abre un diálogo: •Si se selecciona regla de tiempo, se va a 9 (ClockRuleActivity). •Si se selecciona regla de lugar, se va a 5 (LocationActivity). •Si se selecciona regla de batería, se pasa a 3 (BatteryActivity). •Si se selecciona regla de dispositivo, se procede a 7 (DevicesActivity). Si se pulsa el -, se eliminará la regla que anteriormente haya sido seleccionada. Si se pulsa Editar, se abrirá el diálogo de edición de la correspondiente regla. Si se pulsa la flecha, se oculta parte del panel teniendo que utilizar los menús contextuales y de opciones de Android. 50 Capítulo 5. Diseño 5.3. Diseño de la Interfaz Gráfica de Usuario. Si se pulsa ON/OFF se cambia la prioridad de las reglas de Bluetooth. Si se pulsa Bt, se conecta o desconecta el Bluetooth independientemente de las reglas. BluetoothPreferencesActivity : Se trata de la pantalla de opciones de la aplicación. Es la única que no dispone de ’ActionBar’, y sigue el diseño de las pantallas de opciones de Android. Figura 5.13: Diseño de la interfaz de BluetoothPreferencesActivity Si se selecciona Exportar/Importar, se seleccionará cuál de las dos opciones se realizará y se pasará a la Activity de Si se selecciona Refresco, saldrá un diálogo donde poner el tiempo de refresco. AboutDialog : Se trata del diálogo donde aparecerá toda la información de ’Acerca de’. 51 5.4. Gramática Capítulo 5. Diseño Figura 5.14: Diseño de la interfaz de AboutDialog Si se pulsa aceptar se vuelve a 1 (DashboardActivity). 5.4. Gramática Para la implementación de las reglas avanzadas, será necesario crear previamente una gramática válida. La podemos visualizar en la figura 5.15 start -> expr expr -> expr2 or expr3 | expr2 and expr3 | not expr3 | expr2 expr2 -> ID | ’(’ expr ’)’ expr3 -> expr and -> ’and’ | ’AND’ | ’&’ or -> ’or’ | ’OR’ | ’|’ not -> ’not’ | ’NOT’ | ’!’ Figura 5.15: Gramática del lenguaje de definición de reglas avanzadas 52 Capítulo 6 Implementación En el presente capítulo se pasa a explicar y detallar las partes más importantes y resaltables del software desarrollado, así como las soluciones que he adoptado durante la fase de desarrollo de la aplicación y los problemas surgidos durante la misma. 6.1. Implementación de las reglas Para implementar las reglas, se ha creado una interfaz ’Regla’ (Mirar Anexo I, Rule.java, página 60), de la cuál extenderán todas las demás reglas, teniendo que implementar el método ’checkRule’ (Mirar Anexo I, fichero Rule.java, línea 5) , el cuál será el encargado de comprobar que la regla crea que debe activar o desactivar el adaptador Bluetooth. Eso permitirá tratar a todas las reglas de igual forma independientemente de cómo estén desarrolladas. ... 4 public interface Rule { 5 public boolean checkRule ( ) throws Exception ; ... 9 } Figura 6.1: Fragmento de la interfaz Rule En primer lugar vamos a hablar de la regla de batería (Véase en el Anexo I, BatteryRule.java, en la página 60). La implementación es muy sencilla, ya que sólo tomamos como referencia el umbral de batería escogido por el usuario. Entonces, la regla se activaría sólo si el valor de batería está sobre el umbral o está conectado el dispositivo al cargador. 53 6.1. Implementación de las reglas Capítulo 6. Implementación ... 11 public classBatteryRule implements Rule { ... 34 public boolean checkRule ( ) throws Exception { ... 44 if (GeneralLogic.BATTERY_LEVEL > minLevel | | isCharging ){ 45 return true ; 46 } else { 47 return false ; 48 } ... Figura 6.2: Fragmento de la clase BatteryRule.java Para programar la regla de tiempo (En el Anexo I, correspondiente al fichero TimeRule.java, en la página 66), se comprueba que la fecha y hora actual esté dentro de los rangos establecidos, es decir, dentro del rango de fechas establecido, de horas y a su vez, que se encuentre en un día de la semana activo; se tiene en cuenta si el usuario ha decidido no especificar fechas u horas. Una vez comprobado esto, se mira si está activada la casilla del día de la semana en el que nos encontramos. Si todo eso es positivo, se activa el Bluetooth. Como parte destacable de la implementación, resalto el método checkRule (visible en el Anexo I, fichero TimeRule.java, línea 230). 54 Capítulo 6. Implementación 6.1. Implementación de las reglas ... 7 public class TimeRule implements Rule { ... 230 public boolean checkRule() throws Exception{ ... 238 if (nodate && !notime) { 239 if (enabled && compareHours(currentTime, startTime, endTime)) { 240 ret = true; 241 } else { 242 ret= false; 243 } 244 }else if(notime && !nodate){ 245 if (enabled && compareDates(currentTime, startDate, endDate)) { 246 ret = true; 247 } else { 248 ret = false; 249 } 250 }else if(!notime && !nodate){ 251 if (enabled && compareHours(currentTime, startTime, endTime) && compareDates(currentTime, startDate, endDate) ) { 252 ret = true; 253 } else { 254 ret= false; 255 } 256 } ... Figura 6.3: Fragmento de la clase TimeRule.java Para la regla de lugar (Anexo I , fichero PlaceRule.java en la página 63) hace falta detallar a mayor nivel, dada la complejidad alta con respecto a las otras reglas. Para poder geolocalizar al usuario, se utilizan los dos métodos posibles en Android: Mediante el GPS, más lento pero más preciso, y mediante red (Wifi o 3G) más rápido pero con mayor error. Para geolocalizar puntualmente el lugar que queramos, necesitaremos la geolocalización por GPS ya que el error de posición es menor, y se realiza dentro de la Activity AddLocationActivity.java (Anexo I, página 29), independizando a la regla de cómo se obtienen sus datos. 55 6.1. Implementación de las reglas Capítulo 6. Implementación ... 22 public class AddLocationActivity extends ActionBarActivity{ ... 32 public void onCreate(Bundle savedInstanceState) { ... /*Obtenemos el manejador*/ 42 manager = (LocationManager) getSystemService(Context.LOCATION_SERVICE); ... /*Miramos si está inicializado el de satélite*/ 45 if(manager.isProviderEnabled(LocationManager.GPS_PROVIDER)){ 46 locationProvider = LocationManager.GPS_PROVIDER; /*Si no, miramos si está inicializado el de red*/ 47 }else if(manager.isProviderEnabled( LocationManager.NETWORK_PROVIDER)){ 48 locationProvider = LocationManager.NETWORK_PROVIDER; 49 } 50 if(!locationProvider.equals("")){ 51 location = new myLocationListener(); /*Tiempo de actualización*/ 52 manager.requestLocationUpdates(locationProvider, 30000, 20, location); 53 }else{ /*Si no hay ninguna manera de geolocalizar, lo notificamos al usuario*/ 54 Toast t = Toast.makeText(getApplicationContext(), getResources(). getString(R.string.alert_map), Toast.LENGTH_LONG); 55 t.show(); 56 } ... Figura 6.4: Fragmento de AddLocationActivity.java, referenciando la geolocalización Sin embargo, en el caso de la geolocalización del servicio principal, primero intentaremos utilizar la geolocalización por red, dado que consume menos batería que el GPS, y si por algún motivo no estuviera disponible, se pasaría a geolocalizar usando satélite. Está implementado en la clase StandardActivity.java (Anexo I, página 7). 56 Capítulo 6. Implementación 6.5. Sección de ayuda. 1 <?xml version="1.0" encoding="utf-8"?> ... 19 <android.support.v4.view.ViewPager 20 android:id="@+id/vwpg_help" 21 android:layout_width="fill_parent" 22 android:layout_height="fill_parent" > 23 </android.support.v4.view.ViewPager> ... Figura 6.10: help.xml, con la vista ViewPager El segundo problema, y más laborioso de solucionar, es el hecho de diseñar e implementar la interfaz del ViewPager. El principal problema que tenemos es que el ViewPager no está integrado con el diseñador de interfaces gráficas del entorno de desarrollo, y es necesario definir a código java todo aquello que queramos que esté incluido dentro del componente. Un ejemplo de ello lo podemos ver en la figura 6.11, la cuál es un extracto de la clase HelpActivity.java (Anexo I, página 53). 63 6.5. Sección de ayuda. Capítulo 6. Implementación ... 20 public class HelpActivity extends ActionBarActivity { ... 107 /* 108 * Creamos el layout1 109 */ 110 LinearLayout layout = new LinearLayout(this); 111 LinearLayout scrollChild = new LinearLayout(this); ... 120 /*Creamos una vista de scroll, para adaptarlo a pantallas pequeñas*/ 121 ScrollView scroll1 = new ScrollView(this); /*Creamos el texto a mostrar*/ 122 TextView explanation1 = new TextView(this); 123 explanation1.setTextSize(TypedValue.COMPLEX_UNIT_DIP, 17); 124 explanation1.setText(Html.fromHtml( 125 "<b>"+getResources().getString( R.string.header_explanation1)+"</b><br>")); ... 138 layout.addView(explanation1); 139 scrollChild.addView(textOne); ... 142 scroll1.addView(scrollChild); 143 layout.addView(scroll1); 144 layouts.add(layout); ... Figura 6.11: Fragmento de HelpActivity.java 64 Capítulo 7 Ejemplos de funcionamiento A continuación, mostraremos ejemplos de funcionamiento de nuestra aplicación, mostrando su correcto funcionamiento y la interfaz definitiva. Probaremos a añadir una regla de tiempo, y guardarla: Figura 7.1: Añadir regla de tiempo Pasamos a realizar lo mismo con una regla de lugar: 65 Capítulo 7. Ejemplos de funcionamiento Cuadro 7.1: Añadir regla de lugar Ahora, añadimos una regla de batería: Figura 7.2: Añadir regla de batería Tras añadir las tres reglas, se comprueba que en prioridad a apagado, el Bluetooth está activo hasta pasada la hora establecida. Una vez hecho esto, se cambia a prioridad de encendido, y se observa que el adaptador Bluetooth vuelve a activarse. Ahora, desactivaremos todas las reglas, y haremos una regla avanzada relacionándolas: 66 Capítulo 7. Ejemplos de funcionamiento Figura 7.3: Añadir regla avanzada El comportamiento es el esperado, ya que la batería es superior al umbral, y además, estamos en el lugar seleccionado. Ahora vamos a proceder a comprobar el funcionamiento del explorador de archivos, así como de la importación y exportación de las reglas. Para ello, primero exportamos a un archivo en formato zip, para borrar todas nuestras reglas, y después importarlo de nuevo. Observamos que, efectivamente, las reglas se han restaurado. Figura 7.4: Exportación e importación de reglas Para terminar la comprobación del funcionamiento de las partes del programa más importantes, pasamos simplemente a mostrar la ayuda de la aplicación en el orden en el cuál se muestra al usuario. 67 Capítulo 7. Ejemplos de funcionamiento Figura 7.5: Ayuda de la aplicación 68 Capítulo 8 Conclusiones Para finalizar, podemos observar que hemos conseguido realizar una aplicación de gestión de Bluetooth basada en reglas. El usuario, puede ser capaz de transmitir la manera en la que la aplicación mediante reglas simples o complejas, las cuáles se evalúan en conjunto propiciando una activación o desactivación del adaptador Bluetooth del dispositivo Android. Las reglas básicas que se han conseguido implementar correctamente han sido: Regla de tiempo: Es capaz de comprobar los intervalos de tiempo definidos por el usuario, tanto de fechas como de horas. Regla de proximidad : Consigue añadir ubicaciones propias, así como detectar la proximidad a estas. Regla de batería: Detecta el umbral de batería , y si el dispositivo se encuentra conectado a la corriente y cargando. Por otra parte la regla de dispositivos conocidos no pudo ser desarrollada, ya que los permisos necesarios para ello eran propios del superusuario. En las reglas avanzadas, se ha conseguido crear un lenguaje de definición de reglas basado en conexiones lógicas entre los resultados de éstas. Para ello, he aprendido a utilizar la herramienta ANTLRWorks, entorno de desarrollo para ANTLR. Si la regla no está escrita según el lenguaje de definición de reglas, se detecta que existe un error y no es activada. También se ha implementado un sistema de prioridades, en el cuál el usuario puede elegir si ante un conflicto de reglas, se da prioridad al encendido o al apagado. Por lo que respecta a la IGU, se ha conseguido una interfaz limpia, la cuál aprovecha las opciones que ofrece Android (Menús contextuales y 69 Capítulo 8. Conclusiones de opciones) ofreciendo además un panel donde puede realizase igualmente cualquier acción (Favoreciendo a los usuarios con poco conocimiento del propio sistema operativo). También se ha incluido un apartado de ayuda en forma de páginas, para que el usuario pueda consultar cualquier duda acerca del software. Uno de los puntos fuertes de la aplicación puede ser el diseño, el cuál se ha alejado de un aspecto ’por defecto’ de las aplicaciones Android, tanto utilizando material propio como iconos de libre utilización. Para el almacenamiento de las reglas, se ha conseguido crear un formato diferente para cada una utilizando XML, y también se ha conseguido exportarlas e importarlas a un archivo externo como copia de seguridad. Debido a motivos de tiempo, hay objetivos que se han quedado total o parcialmente fuera del alcance del presente proyecto. Estos objetivos son: Un estudio más a fondo del ahorro de batería conseguido por la aplicación. Realización de casos de test y pruebas en la aplicación, utilizando herramientas como JUnit o similares. También podría haber sido interesante, haber ampliado los objetivos: Un sistema de prioridades de regla más avanzado. Almacenamiento de las reglas en un servidor (“en la nube”). 70 Capítulo 9 Definiciones 1. Action Bar: Patrón de diseño para aplicaciones Android basado en la utilización de una barra superior común a toda la aplicación, dentro de la cual hay elementos de navegación como botones, iconos... etcétera. 2. Google Play: Aplicación presente en los dispositivos Android (Anteriormente llamada Android Market) en la cuál es posible descargar, gratuitamente o bajo pago, aplicaciones desarrolladas por Google, otras empresas, o desarrolladores independientes. A partir de su cambio a Google Play, además de aplicaciones, también pueden encontrarse libros y películas, y es posible que en el futuro puedan añadirse nuevos productos. 3. Piconet: Según [Wikipedia2012b], una piconet es una red de dispositivos informáticos conectados mediante la tecnología Bluetooth. Una piconet puede constar de dos hasta ocho dispositivos, en los que uno será el maestro y el resto esclavos. 4. Middleware: Según [Rfidpoint2012], el middleware es un software de conectividad que ofrece un conjunto de servicios que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas. 5. Dashboard : Patrón de diseño para Android que se basa en una actividad principal de la aplicación con botones/iconos de acceso a las partes más importantes de la misma. 71 Bibliografía [Condesa2011] Condesa. Arquitectura de Android. (Julio 2011). Disponible en: http://androideity.com/2011/07/04/arquitecturade-android/ [ADevelopers2012] Android Developers. Activities. (Julio 2012). Disponible en: http://developer.android.com/guide/components/activities.html [ADevelopers2012a] Android Developers. Android, the world’s most popular mobile platform. (Julio 2012). Disponible en: http://developer.android.com/about/index.html [Wikipedia2012] Wikipedia. Bluetooth. (Junio 2012). Disponible en: http://developer.android.com/about/index.html [Wikipedia2012a] Wikipedia. Bluetooth profiles. (Julio 2012). Disponible en : http://en.wikipedia.org/wiki/Bluetooth_profile [Wireless2000] Wireless. Bluetooth Range in Relation to Different Power Classes. (Marzo 2000). Disponible en: http://www.palowireless.com/infotooth/knowbase/general/10.asp [ADevelopers2012b] Android Developers. Application Fundamentals. (Julio 2012). Disponible en : http://developer.android.com/guide/components/fundamentals.html [Android-er2010] Android.er. Implement a simple File Explorer in Android . (Enero 2010). Disponible en: http://androider.blogspot.com.es/2010/01/implement-simple-fileexplorer-in.html [Wikipedia2012b] Wikipedia. Piconet. (Marzo 2011). Disponible en: http://es.wikipedia.org/wiki/Piconet 72