UNIVERSIDAD REY JUAN CARLOS

Transcripción

1 UNIVERSIDAD REY JUAN CARLOS MÁSTER UNIVERSITARIO EN SISTEMAS TELEMÁTICOS E INFORMÁTICOS Curso Académico 2009/2010 Trabajo Fin de Máster QuiteSleep, un proyecto FLOSS en Android Autor : César Valiente Gordo Tutor : Jesús M. González-Barahona

2 (cc) 2010 César Valiente Gordo. Some rights reserved. This document is distributed under the Creative Commons Attribution-ShareAlike 3.0 licence, available in

3 A mi tutor, Jesús M. González-Barahona, por el apoyo brindado y las ideas transmitidas durante el desarrollo de este proyecto. A todos los compañeros de Master que me han acompañado. A mis amigos; por ser como son. A Pablo, por estar siempre ahí y ser mi compañero de aventuras y desventuras. Y como no, a mi familia; sin ellos no soy nada.

4 Índice 1. Resumen 6 2. Introducción Situación histórica Motivación Precedentes Elementos funcionales Aspectos técnicos Java Android Origen Características Arquitectura Elementos principales en la programación con Android db4o Origen Licencias Por qué db4o? Java Mail API Características Licencias Por qué Java Mail? Antecedentes y objetivos Aplicaciones similares Objetivos Descripción informática Metodología a seguir Fases del Proyecto

5 Fase 0: Toma de contacto Fase 1: Acceso a datos Fase 2: Gestión de contactos Fase 3: Gestión de horarios Fase 4: Gestión de servicios Fase 5: Actualización de gestión de contactos Fase 6: Gestión de llamadas Fase 7: Creación del historial Fase 8: Ajustes finales Detalles de la implementación es.cesar.quitesleep.activities es.cesar.quitesleep.callservices es.cesar.quitesleep.ddbb y es.cesar.quitesleep.interfaces es.cesar.quitesleep.dialogs es.cesar.quitesleep.listeners es.cesar.quitesleep.mailmessages es.cesar.quitesleep.menus es.cesar.quitesleep.notifications es.cesar.quitesleep.operations es.cesar.quitesleep.receivers es.cesar.quitesleep.smsmessages es.cesar.quitesleep.staticvalues es.cesar.quitesleep.subactivities es.cesar.quitesleep.syncdata es.cesar.quitesleep.utils Proyecto FLOSS Fase1: Licencia Fase 2: Proyecto en una forja de software libre Fase 3: Publicación en el Android Market Fase 4: Publicidad de QuiteSleep

6 6.5. Fase 5: Logros y actividades Fase 6: Actualizaciones post-release Fase 7: Estadísticas Conclusiones Futuras ampliaciones Implementaciones derivadas Apéndice: Manual de usuario Contactos Horario Configuración Historial Acerca de y Ayuda Bibliografía 108 5

7 1. Resumen QuiteSleep 1 es un proyecto FLOSS 2 para teléfonos móviles que utilicen el sistema operativo Android [1], en el que trata de ocupar un hueco que actualmente se encuentra libre en las aplicaciones para este sistema. La función de QuiteSleep es la de silenciar de forma automática llamadas de contactos a los que previamente se haya establecido como bloqueados en una franja de tiempo, tanto horaria como diaria, una vez la llamada ha terminado, QuiteSleep dejará el teléfono en modo normal, tanto volumen como vibración. QuiteSleep además, ofrece funcionalidad añadida como la de enviar mensajes de aviso indicando que se está durmiendo (u ocupado), tanto vía SMS 3 como vía 4. Es decir, y para tener una visión global de un caso de uso en QuiteSleep, un usuario, seleccionaría 1 o n contactos a bloquear, a continuación pasaría a configurar la hora de inicio y hora de fin en la que el programa realizará las acciones, también definiría que días de la semana entrará en funcionamiento, y por último activaría el servicio correspondiente, donde QuiteSleep entrará a funcionar cuando un contacto, al que hemos establecido como bloqueado, realiza una llamada en una hora dentro de la franja horaria y diaria establecida. Una vez esto ocurra, la llamada correspondiente será silenciada, con lo que no se nos molestará con el sonido del móvil y la vibración, y una vez el contacto (o nosotros) colguemos la llamada,la aplicación volverá a dejar el teléfono en modo normal para atender a otras posibles llamadas. Si el usuario quiere, puede hacer uso también de las funciones de envío de mensajes (sms y/o ) para avisar al contacto que no le puede atender. La forma más fácil de explicar la motivación de QuiteSleep es pensar en lo siguiente, por la noche, si te llaman un lunes tus amigos, muy probablemente estarán gastándote alguna broma, estén de fiesta, etc. pero si esa misma noche te llaman tus padres, hermanos, pareja, a las 2 00 de la mañana, con casi toda seguridad algo grave habrá ocurrido. QuiteSleep se preocupa 1 En español vendría ser como dormir bastante 2 Free/Libre Open Source Software 3 Short Message Service 4 electronic mail 6

8 exactamente de eso, quien puede molestarte en tus horas de sueño, y quien no. En la Figura 1 se puede apreciar el funcionamiento de QuiteSleep. Figura 1: Diagrama del funcionamiento de QuiteSleep. QuiteSleep, como se ha comentado anteriormente, es un proyecto de software libre, que respeta las cuatro máximas, postuladas por la FSF 5 [2], como son libertad de uso, libertad de copia, libertad de modificación y libertad de distribución. Así, QuiteSleep no es una aplicación más de un desarrollador, si no que trata ser un proyecto de software colaborativo, para mejorarlo, cambiarlo, adaptarlo a nuevas necesidades, etc. 5 Free Software Foundation 7

9 2. Introducción QuiteSleep está incluida en un contexto muy actual como es el de las aplicaciones móviles, sector que en los últimos años ha tenido un avance muy grande tanto en creación de sistemas novedosos, como en la difusión de los mismos Situación histórica Con la salida al mercado del sistema operativo Android en 2008, un mundo de posibilidades se abrió para para el mercado de dispositivos móviles ya que se trataba de un sistema operativo open source, y en el que las aplicaciones se desarrollaban en el lenguaje de programación Java, con lo que situaba como clara competencia ante el sistema operativo Symbian [3] de Nokia [4] en el cual la programación era mucho más complicada al utilizar el lenguaje C++, Windows Mobile [5] de Microsoft [6], para el cual se programaba utilizando su plataforma de desarrollo Visual Studio.Net [7], que aunque permitía el desarrollo en cualquiera de los lenguajes soportados por este entorno de desarrollo como C++, C#, o VB, no dejaba de tratarse de una plataforma privativa, para un sistema operativo completamente privativo. Finalmente hace frente al más valorado y utilizado por los desarrolladores y compradores y verdadero hit de ventas como es el sistema operativo de Apple [8] para su iphone [9] llamado iphone OS [10] para el cual se desarrolla en un lenguaje parecido a C++ que se llama Objective-C. No solo la facilidad de desarrollo es lo que brinda Android, sino que al ser un sistema operativo libre, los fabricantes de dispositivos móviles como son HTC, Motorola, Samsung, etc. pueden hacer uso de este sistema operativo sin realizar ningún pago de licencia, cosa que con el anteriormente mencionado Windows Mobile no pasa (iphone y Symbian son propietarios de sus respectivas marcas y solo están disponibles para móviles de la misma marca), ya que como decimos este sistema operativo es privativo. Tal es la aceptación que este sistema operativo ha tenido, que Symbian está pasando a ser liberado en estos momentos bajo licencia EPL 6 y creándose una fundación (Symbian Foundation) para mantener este proyecto software y ser mucho mejor acogido por la comunidad open source que si lo siguiera manteniendo Nokia. Tras estos movimientos y lo obsoleto que se estaba quedando Windows Mobile, Microsoft, 6 Eclipse Public License 8

10 para no quedarse atrás en la guerra de móviles está implementando el llamado Windows Phone que es la evolución del anterior. Esto es a grandes rasgos lo que ha ocurrido en apenas un par de años, la revolución Android está aquí y productos como GoogleTV [11] anunciado en Mayo de 2010, y que está basado en este sistema operativo no hacen más que confirmarlo. Antes incluso del lanzamiento oficial del primer teléfono con el sistema operativo Android (llamado HTC G1, HTC Dream, o Dev Phone), la comunidad de desarrolladores se volcó con Android y a su salida y sucesivamente más con el tiempo, el Android Market se ha llenado de aplicaciones desarrolladas por empresas, desarrolladores en solitario, grupos de ellos, etc. aplicaciones libres, privativas, juegos, widgets, etc. y aquí es donde entra en juego nuestra aplicación, QuiteSleep Motivación La motivación de la creación de QuiteSleep viene dada por la necesidad de tener un filtro de llamadas en teléfonos móviles con sistema operativo Android, sin hacer uso del voic 7 de serie ni de silenciar o colgar las llamadas de forma manual por el usuario. Como se verá posteriormente, hay aplicaciones que realizan acciones similares pero no iguales, QuiteSleep trata de realizar las acciones mencionadas anteriormente de forma fácil y eficaz para el usuario. El por qué de la publicación de QuiteSleep como proyecto FLOSS viene por afinidad al movimiento de software libre en el que compartir y difundir el conocimiento es una máxima Precedentes Android es un sistema de reciente creación, pero en este tiempo, apenas un par de años, se han desarrollado miles de aplicaciones de miles de desarrolladores, tanto empresas, como desarrolladores individuales, colectivos, agrupaciones, administraciones públicas, etc. QuiteSleep no es la única que se ha introducido en el sector de aplicaciones que tratan de automatizar procesos cuando ocurren determinados eventos, pero si es única en cuanto a la funcionalidad concreta que ofrece. 7 Función que manda la llamada entrante al buzón de voz 9

11 Como veremos en la sección 4.1, hay una serie de proyectos ya bien posicionados en las aplicaciones para el sistema operativo Android, que ofrecen características similares, pero siendo cada una diferente en varios aspectos, lo que hace de cada aplicación única en cuanto a funcionalidad, utilidad, accesibilidad, etc. Las aplicaciones son: CallFillter [12] Sweet Dreams [13] Locale [14] Como decimos más adelante se pasará a detallar en que se basa cada una, que ofrece, y en que se parecen o son distintas a QuiteSleep Elementos funcionales QuiteSleep está implementado haciendo uso del lenguaje de programación Java y tres proyectos software como son: El ya mencionado, sistema operativo Android, para el que está desarrollado (para versiones iguales o mayores a la 2.0) La base de datos orientada a objetos db4o [15] La librería open source Java Mail API [16] de Sun Microsystems (recientemente comprada por Oracle[17]). Estos elementos son totalmente independientes entre si, tienen funcionalidades diferentes, y pueden ser utilizados conjúntamente o no. Hemos hecho uso de estos tres proyectos software basándonos en: La elección de un sistema operativo en el que desarrollar la aplicación. La elección de un modo de persistencia de datos. La elección de una vía para transferencia de datos, en este caso correo electrónico, para hacer frente a nuestros objetivos y requisitos. 10

12 En la sección 3 veremos en profundidad cada uno de estos componentes que hacen posible el desarrollo de la aplicación QuiteSleep. 11

13 3. Aspectos técnicos En esta sección vamos a detallar tanto el lenguaje de programación en la que está implementada la aplicación, como los elementos funcionales utilizados en la misma, y que fueron mencionados anteriormente en la sección Java El lenguaje de programación utilizado en el desarrollo ha sido Java, ya que es el lenguaje de programación, impuesto por la plataforma Android para el desarrollo de aplicaciones. Como bien es sabido, Java es un lenguaje de programación orientado a objetos creado por Sun Microsystems a principios de los años 90, Es un lenguaje muy parecido en sintaxis a C y C++, pero más sencillo que estos ya que omite el manejo de punteros y accesos a memoria que en los lenguajes anteriores suelen ser inductores de la mayoría de errores. Java es un lenguaje puramente orientado a la multiplataforma, es decir, su propósito nació con que una aplicación creada sobre un lenguaje operativo, que no tuviera llamadas al mismo, fuera capaz de funcionar para cualquier plataforma distinta sobre la que se había desarrollado. Esto se consigue gracias a que Java es compilado en bytecode que es un código intermedio más abstracto que el código máquina y el cuál es interpretado en una máquina virtual java (jvm 8 ), este hecho es el que hace a Java multiplataforma, ya que existen máquinas virtuales para casi cualquier sistema operativo, con lo que el código generado en bytecode puede ser ejecutado en cualquier jvm. Como decimos Java es un lenguaje orientado a objetos (OO), con lo que posee todas las cualidades propias de los lenguajes que utilizan este paradigma de programación, como son: Abstracción. Encapsulamiento. Herencia. Polimorfismo. 8 Java Virtual Machine 12

14 Java además dispone de un recolector de basura 9 propio, con el que evitamos tener que liberar memoria explicitamente cada vez que no necesitamos ya un objeto o estructura de datos, como por ejemplo hacemos en C o C++; el recolector de basura se encarga de ello Android Este proyecto ha sido concebido para uso en el sistema operativo Android. Android es un sistema operativo orientado a dispositivos móviles que usa una versión modificada del kernel 10 de Linux [18]. Esta plataforma permite el desarrollo de aplicaciones a través del SDK 11 que ofrece, y mediante el uso del lenguaje de programación Java, también es posible realizar aplicaciones más optimizadas utilizando el NDK 12 para desarrollo en lenguaje C Origen Android fue originalmente desarrollado por Android Inc. compañía que fue comprada por Google [19] en 2005, la presentación de la plataforma Android se realizó el 5 de Noviembre de 2007 junto con la fundación de la Open Headset Alliance [20], que es una agrupación de compañías para desarrollar estándares abiertos para dispositivos móviles, liderada por Google, algunos de los miembros son, HTC [21], Motorola [22], Qualcomm [23] y hasta 65 miembros en total. Android actualmente es desarrollado por esta agrupación de empresas. Android está publicado como open source [24] bajo licencia Apache [25] desde el 21 de Octubre de 2008, incluyendo la pila de red y de telefonía. Con la utilización de esta licencia, se permite la creación de aplicaciones privativas sin necesidad de difundir el código fuente ni hacer uso de la licencia Apache, para difundirlas. Desde la primera versión publicada, se han sucedido las siguientes actualizaciones del sistema, que siguen tanto nomenclatura numérica como nomenclatura en forma de nombres de pasteles, por ejemplo Cupcake es una pequeña tarta del tamaño de un magdalena, Donut es un 9 garbage collector 10 Es el responsable de facilitar a los distintos programas el acceso seguro al hardware del ordenador (o máquina) o en forma más básica, el encargado de gestionar recursos a través de llamadas al sistema 11 Software Development Kit, es un conjunto de herramientas de desarrollo que permite a un programador desarrollar aplicaciones para un sistema concreto 12 Native Development Kit, set de herramientas proporcionadas para desarrollo de aplicaciones que necesiten utilizar y acceder de forma mucho más eficiente a los recursos del sistema 13

15 donut, etc. Las diferentes versiones son: 1.0 Versión del SDK lanzado en Octubre de No se define con un nombre. Lanzado junto con el primer teléfono con Android llamado HTC G1 o Dream. 1.1 Versión del SDK lanzado en Febrero de Solucionaba varios errores menores, no aportaba nuevas funcionalidades importantes. 1.5 Cupcake Versión del SDK lanzado el 30 de Abril de Basado en el kernel de Linux Donut Versión del SDK lanzado el 15 de Septiembre de Basado en el kernel de Linux /2.1 Eclair Versión del SDK lanzado el 26 de Octubre de Basado en el kernel de Linux Froyo Versión del SDK lanzado el 20 de Mayo de Basado en el kernel de Linux Gingerbread Próxima versión. Estará basada en el kernel de Linux o Características El sistema operativo Android tiene una serie de características comunes a las de otros sistemas operativos y otras propias orientadas a los dispositivos móviles para los que está creado. Android dispone de un framework 13 para la creación de aplicaciones utilizando los recursos que provee. 13 Estructura conceptual y tecnológica de soporte definida normalmente en basados en módulos software concretos, con base en la cual otro proyecto software puede ser organizado y desarrollado 14

16 Máquina virtual Dalvik 14 optimizada para dispositivos móviles. Navegador web integrado, basado en WebKit 15. Gráficos optimizados en 2D, los gráficos en 3D se basan en la especificación OpenGL ES (aceleración por hardware opcional). Utiliza la base de datos relacional y ligera SQLite[26] para almacenamiento y utilización de datos estructurados. Soporte de los formatos de audio, vídeo e imágenes más comunes y utilizados como son H.263, H.264 (en contenedores 3GP o MP4), MPEG4 SP, AMR, AMR-WB (en contenedor 3GP), AAC, HE-AAC (en contenedores MP4 o 3GP), MP3, MIDI, OGG, WAV; JPEG, PNG, GIF, y BMP. Telefonía GSM 17 (dependiente del hardware). Soporta EDGE 18, 3G y WiFi (dependiente del hardware). Bluetooth con soporte para A2DP 19 y AVRCP 20. Soporta cámara, GPS 21, brújula, acelerómetro, pantallas táctiles con multitouch de diferentes tamaños y densidades (dependiente del hardware). Android Market[27], aplicación accesible desde los dispositivos móviles donde los usuarios pueden descargar tanto de forma gratuita como de pago aplicaciones realizadas por 14 Máquina virtual desarrollada por Dan Bornstein con contribuciones de otros ingenieros de Google 15 Basado originalmente en el motor de renderizado KHTML del navegador web del proyecto Kde, Konqueror, es un framework open source, para aplicaciones que funciona como base para los navegadores Safari, Google Chrome, Epiphany, Midori y otros 16 Open Graphics Library, es una especificación estándar que define una API multilenguaje y multiplataforma escribir aplicaciones que produzcan gráficos en 2D y 3D 17 Sistema Global para Comunicaciones Móviles, es un sistema estándar, completamente definido para la comunicación mediante teléfonos móviles que incorporan tecnología digital 18 Enhaced Data rates for GSM of Evolution, es una tecnología móvil, que actúa como puente entre las redes 2G y 3G, se considera la evolución del GPRS 19 A2DP define la calidad de la música transmitida a través de Bluetooth y que puede ser mono o estero 20 AVRCP provee un interfaz para la manipulación de equipos de imagen y sonido 21 Sistema de posicionamiento global, es un sistema de navegación por satélite que permite determinar en todo el mundo la posición de un objeto, persona, o vehículo con una precisión de hasta centímetros 15

17 los desarrolladores. Tiene un panel web accesible también desde navegadores web de ordenadores personales convencionales, donde los desarrolladores pueden poner sus aplicaciones tanto para descarga gratuita como de pago. Multitarea la capacidad de correr diferentes aplicaciones y procesos al mismo tiempo Arquitectura Android tiene una serie de componentes principales que forman el esqueleto del sistema operativo, los cuales son los siguientes: Aplicaciones. Las aplicaciones base que vienen con el sistema operativo son el cliente de , cliente de mensajería (sms/mms), calendario, mapas, navegador web, contactos, y otras. Todas las aplicaciones están desarrolladas en Java, y algunas de ellas son software privativo, con lo que no se tiene acceso a ellas cuando se obtiene el código fuente del proyecto Android, como son las aplicaciones de (Gmail), y mapas (Google maps). Framework de aplicaciones Los desarrolladores tienen acceso de forma totalmente completa a las mismas APIs del framework de Android utilizado por las aplicaciones base, con lo que la diferencia entre estas y las de terceros son mínimas en cuanto a la posibilidad de utilizar los recursos del sistema. Esta arquitectura está diseñada para simplificar la reutilización de componentes, cualquier aplicación puede publicar sus capacidades y cualquier otra aplicación puede acceder a esas capacidades publicadas, estando todo sujeto a diversas políticas de seguridad. Así como decimos, las aplicaciones de terceros pueden sustituir a las aplicaciones base del sistema como son las de mensajería, llamadas, etc. Bibliotecas Android provee una serie de bibliotecas en C/C++, usadas por varios componentes del sistema. Estas bibliotecas se ofrecen a los desarrolladores a través del framework de aplicaciones, como son bibliotecas de medios, bibliotecas de gráficos, bibliotecas de bases de datos (SQLite), implementación de la biblioteca C estándar, etc. Runtime de Android Android provee un set completo de bibliotecas que proporciona la mayoría de las funciones disponibles en la biblioteca estándar de Java. En Android, cada aplicación Java, tanto aplicaciones base como de terceros (ya que para el sistema son 16

18 iguales) corre su propio proceso, con su propia instancia de la máquina virtual Dalvik. Esta máquina virtual que como dijimos anteriormente fue creada ad-hoc por Google para Android, está diseñada de forma que un dispositivo puede correr múltiples máquinas virtuales de forma eficiente. Dalvik ejecuta archivos en el formato Dalvik Executable (.dex), el cual está optimizado para hacer uso de la menor memoria posible. La máquina virtual está basada en registros, y corre clases compiladas por el compilador de Java que han sido transformadas al formato.dex por la herramienta incluida en el SDK dx. Kernel de Linux Como todo sistema operativo Android posee un núcleo o kernel, el cuál como hemos dicho antes, se trata de Linux, y que se encarga de los servicios base del sistema, gestión de memoria, gestión de procesos, pila de la red, y modelo de controladores, es decir el kernel actúa como una capa de abstracción entre el hardware y el software. A a lo largo de las sucesivas versiones del sistema, se han ido sustituyendo los kernels por versiones más modernos de los mismos, como en el sistema operativo GNU/Linux. Figura 2: Diagrama del modelo de la arquitectura Android 17

19 Como podemos ver en la Figura 2, la arquitectura Android queda dispuesta en 4 niveles, en los que cada uno abstrae a su superior del nivel inferior, es decir, la capa de aplicaciones utiliza el framework de aplicaciones pero este actúa de abstracción para el nivel librerías con respecto al de aplicaciones. Como vemos y desde nivel superior al inferior: Aplicaciones. Aquí se encuentran tanto las aplicaciones base que vienen con el sistema, como la gestión de contactos, mapas, gps, correo electrónico, etc. con las que los desarrolladores externos (terceros) desarrollan para el sistema, como vemos no hay diferencias entre ellas, todas pueden hacer uso de los mismos recursos. Framework de aplicaciones. Aquí se proveen recursos para las aplicaciones en forma de acceso a los contactos, administración de ventanas, proveedor de contenidos, etc. Librerías y Android Rutime. Aquí se ofrecen las librerías del sistema que serán accesibles a las aplicaciones por medio del uso del framework de aplicaciones (nivel superior). La máquina virtual, Dalvik, también está en este nivel. Kernel de Linux. Por último se encuentra el Kernel de Linux el cual es el encargado de ofrecer una capa de abstracción entre el software y el hardware además de todas las funciones anteriormente mencionadas, como el controlador de pantalla, controladores de la cámara, gestión de energía, etc Elementos principales en la programación con Android Antes hemos hablado de lo que es Android como proyecto y como sistema operativo, lo que se puede hacer con el, etc. ahora vamos a ver los elementos principales que se utilizan en la programación para este sistema operativo, no se tienen por que usar todos, ni incluso ninguno, pero son los pilares en los que se fundamenta la programación en este entorno. Adelantar que en QuiteSleep hemos utilizado absolutamente todos estos elementos para las diferentes acciones que realiza la aplicación, con lo que el aprovechamiento y aprendizaje de Android es muy alto. Indicar que estos elementos son explicados de forma completa en los libros utilizados para el desarrollo de este programa como son The Busy Coder s Guide to Android Development [28] y Professional Android 2 Application Development [29]. Así, estos son los elementos principales de la arquitectura Android para el desarrollo de aplicaciones: 18

20 Activities La parte principal de la interfaz de usuario en Android, son las llamadas Activities [30], una activity es como si fuera una ventana o un frame en una aplicación normal de escritorio de un ordenador convencional. Por así decirlo las activities son las pantallas que aparecen en cualquier aplicación Android, cuando pasamos de una pantalla a otra, lo que estamos haciendo es pasar de una activity a otra. Figura 3: Ejemplo de dos Activities diferentes Content Providers Los Content Providers 22 [31], proveen un nivel de abstracción para cualquier tipo de dato almacenado en el dispositivo que es accesible por múltiples aplicaciones. Los datos internos del teléfono son accesibles para cualquier aplicación haciendo uso de este mecanismo. El modelo de desarrollo de Android, fomenta el poder poner los datos de cada aplicación de cada desarrollador accesible para el resto de las aplicaciones, esto se realiza construyendo tu propio content provider. Intents Los intents [32] son mensajes del sistema que son lanzados dentro del dispositivo, notificando a las aplicaciones de varios eventos, como cambios en el estado del hardware (por 22 Proveedores de contenido 19

21 ejemplo cuando una SD card es insertada), datos que son recibidos (por ejemplo cuando llega un SMS), eventos de las aplicaciones (por ejemplo tu aplicación es lanzada desde el menú principal), etc. No solo se puede responder a los intents, sino que los desarrolladores pueden crear sus propios intents para lanzar otras actividades (muy utilizado) o para saber cuando se dan situaciones específicas. Services Las activities, content providers e intents tiene un ciclo corto de vida y pueden ser terminadas en cualquier momento, incluso sin previo aviso. Los services [33] están diseñados para mantenerse en funcionamiento en background, si es necesario, independientemente de la activity que lo pueda lanzar. Se pueden utilizar services para checkear actualizaciones del correo electrónico en background, o escuchar música mientras se está realizando otra acción, etc. 20

22 3.3. db4o Aunque este proyecto utiliza la base de datos propia de Android, como es SQLite, principalmente utiliza esta base de datos en la mayoría de gestiones de acceso a datos. db4o es un motor de base de datos open source orientado a objetos, sus siglas corresponden a DataBase 4(for) Objects. Está desarrollado para trabajar con desarrollos en Java y en.net. Db4o está escrito en Java y.net, y provee las respectivas Apis para estos lenguajes de programación. Db4o funciona en cualquier sistema operativo que soporte estos lenguajes y es ofrecido en múltiples licencias, como son GNU GPL [34], the db4o Opensource Compatibility License(dOCL) [35] y una licencia comercial [36] para uso en software propietario [37] Origen El término Base de datos orientada a objetos data sobre 1985, aunque las primeras aproximaciones en esta área son de mediados de Los primeros sistemas gestores de bases de datos orientados a objetos se lanzaron comercialmente a principios de 1990, donde fue añadido el concepto de persistencia en los lenguajes orientados a objetos. Una segunda oleada te este tipo de bases de datos sucedió a principios de 2000, cuando las bases de datos orientadas a objetos escritas completamente en lenguajes que también eran orientados a objetos aparecieron en el mercado. Db4o es uno de estos ejemplos, escrita enteramente en Java y C# orientadas a las las mismas plataformas. El proyecto db4o fue iniciado en el 2000, por Carl Rosenberg y su primera versión fue lanzada en En 2004 junto al lanzamiento comercial de db4o se crea Db4objects Inc. destinada a labores comerciales y de promoción de esta base de datos, así como a la gestión de su comunidad de usuarios, que desde 2001 no ha hecho más que crecer. En 2008, Db4objects Inc, vende su producto estrella, la base de datos orientada a objetos, db4o a Versant Corp.[38] empresa que ya contaba con otra base de datos orientada a objetos como era Versant Object Database para Java y Versant Fast Objects para.net. Por su parte Db4objects Inc. cambia su nombre a Servo, y pasa a dejar de lado el negocio de bases de datos, centrándose en la venta de soluciones para gestión de datos de usuarios a proveedores de 21

23 comunicación inalámbrica. El CTO de Db4objects Inc. y responsable de la linea db4o Carl Rosenberg pasa a trabajar también para Versant Corp. donde sigue estando a cargo de este producto. Con la compra de db4o por parte de Versant Corp. se piensa y espera que se pueda expandir su comunidad, que actualmente data de unos usuarios en más de 190 países Licencias db4o hace uso de múltiple licenciamiento, orientado sobre todo a dar la máxima flexibilidad a los desarrolladores y empresas que desean utilizar db4o como base de datos para sus productos software, permitiendo tanto licenciamiento como software libre como licenciamiento para software privativo. Licenciamiento como software propietario Orientada al desarrollador o empresa que use db4o en su aplicación, y que quiera distribuir su trabajo sin ser software libre, es decir quiera distribuir su software como software privativo. También esta licencia es orientada para aquellos que no quieren hacer uso de la licencia GNU GPL (descrita a continuación) como licencia para su obra que utiliza la base de datos orientada a objetos, db4o. GNU GPL v3 db4o hace uso de la licencia general GNU GPL v3, para uso en aplicaciones que quieran hacer uso de esta licencia y/o para uso en aplicaciones que necesiten usar esta base de datos, pero no quieran hacer frente a un desembolso económico por su licencia. Originalmente db4o hacía uso de la licencia GNU GPLv2, pero pasaron a esta nueva versión recientemente. Versant Corp. en su interpretación de la GNU GPL hace mención a que el licenciamiento mediante el uso de esta licencia viene siendo como cualquier otro software publicado con esta ella, y además, comenta una serie de situaciones en las cuales el software estará basado (derivado de) en db4o (situaciones incluyentes pero no limitadas solo a estas): Si compilas el software contra software de db4o. Si tu software contiene referencias específicas al software de db4o. 22

24 Si tu software requiere del uso del software de db4o; o Si tu software usa una api propietaria contra el software de db4o. En todas estas situaciones, el desarrollador o compañía deberá hacer público el código fuente en correspondencia y aceptación de la licencia GNU GPL. db4o Open Source Compatibility License (docl) db4o tiene también un tipo de licencia especial creado para db4o de forma ad-hoc. En 2007, db4o introdujo esta tercera opción de licenciamiento para poder otorgar más flexibilidad de elección a los desarrolladores y empresas para los que hasta el momento solo existían dos tipos de licenciamiento, o adquirir una licencia como software privativo o publicarlo mediante una licencia GNU GPL. Esta nueva licencia otorga más posibilidades de licenciamiento a los desarrolladores y empresas en proyectos free/open source que usan db4o pero que no quieren o pueden publicar su proyecto enteramente bajo licencia GNU GPL, permitiendo así licenciar el código bajo alguna de estas licencias: GNU Library (or "Lesser") General Public License (LGPL), versions 2.0 and 2.1 Apache Software License, versions 1.0, 1.1, or 2.0 BSD License, as copyrighted on July 22, 1999 Eclipse Public License, version 1.0 MIT/X11 License Mozilla Public License, version 1.1 Recientemente, el 8/4/2010, Versant realizó un comunicado en el que se ampliaban estas licencias con la suma de: Microsoft Public License (Ms-PL) Microsoft Reciprocal License (Ms-RL) Code Project Open 1.02 License 23

25 Según el anuncio, Versant hace esto para poder llegar a mas proyectos FLOSS, que por cuestiones de licenciamiento no podían hacer frente a las restricciones de la licencia GNU GPL, como: Novell s Mono Redhat s Fedora-Linux Eclipse (Apogee) Spring JPOX Apache-Lucene (Gdata) RSSOwl newsreader Arum DataEye and Funambol (SyncML) Como dicen, con esta ampliación de licenciamiento, creen que db4o ya se podría usar en el 94 % de los proyectos FLOSS hechos en Java y.net existentes. Para poder hacer uso de la licencia docl, el desarrollador o empresa debe registrar su proyecto en la sección de Proyectos de db4o, y en su blog, y enviar un mail a su community manager, con la aceptación de los términos de la licencia docl Por qué db4o? Como se verá posteriormente con más detalle, db4o nos ofrece un medio para dar consistencia a nuestros datos en forma de base de datos completamente orientada a objetos con lo que la facilidad de uso en el desarrollo es muy buena, no hay necesidad de mapear un objeto en una fila, ni sus tipos de datos en las correspondientes columnas de una tabla, trabajar con objetos complejos es trivial y no es necesario hacer uso de herramientas que pasan del modelo orientado a objetos al relacional como Hibernate [39] que requiere de librerías adicionales y pesadas así como tiempo de proceso y complejidad mucho mayores. 24

26 3.4. Java Mail API Java Mail API es una expansión de Java que facilita el envío y recepción de desde código. Este paquete no viene con la distribución estándar de Java (Java SE) y hay que descargarlo de forma adicional. Si viene incluida, sin embargo, en la versión empresarial de Java (Java EE) Características Java Mail implementa el protocolo SMTP 23 los diferentes protocolos de correo POP3 24 e IMAP 25, así como los distintos tipos de conexión con servidores de correo como son TLS 26, SSL 27, autenticación con usuario y password, etc Licencias Java Mail desde el 2 de Marzo de 2009 es software libre, alojándose el proyecto en el sitio que Sun tiene para ello como es el Proyecto Kenai [40] y desde el 10 de Marzo de ese año también disponible en el repositorio Maven que Sun tiene para ello. Las licencias con las que está licenciado este proyecto son: CDDL-1.0 Common Development and Distribution License es una licencia de software libre creada por Sun Microsystems y basada en Mozilla Public License (MPL) versión 1.1. Los archivos que usan esta licencia pueden ser combinados con otros tanto de licencias privativas como de licencias libres. Está aprobada como software libre con FSF, OSI [41] y Debian [42], pero no es compatible con la licencia GNU GPL. Algunos de los proyectos que utilizan esta licencia además de Java Mail son: OpenSolaris NetBeans 23 Simple Mail Transport Protocol 24 Post Office Protocol 25 Internet Message Access Protocol 26 Transport Layer Security 27 Secure socket Layer 25

27 GlassFish Project DReaM GNU GPL v2 Es seguramente con la GNU GPL v3, la licencia más utilizada en proyectos de software libre, es del tipo de licencias libres robustas y es Copyleft 28, está aprobada por la FSF (sus creadores), OSI y Debian, pero no es compatible con su evolución la GNU GPL v3. BSD Esta licencia fue una de las primeras licencias de software libre, su nombre viene de Berkeley Software Distribution, es una licencia de tipo permisivo y está aprobada como software libre por la FSF, OSI y Debian, es compatible con la licencia GNU GPL (la licencia BSD de tres clausulas), pero no es Copyleft Por qué Java Mail? Como hemos indicado antes con db4o, el uso de Java Mail será explicado con más detalle en secciones posteriores, pero indicar que el motivo de elegir Java Mail como librería para realizar el envío de correo electrónico es debido a que Android no permite el envío del mismo sin la autorización de forma interactiva por parte del usuario, y como veremos, eso no es lo que queremos. 28 Obliga a los proyectos derivados de proyectos que usen esta licencia a otorgar los mismos privilegios con los que fue recibida la obra, para así mantener la cadena siempre de igual forma 26

28 4. Antecedentes y objetivos 4.1. Aplicaciones similares QuiteSleep trata de llenar un segmento de las aplicaciones de Android que no está muy explotado, que es el de controlar las llamadas entrantes y responder de una forma u otra cuando estas llegan. Como podemos ver si investigamos un poco por las sitios web que tratan de indexar las aplicaciones del market para ofrecer una navegación mucho más intuitiva como pueden ser AndroidZoom [43] y AndroLib [44], hay aplicaciones que filtran llamadas asociadas a números concretos, y otros que filtran según una situación previamente configurada. Para ver más en detalle a que nos referimos, vamos a resumir brevemente tres de las aplicaciones que se podrían decir que son rivales de QuiteSleep, que ya se mencionaron en la sección 2.3, pero que ninguna de ellas hace exactamente lo mismo. CallFilter Esta aplicación desarrollada por la empresa japonesa telemarks, realiza un bloqueo de llamadas entrantes para los números de contactos individuales asociados a los contactos que tenemos en nuestra agenda personal. Es decir, en esta aplicación elegimos que números de teléfono asociados a nuestros contactos (esto se realiza de uno en uno) queremos bloquear. Una vez definimos que teléfonos vamos a bloquear, cuando nuestro móvil reciba una llamada de algún número de los considerados bloqueados y la aplicación esté activa, esta rechazará la llamada realizando la acción de colgar (en ingles, hang up), una vez haya bloqueado la llamada el teléfono pasará a estar otra vez a la espera. 27

29 Figura 4: Imagen de la configuración de CallFilter Esta aplicación tiene una serie de carácterísticas, como son: Interfaz simple y sencilla. Funcionamiento muy bueno. Proceso para bloquear varios teléfonos de una única persona largo y tedioso. Únicamente en inglés. No tiene historial de llamadas bloqueadas. Gratuita. Software privativo. Sweet Dreams Sweet Dreams es una aplicación de los españoles Inizziativa los cuales fueron ganadores con esta aplicación del último concurso de aplicaciones de Google, el llamado Android Developer Challenge 2 (ADC 2) [46] realizado en verano de Sweet Dreams es una aplicación destinada a silenciar el teléfono móvil para no interrumpir tus sueños (al estilo de QuiteSleep), y que incluye varios tipos de configuraciones 28

30 donde también se puede indicar que se desactiven ciertas opciones del teléfono para ahorrar batería. En cuanto a la funcionalidad parecida a QuiteSleep, podemos indicar al teléfono que se ponga en modo silencio entre dos franjas de tiempo en los días de la semana establecidos, también podemos silenciar el teléfono en según que localización nos encontremos haciendo uso del GPS del teléfono, y por último podemos silenciar el teléfono si detecta que nos encontramos en un entorno de absoluto silencio, función que realiza haciendo uso de los micrófonos del mismo. Figura 5: Imagen de la configuración mediante intervalo horario de Sweet Dreams Vamos a ver ahora una serie de características de esta aplicación: Es la ganadora del ADC2, con lo que atesora calidad y funcionalidad. Es una Aplicación 100 % española. Aplicación con interfaz vistosa y funcional. Muy configurable. Muchas opciones, puede que demasiadas, lleva tiempo configurarlas todas. Algunas funciones son realmente ingeniosas útiles?. Buen funcionamiento. 29

31 Gratuita. Software privativo. Locale La ganadora del primer ADC en 2008, Locale es una aplicación creada por alumnos de informática del MIT [47] en su último año de estudios, para una asignatura llamada Building mobile applications with Android. Una vez desarrollada la aplicación estos alumnos han creado una empresa llamada TwoFortyFourAM [48] en la que hacen negocio con esta aplicación. Al principio Locale se trató de una versión Beta, que era gratuita y la cual fue probada y utilizada por miles de personas, para pasar después a ser una aplicación únicamente de pago. Locale actúa de forma muy similar a Sweet Dreams, pero con mucha más funcionalidad, ya que no solo se encarga de silenciar el teléfono móvil, si no que actúa sobre todos los elementos que consumen batería del mismo, como es activar/desactivar el 3G, el WiFi, permitir notificaciones, establecer un volumen específico dependiendo de la acción, hora, día, etc. Locale cuenta con una API para poder desarrollar plugins de terceros e integrarlos con ella, para hacer así un entorno mucho más funcional. Figura 6: Imagen de la configuración mediante situaciones o sitios en Locale Algunas características de Locale son: 30

32 Fue de las primera aplicaciones en aparecer y sin duda la de más calidad y funcionalidad. Tuvo un proceso en fase Beta largo donde pulieron todos los posibles bugs que salían para así convertirla en una aplicación muy estable. Múltiples acciones, no solo correspondientes con los tonos de llamada. Múltiples configuraciones. Fácil utilización, compleja, completa y sencilla. Ahora mismo es de pago con un precio de 10.99$ (dólares). Los plugins también son, en su mayoría de pago. Si queremos funcionalidad extra deberemos pagar por ella. Es software privativo. Después de ver lo que hacen estas tres aplicaciones (en el Android Market seguro que hay más aplicaciones parecidas, a día de hoy, hay más de aplicaciones) nos dimos cuenta que ninguna de ellas hacía lo que habíamos pensado, ya que, como hemos visto, hay aplicaciones que silencian el móvil por franjas horarias/diarias, que bloquean llamadas, pero no que silencien llamadas según quien nos llame en una determinada franja horaria/diaria, y adicionalmente realicen acciones post-llamada. Así QuiteSleep podía adentrarse en el comienzo de su desarrollo sabiendo que, al menos, conocido, no había nada parecido a lo que se pretendía hacer Objetivos A la hora de empezar con el análisis de requisitos previos al desarrollo teníamos que tener claro que pretendíamos ofrecer al usuario (objetivos) y como lo íbamos a ofrecer, las ideas de que queríamos conseguir estaban claras: Filtrado de contactos como contactos bloqueados. Silenciado de llamadas de los contactos bloqueados. 31

33 Por qué filtrar contactos y no teléfonos concretos? Un contacto hoy en día, es normal que tenga varios números de teléfono, y lo ideal en una aplicación de este tipo que puede manejar N contactos que a su vez tienen M números de teléfono es que ponga como bloqueados los contactos y no los teléfonos, ya que bloquear los teléfonos uno a uno puede ser una tarea mucho más pesada que bloquear un contacto que ya lleve implícito sus teléfonos, y sin ningún lugar a dudas cuando alguien piensa en un contacto no piensa en un numero de teléfono concreto de ese contacto, piensa en el contacto en si, una persona. Por qué silenciado en vez de bloqueado? Nuestra idea original nunca fue bloquear las llamadas, ya que nos parecía una acción relativamente agresiva, ya que si nos ponemos en el papel del contacto bloqueado, cuando alguien nos cuelga, el efecto que se produce en el móvil del llamante es el de un pitido repetitivo en intervalos, y de todos es sabido, que eso significa que han colgado tu llamada, con lo que puede dar lugar a posibles malentendidos. Con estos fundamentos básicos sobre que queríamos conseguir con la aplicación, se empezó a pensar en aspectos relacionados con el diseño, la usabilidad y posibles nuevas acciones que enriquecieran la funcionalidad básica de la aplicación: Aplicación realmente sencilla de utilizar que con pocos pasos se consiguiera tener lista para su uso. Una vez que estuviera totalmente configurada, que no fuera necesario volver a configurarla de forma completa, si no que si se quiere cambiar algo se realice con pequeños ajustes. Entorno amigable al usuario. Multilenguaje, nos parecía que la internacionalización debía ser un hecho. Adaptable a múltiples tipos de pantalla y resoluciones, en un mundo en donde cada día aparecen nuevos y mejores dispositivos, que nuestra aplicación esté adaptada y preparada a ellos sin realizar cambios o en el peor de los casos realizando mínimos ajustes, es primordial. 32

34 Atajos para realizar acciones pesadas, como por ejemplo establecer todos los contactos como bloqueados, o quitar todos los contactos de este modo. Posibilidad de hacer algún tipo de acción cuando hemos silenciado la llamada, como por ejemplo envío de sms o al contacto que ha llamado, indicándole nuestra situación de ocupado. Posibilidad de creación de algún informe con lo que ha ocurrido mientras la aplicación esta operativa. Acceso rápido y eficaz a la aplicación para así poder activarla y desactivarla rápidamente cuando el usuario quiera. Con respecto a la parte del desarrollo había algunas acciones que queríamos cumplir, como eran: Aplicación completamente FLOSS, tanto bibliotecas utilizadas como iconos, etc. debían ser software libre, intención de liberar la aplicación, siempre si se puede, bajo alguna licencia de software libre robusta que sea Copyleft, como GNU GPL. Desarrollo completamente en inglés para fomentar la posible colaboración de desarrolladores al ser un proyecto de software libre. Gestión de paquetes respetando estándares Java. Gestión eficaz de los recursos utilizados por nuestra aplicación, esto hay que tenerlo muy en cuenta a la hora de desarrollar aplicaciones para dispositivos móviles que no disponen de tantos recursos como los ordenadores personales o similares. Bien documentado, no solo en el aspecto de código fuente, si no también en la posible creación de documentación estándar y accesible en forma de API como puede ser la generada por javadoc. 33

35 5. Descripción informática 5.1. Metodología a seguir En todo proyecto de desarrollo software se realizan una serie de actividades (ciclos) entre la idea inicial u original del mismo y el producto final, que obtenemos cuando está totalmente acabado, y listo para su entrega. El plan de trabajo que se ha llevado a cabo para la realización de este proyecto ha consistido en la utilización de una determinada metodología o modelo de desarrollo, la cual establece el orden en el que se llevan a cabo las tareas pendientes de realizar durante toda la duración del proyecto. El modelo de desarrollo escogido ha sido el modelo de desarrollo en espiral. Este tipo de metodología o modelo está indicado para proyectos que varían en el tiempo atendiendo a los nuevos requisitos o a la modificación de los viejos. El modelo en espiral se basa en la necesidad de separar el comportamiento final en varias actividades más sencillas, que conjuntamente, formarán el comportamiento final del producto. Este modelo se caracteriza por la realización de fases o tareas las cuales son: Análisis de Requisitos Análisis del Riesgo Desarrollar, verificar y validar (probar) Planificar Lo verdaderamente importante de esta metodología es que nos aporta cierta flexibilidad en cuanto a posibles cambios de los requisitos iniciales y que nos ofrece, además, la posibilidad de ir construyendo prototipos que se producen como fase final de cada ciclo y los cuales nos servirán para comprobar si hemos cumplido con los objetivos o requisitos que nos propusimos al comienzo del ciclo, para luego evaluarlo en la fase final de planificación para poder pasar o no a la siguiente actividad. 34

36 Análisis de requisitos Análisis de riesgos Planificación Desarrollar, verificar y validar Figura 7: Modelo en Espiral Este modelo en espiral, fue adaptado a nuestro propio proyecto para que fuera totalmente orientado a el: Análisis de Requisitos (Comunicación con el cliente) Como cualquier otro proyecto, sea del orden que sea, el nuestro también tiene captura de requisitos y su correspondiente análisis. En esta fase el cliente especifica los requisitos al inicio del ciclo de la espiral, esto se corresponde con la realización de una reunión donde el tutor del proyecto nos da una serie de pautas u objetivos a cumplir o hacia donde debemos orientarnos. Una serie de requisitos, con los que se obtiene una idea general del objetivo del proyecto en cada ciclo. Aclarar, que la planificación inicial o previa solo se realiza una vez, no obstante volveremos a la captura de requisitos tantas veces como sea necesario para obtener nuevos requisitos o modificar los que anteriormente ya estaban fijados. Análisis de Riesgos Analizamos los requisitos dados por el cliente, estudiamos los riesgos potenciales y seleccionamos una o varias alternativas para reducir o eliminar riesgos. También en esta fase se evalúa el tiempo que necesitaremos para realizar cada ciclo, si es viable la actividad a realizar, y lo más importante si merece la pena. Así, nos disponemos a diseñar la 35

37 estructura de nuestra aplicación definiendo el paradigma de programación más indicado, el lenguaje de programación que más se adapte al paradigma escogido, los pertinentes diagramas para aclararnos las ideas y tenerlo todo más claro, etc. Desarrollar, verificar y validar Una vez que ya tenemos el diseño inicial nos disponemos a codificar la aplicación adaptando las ideas del cliente en los requisitos iniciales a lo que el programa realizará para obtener esos objetivos. Una vez desarrollada parte de la aplicación (o mientras la desarrollamos), la tenemos que verificar realizándole una batería de pruebas para ver si lo realizado hasta el momento se adapta a lo que teníamos diseñado, y por tanto si se adapta a las necesidades del cliente. Planificar la siguiente iteración Una vez llegados a esta fase revisamos todo lo hecho hasta el momento, y con ello, decidimos si continuamos con la actividad siguiente y la planificamos, o si debemos pararnos y analizar alguna fase anterior al no haberla superado como esperábamos. Así, una vez completada una actividad volveremos tantas veces como sea necesario a realizar todas las fases para llevar a buen fin el desarrollo del proyecto. Todas estas fases y cada actividad (iteración), con sus respectivos prototipos, serán validadas y supervisadas por el tutor del proyecto, corrigiendo errores, ampliando y modificando requisitos, etc. para la correcta conclusión del proyecto Fases del Proyecto Hemos dividido el proceso de creación del proyecto en iteraciones, o ciclos, con lo que una iteración completa no es la realización del proyecto en su forma total, sino la finalización de una meta propuesta en una etapa anterior y por tanto el intento de desarrollar ese propósito. Para cada iteración se realizaron diseños, bocetos, se creó código de ejemplo que para etapas maduras se ha desestimado, se mantuvo un contacto permanente con el tutor del proyecto, etc Fase 0: Toma de contacto Análisis de requisitos 36

38 Para empezar en esta fase, se mantuvo una reunión inicial con el tutor para ver que es lo que se iba a tratar de conseguir, es decir, el objetivo final del proyecto. Además de las indicaciones y consejos dados en esta reunión, se dio total libertad para el diseño de interfaces, creación, desarrollo de la lógica de negocio, etc. En esta etapa lo principal es realizar una primera toma de contacto con la API Java de Android para el desarrollo de aplicaciones, como en Java ya teníamos experiencia, este es un escollo ya salvado y solo nos tenemos que centrar en el aprendizaje de los conceptos principales de Android, vistos anteriormente, sus particularidades, el acceso a datos, etc. Análisis de riesgo En esta etapa no debemos evaluar mucho ya que es una etapa de toma de contactos y no hay riesgos que asumir ni deadlines 29 que cumplir. Desarrollo, verificación y validación En esta etapa se empieza la toma de contacto con la creación de interfaces gráficas en Android, en el cual, el modelo que sigue para su creación es bastante diferente de otros frameworks en los que lo normal es implementarlas (escribirlas) diréctamente en código. En Android, se puede implementar las interfaces gráficas de dos formas, o bien directamente en código, como hemos dicho antes, o bien mediante ficheros xml 30 en los que se indica como vamos a colocar los elementos o widgets que forman un activity, la forma de estos, su tamaño, etc. Una vez creadas algunas activities básicas para ver como funciona el diseño de interfaces, se pasa a dar por bueno el aprendizaje inicial que se basa en lo que se suele gastar la mayoría del tiempo en un proyecto software, la interfaz gráfica de usuario (gui). Para jugar con la creación de interfaces gráficas pasamos a crear activities independientes, englobadas dentro de un grupo de activities accesibles por pestañas o tabs en las que en cada activity (pestaña) realizamos pruebas con algunos de los componentes de Android. Planificación Para la siguiente fase se piensa como se va a desarrollar el proyecto de forma global, y se divide este en tres partes importantes, como son: 29 tiempos límite 30 extensible Markup Language 37

39 Figura 8: Reloj Figura 9: Formulario básico Gestión de contactos, donde se accederá a los contactos del dispositivo, se especificará cuales se bloquean y cuales no, etc. Gestión de horarios, donde especificaremos la franja horaria y días activos, en la que QuiteSleep podrá bloquear los contactos especificados. Gestión de servicios, donde inicialmente se especificará si la aplicación puede hacer su cometido cuando entre una llamada o no, es decir se activará o desactivará el servicio encargado de ello. Como se ha desglosado el proyecto en tres fases, se decide también que lo más idóneo para la creación de la interfaz de usuario, y ya que se han hecho pruebas satisfactorias, es diseñarla mediante pestañas, donde cada pestaña equivaldrá a una gestión antes mencionada, y por tanto a la configuración de cada fase. Pero antes de comenzar con el planning establecido, procederemos a algo muy importante y que regirá el correcto funcionamiento de toda la aplicación como es el modelo de datos que vamos a utilizar. En la siguiente fase se realizará el diseño de datos y su implementación para luego, ya si, proceder con el diseño de interfaz y funcionalidad planificado. 38

40 Fase 1: Acceso a datos Análisis de requisitos Antes de comenzar el desarrollo e incluso la planificación de este proyecto ya sabía cosas sobre el modelo de datos que usa internamente Android, los content providers, el uso de SQLite para crear propias bases de datos, etc. a día de hoy, para mi, el modelo relacional de bases de datos, es un modelo muy consistente, muy eficaz, idóneo para multitud de tablas, registros, etc. pero pensando en el lenguaje que se va a usar, como es Java, que es orientado a objetos y el modelo cuanto más básico y sencillo mejor para el manejo de la aplicación y sus posibles mejoras en el tiempo, pienso en todo momento el uso de la base de datos orientada a objetos db4o de forma interna y principal en la aplicación. Dada la experiencia que ya tenía con esta base de datos, ya que la utilizo a diario en mi trabajo desde 2007, no me costaría nada adaptarla a este nuevo sistema y utilizarla, y efectivamente, se piensa y se da paso a su utilización para nuestro proyecto. El modelo de orientación a objetos se ajusta muy bien a lo que tenemos pensado que serán las entidades protagonistas para esta aplicación como son, de inicio: Contact Clase que implementará el modelo de datos asociado a un contacto del dispositivo junto con los datos que utilizaremos de el como son los números de teléfono y las direcciones de correo electrónico. Banned Clase que implementa un contacto que hayamos especificado como bloqueado. Schedule Clase que implementará el modelo de datos asociado a la franja horaria y días que definamos para que la aplicación realice su cometido. Settings Clase que implementará la gestión de servicio activo o no de la aplicación QuiteSleep. Con este modelo, a la vista, básico, se piensa que será idóneo para modelizar todo lo que se piensa que va a realizar y gestionar la aplicación. Análisis de riesgo De inicio, como hemos dicho, pensamos que este modelo de datos es suficiente para la implementación de toda la funcionalidad de la aplicación, pero al ser esta una etapa 39

41 muy inicial del proyecto, cualquier cambio se puede realizar a este modelo en cualquier momento, o incluso vuelta a esta etapa para cambios en profundidad en un futuro. Desarrollo, validación y verificación Se implementan las clases anteriormente mencionadas de nuestro modelo de datos, junto con las restantes clases encargadas de la gestión interna de la BBDD en lo que a consultas, inserciones, borrados, actualizaciones y gestión en general se refiere. Se hacen pruebas con este modelo para probar que todo funciona de forma correcta y se da el visto bueno. Planificación Evaluamos todo lo creado hasta el momento y vemos que la progresión es correcta, con lo que damos el visto bueno para continuar con la siguiente iteración del proyecto Fase 2: Gestión de contactos Análisis de requisitos En esta fase del proyecto, nos debemos centrar en la gestión de los contactos, como accedemos a ellos, como obtenemos sus datos, como los gestionamos, etc. Para empezar aquí es donde se realiza una de las grandes decisiones de todo el proyecto y que es ni más ni menos, con que versión de Android vamos a trabajar, y la cual será la mínima versión que en la que QuiteSleep funcione. Como dijimos al principio, en la historia y evolución de Android (sección 3.2.1), se han ido sucediendo diferentes versiones, algunas con cambios más importantes y algunas con menos, bien, la API de gestión de contactos y toda la información que conlleva sufrió un cambio muy importante de la versión 1.6 a la versión 2.0, pasando los viejos métodos de acceso a datos de los contactos al estado deprecated 31, así, había que tomar una decisión, o seguir usando los viejos métodos y clases de acceso a datos, con lo que mantendríamos la funcionalidad en todas las versiones de Android hasta el momento, o empezar a usar la nueva versión que no solo cambia clases y métodos sino que incluso la forma de entender el acceso a los datos, con lo que las versiones inferiores 31 Indica que con el tiempo estos métodos y clases pasarán a ser eliminados de la API, no se sabe cuando, pero si que se procederá con ello en algún momento 40

42 Figura 10: Gráfico de versiones de Android Figura 11: Tabla de versiones de Android a 2.0 no podrán utilizar la aplicación pero en cambio esta si se podrá utilizar sin cambios en esta parte en versiones futuras de Android sin preocuparnos por nada. Con la ayuda del tutor se decide que lo mejor, y debido al rápido avance tanto de nuevos y modernos dispositivos como de nuevas versiones de Android, es centrarse en el desarrollo de Android 2.0 en adelante, ya que con el tiempo, y como así está pasando, las versiones inferiores a esta irán en decrecimiento hasta su desaparición total. Un ejemplo son las Figuras 10 y 11 en la que podemos ver, como a día de hoy (Junio 2010) las versiones iguales o superiores a la 2.0 se están imponiendo poco a poco. Análisis de riesgo En esta etapa un riesgo importante, y quizá el más importante de todo el desarrollo es la elección de a que versiones destinar la aplicación, como hemos dicho será para versiones iguales o superiores a la 2.0. Evaluamos los riesgos y problemas que podemos tener con esta decisión, uno de los riesgos es la novedad de este acceso a datos de los contactos, con lo que prevemos que no será trivial el acceder a los datos, debido a la escasa documentación, ya que aquí es donde nos damos cuenta, que lo que cuentan en foros de desarrolladores Android es cierto; la documentación oficial de Android en su web no es todo lo buena que debiera. Aún así procedemos con el diseño y desarrollo. Desarrollo, validación y verificación Como pensábamos, uno de los grandes inconvenientes de esta etapa fue la escasa documentación que había sobre el acceso a los datos de los contactos, con lo que tuvimos 41

43 que hacer frente a estos hándicaps, accediendo a foros, páginas de usuarios etc. hasta conseguir obtener los datos que nos interesaban. Una vez conseguidos los datos, es cuando entra en juego la base de datos orientada a objetos db4o, en la que importamos los datos de los contactos que al menos tengan un teléfono, ya que los contactos sin teléfono no nos interesan, y trabajamos a partir de este momento con nuestra propia base de datos. Así, es aquí el único sitio en toda la aplicación donde accedemos a los datos internos del teléfono asociados a los contactos, vía content providers. Una vez importados los datos, pasamos a la creación de la gui, donde estableceremos los mecanismos para: Añadir contactos a bloqueados. En esta sección establecemos los contactos deseados como contactos bloqueados, es decir, estos serán los que el sistema filtrará una vez esté en completo funcionamiento. Quitar contactos del estado bloqueado. Aquí quitamos el estado bloqueado de los contactos que ya lo están, pasando estos a contactos normales sin bloqueo alguno. Sincronizar datos de nuevo. Con esta opción permitimos al usuario que actualice los datos de sus contactos si por ejemplo ha agregado nuevos contactos, o si los ha modificado, etc. Como hemos dicho antes, una vez que importamos los datos pasamos a utilizar la base de datos db4o, con los datos que se han utilizado para esa importación, con lo que todos los cambios que se realicen desde la aplicación no se utilizan nunca los datos reales e importantes almacenados en el teléfono, se usa la base de datos db4o para todo, con lo que si el usuario actualiza datos globales al teléfono, para que estos queden reflejados en la aplicación deberá realizar una nueva sincronización. Esto que puede sonar como algo malo, no creemos que lo sea ya que el acceso a los datos desde la aplicación se hace utilizando el mismo paradigma que utiliza el lenguaje de programación con lo que con apenas un par de lineas podemos insertar datos en la bbdd, obtener datos, etc. y por seguridad todos los cambios que hacemos o posibles corrupciones de datos solo se verían afectados en los datos de la base de datos interna db4o. La sincronía por cambios es solo un pequeño handicap, pero 42

44 nada importante. En la Figura 12 se puede ver como quedaría el activity que se encarga de la interfaz de gestión de usuarios, en su primera versión. Figura 12: Versión inicial de la gestión de contactos en QuiteSleep En la Figura 13 podemos apreciar como se muestran los detalles de un contacto seleccionado antes de añadirlo como bloqueado, la información que se muestra al quitarlo de esa lista es muy parecido. 43

45 Figura 13: Versión inicial de detalles de los contactos en QuiteSleep Planificación En esta etapa hemos creado los elementos básicos para la gestión de contactos, como es acceder a ellos, sus datos, establecerlos como bloqueados, y quitarlos de ese estado, con lo que damos por buena la actividad y podemos pasar a la siguiente Fase 3: Gestión de horarios Análisis de requisitos En esta fase queremos dos cosas: Establecer una franja horaria de funcionamiento. Establecer que días de la semana será efectiva esa franja horaria. Como vemos, esto en principio, no es excesivamente complejo y casi toda esta fase se centra en crear una activity atractiva y funcional para que el usuario esté cómodo, y pueda hacer uso de ella de forma fácil y eficaz. La lógica de negocio se centrará en el desarrollo del algoritmo para comprobar que una hora esté dentro de una franja horaria/diaria definida aquí. 44

46 Análisis de riesgos Un problema que vemos aquí es el de que pasa con situaciones como puede ser la más común de franjas horarias entre dos días, en los que deberemos realizar un pequeño algoritmo que parsee todos los posibles casos de horas como son el anterior, el caso en que las horas estén en el mismo día, el caso de 24 horas, etc. Como se mostrará en el siguiente apartado, veremos como subsanamos esto. Por lo demás, no se prevé muchos problemas en esta fase, el acceso a datos es sencillo, una vez creados los datos por primera vez e insertados en la bbdd, siempre se procederá a su actualización cuando se produzcan cambios, sin necesitar la creación de nuevos objetos. Desarrollo, verificación y validación Para establecer una franja horaria donde la aplicación pueda silenciar las llamadas entrantes de los contactos bloqueados, se decide implementar dos botones donde el usuario establezca la hora de inicio y de fin que estime, esto se realiza mediante el uso de dialogs de Android, en los que establecemos la hora de forma rápida y sencilla. Para establecer que días de la semana queremos elegir ponemos a disposición del usuario una serie de checkbox en los que podrá seleccionar 0 o todos los días de la semana, para luego guardar su selección mediante un botón de forma rápida y sencilla. Como hemos dicho en el punto anterior,análisis de riesgo, vimos que podríamos tener problemas con como poder implementar el algoritmo que funcionase de forma correcta para todos los casos posibles de mezcla hora/día, y lo solucionamos como mostramos en el siguiente pseudocódigo: Hora tiempoinicial; Hora tiempofinal; Hora tiempoactual; Texto diacompleto = "24:00"; Texto iniciodia = "00:00"; boolean estaintervalo = false; 45

47 /* Si ambos tiempos, inicial y final son iguales * (caso de 24h ==> si 8:00 == 8:00) */ if (tiempoinicial == tiempofinal) estaintervalo = true; /* Si el tiempo final es después del tiempo inicial * (ejemplo tiempoinicial=10:00 tiempofinal=21:00) */ else if (tiempofinal esdespués tiempoinicial && (tiempoactual esdespués tiempoinicial && tiempoactial esantes tiempofinal)) estaintervalo = true; /* Si el tiempofinal es antes que el tiempoinicial * (ejemplo tiempoinicial=22:00 tiempofinal=3:00) * entonces, debemos añadir 24 al tiempofinal * (ejemplo tiempofinal=3:00 después del incremento=27:00) */ else if (tiempofinal esantes tiempoinicial ) { tiempofinalcambiado = cambiartiempofinal(diacompleto); /* Si tiempofinal=22:00 tiempoactual=23:00 diacompleto=24:00, * y ya hemos comprobado antes que tiempofinal antes * tiempoinicial ==> tiempofinal=3:00 */ if (tiempoactual esdespués tiempoinicial && tiempoactual esantes diacompleto) estaintervalo = true; 46

48 /* Si tiempoactual es después de las 00:00 * (ej tiempoactual=2:00) y tiempoactual es * antes que el tiempofinalcambiado entonces * cambiamos tiempoactual sumándole 24 (diacompleto)*/ else if (tiempoactual esdespués iniciodia && tiempoactual esantes tiempofinalcambiado) { tiempoactualcambiado = cambiartiempoactual(diacompleto); if (tiempoactualcambiado esdespués tiempoinicio && tiempoactualcambiado esantes tiempofinalcambiado) estaintervalo = true; else estaintervalo = false; }else estaintervalo = false; }else estaintervalo = false; return estaintervalo; Como vemos, poco podemos apuntar más que no se vea en el pseudocódigo, vemos como se abordan todos los posibles casos en los que una franja horaria, horas en formato de 24h, y días se pueden dar. Es esta etapa además del desarrollo se procedió a un intensivo test de casos de pruebas para realizar su verificación y validación, ya que el correcto funcionamiento de este algoritmo es fundamental en el correcto funcionamiento de la aplicación. En la Figura 14 podemos ver en una versión inicial como quedaría la gestión de horarios en QuiteSleep. 47

49 Figura 14: Versión inicial de la gestión de horarios en QuiteSleep Planificación En esta etapa se abordó de forma correcta la gestión de horas y días de actividad de la aplicación, se comprobaron casos de uso, se hicieron casos de prueba y se probó y validó todo, con lo que se certifica que esta parte está correcta y se da el visto bueno a dar el paso a la siguiente fase Fase 4: Gestión de servicios Análisis de requisitos En esta fase se pretende ofrecer al usuario una serie de mecanismos para que pueda activar la funcionalidad de la aplicación para poder filtrar o no las llamadas. Una cosa es el funcionamiento a la aplicación que se puede hacer entrando simplemente a ella, y otra es activar, por así decirlo, el servicio que atiende las llamadas entrantes y las filtra. En una reunión mantenida con el tutor se comentó que se podría añadir cierta funcionalidad extra para ofrecer algo de feedback a al hora de filtrar las llamadas, se sugiere que se podría enviar al contacto llamante algún tipo de mensaje para indicarle la situación del usuario, y que luego se pondrá en contacto con el, o algún otro mensaje predefinido por 48

50 el usuario. Así en esta reunión, se acuerda que se pueden utilizar dos de los servicios de mensajería más extendidos, el SMS y el , con lo que cuando un contacto definido como bloqueado intente contactar con el usuario, la aplicación silenciará la llamadas y si el usuario así lo quiere se enviará un SMS o al contacto llamante avisando del estado en el que se encuentra. Análisis de Riesgos No prevemos muchos problemas a la hora de activar/desactivar el servicio interno de la aplicación, si que nos podremos encontrar problemas con el envío de sms y , ya que algo que tenemos que dejar claro al usuario es que la utilización de alguno de estos dos servicios puede llevar implícito el uso de una tarifa adicional por parte del operador, así que se deberá indicar para que el usuario lo tenga claro. También se prevé que se deba estudiar a fondo la API de Android para hacer uso de estos dos servicios de feedback. Desarrollo, verificación y validación El objetivo principal de esta fase es la de ofrecer al usuario la posibilidad de activar y desactivar el servicio que pone en funcionamiento la aplicación, para que así realice el filtrado de llamadas entrantes o no. Esto se provee de forma fácil e intuitiva como un simple botón de dos estados con el que el usuario activará y desactivará esta funcionalidad. Para una mayor información del usuario sobre que está realizando, se implementan varios mecanismos de notificación: Las llamadas Toast de Android, que no son más que mensajes tipo pop-up con un mensaje informando al usuario y una duración predeterminada tras la cual desaparece. Las notificaciones en la barra de estado, en la cual se actualiza con un icono asociado a la aplicación y un mensaje indicando que el servicio está activo. Las notificaciones en la barra de estado en Android no son solo notificaciones mediante mensajes asociados a las aplicaciones, si no que sirven también como acceso rápido a las aplicaciones o ciertas partes de esta, con lo que si nosotros pulsamos sobre la 49

51 notificación de la barra de estado y no tenemos abierta la aplicación (abierta o en primer plano) iremos a ella de forma rápida y eficaz. Además de activar de forma general el servicio asociado a la funcionalidad de la aplicación, se da la oportunidad al usuario de activar o desactivar los servicios de envío de SMS o de forma individual, por si se quiere o no hacer uso de estos servicios y ofrecer toda la flexibilidad posible al usuario. Como comentábamos antes, es muy importante informar al usuario que hacer uso de estos servicios puede llevar un recargo por parte de su operadora, por ese motivo, cuando el usuario active alguno de estos servicios se le notificará para que lo tenga en cuenta, y actúe con total conocimiento de causa. En la Figura 15 se pude ver la pantalla original de esta configuración. Figura 15: Versión inicial de la gestión de servicios en QuiteSleep Como en esta etapa se pensó el uso de SMS y para dar una respuesta al usuario, también se decide modificar el modelo de datos de la base de datos para albergar esta nueva funcionalidad: Settings Al diseño original de este tipo de dato, se le añaden ahora además de tener un 50

52 flag para comprobar si el servicio global de QuiteSleep está activo, unos datos para guardar la configuración de SMS como es el indicador de servicio de envío de sms y , y los datos asociados al contenido de estos, cuerpo, asunto, etc. Para el envío de correo electrónico, Android provee unos intents para delegar esta funcionalidad a alguna de las aplicaciones que tiene el propio teléfono como es la propia de Gmail o la de otro tipo de correo, y que sean estas la que realicen esta acción con una simple llamada a sus servicios. El problema es que este modo utiliza la interacción del usuario con lo que en el caso de querer enviar un correo electrónico a un usuario, se mostraría la aplicación llamada y encargada de realizar el envío y el usuario tendría que pulsar el botón de enviar para hacerlo efectivo. Esto es algo que no queremos puesto que nuestro propósito es que el usuario configure la aplicación al principio y luego se olvide de todo, haciendo todas las gestiones la aplicación, así que el envío de correo electrónico utilizando estos mecanismos no nos vale. Así procedemos a la utilización y creación de unas clases y métodos para enviar el correo electrónico sin que el usuario tenga que interactuar de alguna forma, para ello hacemos uso de la librería Java Mail que como vimos en la sección 3.4 es una librería open source, y nos permite realizar el envío del correo electrónico como queremos. Utilizando esta librería lo único que tendrá que hacer el usuario es configurar el correo electrónico en la aplicación como se pude ver en la Figura 16, además de los parámetros antes mencionados de asunto y cuerpo, con los parámetros nombre y contraseña de la cuenta del usuario del servicio de correo electrónico de Google, Gmail [49]. Se decidió utilizar solo el servicio de correo de Gmail, por simplicidad de uso para nosotros y por el hecho de que los teléfonos que utilizan Android, están en perfecta simbiosis con los servicios de Google, siendo este servicio, el que más ligado está al sistema operativo está, ya que si queremos aprovechar toda la funcionalidad de Android, nuestros contactos serán los que se encuentren en nuestra cuenta de correo electrónico de Gmail, así, ahí tenemos todos los contactos con sus teléfonos, direcciones de correo, citas, cumpleaños, etc. 51

53 Figura 16: Versión inicial de la configuración de correo electrónico en QuiteSleep En lo que concierne al desarrollo, a nosotros nos resulta más fácil especificar un solo proveedor de servicios en forma de hardcode 32 para así evitar que al usuario se le pidan datos como servidor de correo saliente, correo entrante, tipo de seguridad, y otras opciones que a un usuario no técnico le puede resultar completamente extraño. Planificación En esta etapa hemos realizado otra de las tres partes importantes de la aplicación como es la activación y desactivación del servicio de QuiteSleep, y también como añadido hemos implementado los mecanismos para realizar el envío de SMS y tras filtrar una llamada de un contacto bloqueado. Para realizar esto, nos hemos dado cuenta que tenemos que realizar unos cambios en la gestión de contactos, para poder seleccionar que números de teléfono asociado a un contacto será posible enviar un SMS y a que direcciones de correo electrónico del usuario será posible realizar el envío del mismo. Se piensa dar la oportunidad de elección al usuario, para que si por ejemplo llega una llamada entrante de un contacto bloqueado desde un teléfono fijo, evitar que se le pueda 32 implementar en código directamente 52

54 enviar un SMS por defecto, ya que no es lo que el usuario querría, así, le ofrecemos al usuario la posibilidad de elección. Lo mismo pasa con el correo electrónico, puede que aunque el usuario haya activado el envío de correo electrónico no quiera que se envíe correo a ciertos contactos, con lo que queremos ofrecer al usuario la posibilidad de seleccionar que correos electrónicos asociados a un contacto son utilizados para enviar correo electrónico. Por supuesto, se podrá especificar que aunque los servicios estén activados, no se envíe nada a cierto contacto o a ninguno. Así con esto volveremos en la siguiente fase a la gestión de contactos Fase 5: Actualización de gestión de contactos Análisis de requisitos En esta fase volvemos a la gestión de contactos donde realizaremos una serie de cambios para adaptarlo a lo que hemos diseñado en la fase anterior, en la que definimos las pautas para enviar SMS o correo electrónico a los contactos bloqueados. Como vimos en la sección 5.2.3, cuando accedíamos a los contactos para bloquearlos, la única opción era bloquearlo o no, mostrábamos los detalles asociados a el como se mostraba en la Figura 13, pero nada más. Con el diseño comentado para el envío de SMS y correo electrónico, ahora debemos ofrecer al usuario mecanismos para poder seleccionar que teléfonos utilizar para poder realizar el envío de SMS, y que direcciones de correo electrónico permitir para enviar s. Así en esta etapa se dará paso al diseño y desarrollo de esta funcionalidad. Análisis de riesgo La complejidad de esta fase, además de cambiar el modelo de datos de la base de datos, radica en cambios en la interfaz, de forma que durante todo el proyecto hemos definido las interfaces en forma de xml estáticos, ahora con la variabilidad del número de teléfonos y direcciones de correo, la interfaz que da permiso a la elección de estos parámetros pasará a ser dinámica, y se construirá en tiempo de ejecución, con todo lo que conlleva, como rendimiento, visibilidad, etc. 53

55 Por lo demás no se prevé más cambios que los mencionados, ni más riesgos previstos. Desarrollo, verificación y validación Para el desarrollo de esta fase se hace uso de la creación widgets dentro de las activities de forma dinámica con lo que deberemos obtener los datos del usuario seleccionado y con los datos de este crear la interfaz. En la Figura 17 podemos ver como queda ahora el detalle de los contactos, donde además del nombre completo del contacto en la parte superior, se muestran unos checkboxes donde se puede seleccionar 0 o N números de teléfono a los que se estará permitido enviar SMS y 0 o N direcciones de correo electrónico a los que estará permitido enviar s. Figura 17: Versión modificada del acceso a los detalles del contacto en QuiteSleep Para el cambio en el modelo de datos de la base de datos, se añadieron los siguientes tipos de datos: Phone Cada teléfono seleccionado para poder enviar SMS, crea un objeto de este tipo, o se actualiza si ya está creado, para poder comprobar si una llamada asociada a número de nuestra agenda tiene permiso para enviar SMS. 54

56 Mail De la misma forma que el objeto anterior, este objeto se crea cada vez que añadimos una dirección de correo electrónico de un usuario como permitida para poder enviarle correo electrónico. Una vez modificado el diseño de la base de datos con estos objetos y creadas las activities y funcionalidad que dan acceso a la configuración de sms y , pasamos a su verificación y validación, en la que comprobamos, mediante el uso de emuladores como todo funciona de forma correcta. Planificación Una vez que con esta fase ya tenemos todos los elementos que son necesarios para probar la funcionalidad total de la aplicación en la siguiente fase se dará paso al diseño y desarrollo de la gestión de las llamadas, es decir la lógica de negocio de las llamadas, que sin duda alguna es lo más importante, si esto no funcionara, todo lo desarrollado sería inútil. Así pasaremos a la siguiente fase donde realizaremos estas tareas Fase 6: Gestión de llamadas Análisis de requisitos En esta fase vamos a diseñar e implementar la lógica central de toda la aplicación que no es más que la gestión de llamadas entrantes, como las gestiona, trata, etc. Como requisitos, nos proponemos que todo funcione de forma correcta, que siga la funcionalidad explicada como lo podemos ver de forma mucho más detallada en la Figura 18. En esta figura vemos como el teléfono se encuentra en estado de espera, este estado no es ningún estado especial, es el estado en el que se encuentra cualquier teléfono, utilice Android o no, cuando se enciende, es decir, está a la espera de realizar algo, los teléfonos tienen una serie de preferencias o acciones críticas y recibir llamadas sin duda es la más crítica, cualquier cosa que estemos realizando con el teléfono, se verá parada, o pausada al recibir una llamada. Vemos como nuestro proceso es ir caso por caso probando todas las opciones que a lo largo del desarrollo hemos ido diseñando e implementando, estos son: 55

57 Esperar llamada Recibir llamada Está el servicio activo? El teléfono pertenece a un contacto bloqueado? Estamos en el intervalo de tiempo correcto para silenciar la llamada? El teléfono está incluido en los teléfonos con envío de SMS? El contacto tiene direcciones de correo admitidas para enviar s? Así: 56

58 Figura 18: Diagrama de flujo del proceso de una llamada entrante procesada por QuiteSleep 57

59 Análisis de riesgo En esta etapa que sin duda es la más importante, todos los procesos que realizamos deben ser hechos con eficacia y con una gran optimización, ya que estamos introduciendo un proceso extra en el proceso más crítico de todos los que puede tener un teléfono móvil. Una vez evaluados los riesgos que nos podemos encontrar, pasamos al siguiente punto en donde realizaremos la implementación del proceso global. Desarrollo, verificación y validación Para la implementación de este proceso se hace uso de lo que en Android son los Broadcast Receivers [50], que son mecanismos con los que podremos atender a los broadcast intents que el sistema operativo crea y envía al resto del sistema mediante broadcasting para que cualquier aplicación pueda hacer uso de ellos. Un broadcast intent no es más que un intent con contenido asociado a el, como dijimos cuando hablamos de los intent en la sección 3.2.4, los intent son utilizados para enviar mensajes a todo el sistema, lanzar activities, etc. en el caso de los broadcast intent, el sistema al recibir una llamada crea uno de este tipo y lo propaga por todo el sistema (broadcasting), aquí es donde nosotros debemos implementar un broadcast receiver para atender a este intent y entonces realizar nuestro proceso como viene indicado en la Figura 18. Las gestiones de comprobación de todas las ramas condicionales las realizamos accediendo a la base de datos, las acciones de silenciado y envío de sms las hacemos accediendo a los elementos provistos por la API de Android, que tiene métodos para eso. El envío de correos electrónicos, como dijimos anteriormente, se realiza de forma programática creando un algoritmo que utiliza la librería Java Mail. Una vez que el teléfono procese una llamada y esta cumpla todos los requisitos para ser silenciada, QuiteSleep volverá a poner el teléfono móvil en modo normal, con lo que otras llamadas podrán sonar y vibrar sin problemas, si no hay que filtrarlas. En esta etapa se realizan multitud de test y pruebas de funcionamiento, tanto en emuladores como en dispositivos reales, y se da cuenta de los problemas que se producen, con lo que dio pie a dos implementaciones: La primera implementación, fue realizar lo que es obvio, filtrar las llamadas según 58

60 nos lleguen y cumplas los requisitos específicos. Pero en este caso, muchas situaciones, y por razones desconocidas, la aplicación al silenciar una llamada que tiene que ser silenciada, lo hace justo unas décimas después de que el teléfono suene un poco, pasado ese pequeñísimo instante se da paso al proceso de silenciado. Otra de las formas implementadas fue silenciar por defecto todo, y si la llamada no hay que silenciarla pasar a volver a poner el teléfono en modo normal, el problema es que se unas décimas en que la persona está llamando el teléfono está en silencio, pero creemos que es un problema menor, porque es my poco tiempo, y la persona que llama no sabe lo que ocurre. Pero esto nos dio más problemas, porque en ocasiones el sistema operativo Android mata las aplicaciones según sus recursos, es decir, que si está necesitado de memoria matará una aplicación sin tener en cuenta su funcionamiento, debido a esto, en ocasiones, al silenciar todo por defecto, el sistema operativo a veces mataba la aplicación, con lo que ya no se podía volver a poner en modo normal, y una llamada que no debería ser silenciada lo era, con lo que se trata de una opción inaceptable. Finalmente se decide utilizar la primera forma explicada, ya que es algo que por mucho que hayamos optimizado no es a causa de nuestro proceso, si no que se trata de algo aleatorio relacionado con la carga del móvil (procesos en funcionamiento, aplicaciones activas, etc.) en ese momento, porque como digo, en ocasiones suena un instante, y en otras muchas no, de hecho se ha comprobado que cuando suele sonar ese pequeño instante es cuando la llamada entrante es la primera llamada que recibe el teléfono desde que se enciende. Así se da por valida esta fase, ya que su funcionamiento es correcto y se procede al siguiente punto. Planificación Se puede decir que con esto el proyecto ya estaría terminado, pero creemos que podemos hacer algo más y se piensa en alguna otra funcionalidad para que el usuario sepa la actividad de la aplicación mientras esta está funcionando, así que se piensa en realizar en la siguiente etapa un historial de lo que ha ocurrido. 59

61 Fase 7: Creación del historial Análisis de requisitos En esta etapa ideamos como realizar un histórico de eventos que la aplicación a procesado, es decir, a nosotros nos interesa no todo lo que ocurra mientras QuiteSleep está activo en la franja horaria/diaria, ya que se puede dar el caso en que la aplicación esté activa las 24h los 7 días de la semana, con lo que estaría activa siempre. A nosotros lo que nos interesa es guardar un log o histórico con las acciones que realmente la aplicación ha realizado, es decir las llamadas que ha filtrado, los mensajes que ha enviado, los correos electrónicos, etc. Análisis de riesgos En esta fase no hay muchos riesgos que evaluar ya que se trata de un proceso que no es crítico, si que hay que tener en cuenta donde y como guardar los datos de un proceso el cual queremos conservar. También debemos proveer mecanismos para la gestión de este historial y que el usuario actualice o elimine cuando desee, notificándole previamente, todos los cambios que se pueden producir. Desarrollo, verificación y aplicación En el desarrollo de esta fase vamos a modificar el sistema de datos de la base de datos, añadiendo un nuevo objeto que guarde los datos de cada llamada que el programa procese durante su funcionamiento: CallLog Este objeto guardará los datos correspondientes a: Número de orden que ocupa dentro de todos los objetos de este tipo. Contacto (referencia al objeto Contact asociado al número de teléfono). Número de teléfono que ha efectuado la llamada. Fecha y hora de llamada. Si se ha enviado un sms. Número de correos electrónicos que se han enviado. 60

62 Como vemos con estos datos se guardan los datos importantes asociados al proceso de silenciar una llamada. Este objeto se creará solo cuando en el proceso de una llamada entrante, esta sea silenciada debida a estar en la franja de tiempo adecuada y pertenecer a un usuario bloqueado. Posteriormente se pasará a completar con los datos del envío del SMS y de los posibles correos electrónicos, una vez completado los datos del objeto, este se pasará a guardar en la base de datos, para poderse mostrar en forma de lista ordenada por los más nuevos primero en la lista y pestaña nueva de historial que será creada adyacente a la pestaña de configuración. Junto a esta nueva pestaña y funcionalidad, implementamos también dos menú buttons con los que el usuario puede actualizar el histórico de llamadas, ya que una vez que el usuario accede a la pestaña de historial, esta se carga con todos los datos de las llamadas de la base de datos, pero cuando el usuario vuelve a acceder al historial esta no se actualiza, se decide que sea el usuario el que actualice la lista por que así no se carga continuamente la base de datos cada vez que se accede a esta pestaña, aunque no tenga más datos nuevos. También se implementa un botón para eliminar todo el histórico de llamadas, y actualizar tanto la lista de llamadas como la propia base de datos. Este es un proceso no recuperable, por eso se avisa al usuario de las consecuencias. La pestaña historial puede verse reflejada en la Figura 19, tanto la lista de llamadas como los botones de menú comentados. 61

63 Figura 19: Versión inicial de la pestaña de historial de QuiteSleep En esta parte probamos que todo funcione de forma adecuada como tenemos pensado, verificando y validando todas las acciones y los casos de uso de esta fase. Planificación Con este añadido la aplicación cuenta ya con toda la funcionalidad pensada al inicio y con la que se ha ido innovando y añadiendo a lo largo de todo el desarrollo, ya se podría decir que se podría publicar, pero para se totalmente correctos y debido a que queremos liberar la aplicación como software libre, debemos en la siguiente fase hacer un repaso a todas las partes de la aplicación susceptibles de poseer licencias, tales como librerías, código, iconos, etc. También queremos ampliar un poco la información mostrada al usuario con unos apartados donde el usuario pueda consultar la ayuda en la propia aplicación y donde pueda ver datos de la aplicación, licencia y autor. Y por último se piensa en cambiar algunas partes de la interfaz de las que no se está del todo convencido. 62

64 Fase 8: Ajustes finales Análisis de requisitos Como hemos dicho anteriormente, la aplicación está terminada, pero antes de publicarla y ser totalmente legales tenemos que hacer dos cosas: Realizar unos añadidos para que el usuario pueda ver la ayuda de la aplicación y datos sobre ella, la licencia y el autor. Comprobar todas los recursos sensibles de poseer licencias y comprobarlas para ver si son libres o no. Como dijmos en la planficación de esta fase, también se dará un lavado de cara a la gui de la aplicación en las partes de las que no se está del todo convencido. Análisis de riesgo Durante el desarrollo de la aplicación se ha ido intentando utilizar licencias libres o gratis para uso no comercial del sitio web iconspedia [51] y esta será seguramente la parte no más crítica de esta fase si no la más pesada, ya que en el caso que tengamos algún icono no libre, deberemos encontrar iconos libres de los tamaños específicos para cada tamaño de pantalla que vamos a dar soporte. Desarrollo, verificación y validación Acerca de y Ayuda En esta fase vamos a implementar dos menú buttons como hicimos con los botones del historial para actualizarlo y eliminar sus datos, en los que en uno incluiremos toda la información asociada a la aplicación, como que es, quien es el autor, agradecimientos, licencia, sitio web, colaboración, etc. y otro con la ayuda en la que de forma resumida se hará un repaso del funcionamiento de la aplicación comentando todos los elementos del sistema. Licencias de los recursos Como decimos, durante el desarrollo de la aplicación no se puso excesivo cuidado a la hora de utilizar los iconos para la misma, es por eso que ahora habrá que hacer un repaso a las licencias de todos ellos. 63

65 Nuestra aplicación será liberada como GNU GPL, con lo que los iconos y todos los recursos externos utilizados deberán ser compatibles. Como se mostró en la sección 3 el sistema operativo, la base de datos orientada a objetos db4o, y la librería de correo electrónico Java Mail son compatibles con la licencia GNU GPL v3, con lo que por esta parte no hay problemas. Con los iconos, es ahora cuando investigando vemos que la licencia Free for noncommercial use no es una licencia libre por mucho que parezca, software libre no significa gratis, y esta licencia prohíbe su uso si se utiliza o se generan beneficios, con lo que debemos cambiar muchos de los iconos de la aplicación incluido el principal de la aplicación. Encontramos el sitio web open icon library [52] donde todos los iconos que hay aquí poseen licencias libres o son de dominio público con lo que se decide cambiar todos los iconos para evitar problemas con los que encontramos aquí y que son compatibles con la licencia GNU GPL. Para el icono principal y debido a que queríamos tener algo más original que un icono de los encontrados en el sitio web anterior, que son más genéricos, me fue regalado un icono realizado por un compañero mio diseñador ad-hoc para la aplicación, con lo que lo liberé con licencia libre GNU GPL para poder utilizarlo y colaborar con la comunidad para aquel que quiera utilizarlo. Para la fuente utilizada en la aplicación en la sección de gestión del horario, utilizamos para las pruebas una fuente de las que vienen incluidas en Android, pero para que tuviera un aspecto más de reloj electrónico utilizamos una con licencia CC-BY-SA v3 que es compatible con la licencia GNU GPL. La fuente fue obtenida del sitio web FontStruct [53] donde se encuentran licencias de todo tipo, privativas, libres, de dominio público, etc. Para finalizar esta etapa, al incluir todos los iconos y fuentes nuevas, revisamos y hacemos algunos pequeños ajustes en la aplicación en lo respectivo a la visualización, para hacerla más atractiva. Como detalle final, mencionar que en esta etapa es donde se crea la documentación mediante JavaDoc en forma de API, para poder utilizarla posteriormente, publicarla, etc. 64

66 Se comprueba y verifica que todos los iconos y fuentes se muestran de forma correcta, y se incluyen los menú buttons de Ayuda y Acerca de en todas las pestañas excepto en la del historial que ya posee los suyos propios, para que el usuario acceda a estos recursos casi desde cualquier sitio de la aplicación. Planificación Como fase final damos por valido todo lo realizado en esta fase y se da por terminado el desarrollo de la aplicación, estando lista, de inicio, para ser lanzada en el Android Market y puesta en su sitio web del proyecto para estar a disposición de toda la comunidad Detalles de la implementación Java y el paradigma de programación orientado a objetos nos ofrecen el diseño usando el modelo de clases, es decir que nuestro modelo de datos es nuestro modelo de clases, lo mismo pasa con la base de datos orientado a objetos, si hubiéramos utilizado una base de datos relacional, tendríamos que realizar el diseño en base a tablas, registros, etc. pero con esta base de datos, y como ellos publicitan en su web, la facilidad radica en que nuestro modelo de datos en la base de datos es el propio modelo de clases, de nuestro proyecto software. Como nota importante, apuntar que los paquetes aquí comentados son y tienen la funcionalidad que posee la aplicación en su última actualización a día de 31/5/2010, con lo que hay paquetes que utilizan métodos más modernos que los explicados en la sección 5.2, pero que serán explicados en apartados posteriores cuando se comenten las actualizaciones realizadas al proyecto original. En la Figura 20 podemos apreciar de forma global los paquetes utilizados en el desarrollo de la aplicación, en la que se muestran los paquetes de clases creados por nosotros y los paquetes utilizados de forma externa, como son los paquetes correspondientes a Android, db4o y Java Mail. 65

67 Figura 20: Diagrama de clases global utilizado en la aplicación. A continuación, vamos a mostrar nuestro diseño de clases separado en paquetes de funcionalidad similar como hemos dividido nuestro proyecto es.cesar.quitesleep.activities Este paquete es el utilizado como principal para el diseño de nuestra interfaz gráfica de usuario (gui), aquí definimos todas las activities que se ven y usan en primer plano, es decir las usadas en las pestañas, y la que es utilizada para iniciar la aplicación (Main). 66

68 Figura 21: Paquete de clases relativas a las activities principales es.cesar.quitesleep.callservices Este paquete es el utilizado para la creación de servicios Android que funcionan en modo background y son lanzados cuando se solicita el proceso que comprueba si la llamada entrante debe ser silenciada, y cuando se solicita volver a poner el teléfono en estado normal después de haber puesto el móvil en modo silencio al silenciar una llamada de un contacto bloqueado. 67

69 Figura 22: Paquete de clases relativas a los servicios Android que funcionan en background es.cesar.quitesleep.ddbb y es.cesar.quitesleep.interfaces El paquete.ddbb contiene todos los elementos utilizados en el modelo de datos de la base de datos db4o, así como todos los mecanismos para hacerla funcionar como es el servidor embebido en memoria, el cliente que hace uso de ese servidor, y los métodos de consulta, inserción, actualización y borrado. El paquete.interfaces contiene las interfaces utilizadas en la aplicación, en este caso solo se ha desarrollado una que contiene datos relacionados con la base de datos. 68

70 Figura 23: Paquete de clases relativas al modelo de datos de la bbd es.cesar.quitesleep.dialogs Este paquete contiene todas las clases relativas a los dialogs con los que se avisa al usuario que se van a realizar acciones que requieren una atención especial. 69

71 Figura 24: Paquete de clases relativas a los dialogs de aviso es.cesar.quitesleep.listeners Este paquete contiene la clase relacionada con el listener utilizado para atender el cambio de estado del teléfono en lo que a modo de llamada se refiere, atendiendo a los estados de: Llamada entrante. Llamada atendida. Llamada colgada. 70

72 Figura 25: Paquete de clases relativas a los listeners es.cesar.quitesleep.mailmessages Este paquete contiene las clases relacionadas con la gestión, configuración y envío de correo electrónico utilizando el paquete Java Mail. 71

73 Figura 26: Paquete de clases relativas a la gestión de correo electrónico es.cesar.quitesleep.menus Este paquete contiene las clases relativas a los menus de: Añadir todos los contactos como bloqueados. Eliminar todos los contactos del estado bloqueado. Actualizar el historial de llamadas. Eliminar todo el historial de llamadas. Pero no se refiere al hecho de mostrar los menús, sino, al proceso en background (utilizan threads) de cada una de estas acciones para realizar las acciones mencionadas, es decir su funcionalidad, no su apariencia. 72

74 Figura 27: Paquete de clases relativas a los procesos en background de los menús es.cesar.quitesleep.notifications Este paquete incluye la clase que realiza el proceso de gestionar la notificación que es utilizada cuando se activa y desactiva el servicio operativo de QuiteSleep. Figura 28: Paquete de clases relativas a la gestión de notificaciones es.cesar.quitesleep.operations Este paquete incluye las clases que realizan (o inician) la mayoría de procesos funcionales para la aplicación, como: 73

75 Comprobar el estado del servicio de la aplicación. Poner los contactos como bloqueados o no. Operaciones que son lanzadas después de mostrar dialogs. Operaciones relativas a las llamadas entrantes. Operaciones relativas a los procesos de envío de SMS y correo electrónico. Acciones correspondientes al inicio y parada de los servicios de QuiteSleep (el principal, el de SMS y el de ). Figura 29: Paquete de clases relativas a diferentes operaciones del sistema es.cesar.quitesleep.receivers Este paquete incluye las clases relativas a los Broadcast receivers, que están a la escucha de los eventos lanzados por el sistema operativo relativos a: 74

76 El estado del teléfono. La respuesta después de haber enviado un SMS. Los informes de entrega después de haber enviado un SMS. Figura 30: Paquete de clases relativas a las clases que atienden las peticiones broadcast es.cesar.quitesleep.smsmessages Este paquete contiene las clases relacionadas con la configuración, gestión y envío de SMS, contiene dos clases que realizan la misma función pero implementadas de forma diferente ya que una de ellas utiliza services de Android y otra threads de Java, se han creado para probar cual de las dos es más eficiente, pero actuando las dos de forma exactamente igual. Actualmente se utiliza la versión que usa threads de java. 75

77 Figura 31: Paquete de clases relativas a la configuración y envío de SMS es.cesar.quitesleep.staticvalues Este paquete incluye las clases que son utilizadas para contener objetos estáticos y utilizarlos muchas veces de forma directa como si fuera una caché. Figura 32: Paquete de clases que contienen objetos estáticos. 76

78 es.cesar.quitesleep.subactivities Paquete que contiene las clases correspondientes a las activities que no son utilizadas de forma principal, es decir, son activities que son lanzadas por las activities principales del paquete es.cesar.quitesleep.activities. Figura 33: Paquete de clases relativas a las activities secundarias de la aplicación es.cesar.quitesleep.syncdata Paquete de clases que se corresponde a los procesos de sincronía e importación de los datos de los contactos de la aplicación, obtenidos utilizando content providers con los datos contenidos en la base de datos orientada a objetos db4o. 77

79 Figura 34: Paquete de clases correspondiente a la sincronía e importación de datos es.cesar.quitesleep.utils Paquete correspondiente a clases utilizadas para realizar acciones de diversa índole como: Tipo de dato utilizado para el envío de correo electrónico. Control y gestión de excepciones. Control y gestión de logs. Control y gestión de notificaciones de tipo toast. Codificación de datos utilizando SHA1 [54]. Parseo de datos utilizando tokens. 78

80 Figura 35: Paquete de clases correspondiente a utilidades varias. 79

81 6. Proyecto FLOSS Como dijimos al principio de esta memoria, QuiteSleep se trata de un proyecto FLOSS. Al empezar el diseño y desarrollo del mismo, teníamos muy claro que nuestra aplicación la publicaríamos bajo una licencia de software libre, para así poder devolver a la comunidad lo que esta nos ha dado, que es el conocimiento. Esta sección está explicada siguiendo un orden cronológico, de más antiguo a más reciente. Después de realizar la última fase del modelo de desarrollo en espiral, se pasó a realizar la elección de licencias, publicación, etc. con lo que tuvo lugar el proceso de puesta en marcha de QuiteSleep como proyecto libre Fase1: Licencia Nuestro propósito desde siempre era publicar nuestra aplicación bajo una licencia robusta que fuese Copyleft, la más usada de este tipo es la GNU GPL, con lo que nuestra intención era publicarla bajo esta licencia. En este apartado completamos lo mencionado en la sección correspondiente a las licencias utilizadas en el proyecto. En esa sección realizamos la puesta a punto de la licencia a utilizar, y aquí procederemos ya a la inclusión de la licencia en el proyecto para su posterior distribución. Como hemos dicho antes, en otras ocasiones, los proyectos externos utilizados para nuestro desarrollo poseen licencias libres ahora debemos ver que tipo de licencia tienen: Android, publicado en casi su totalidad bajo la licencia Apache License 2.0 db4o, publicado mediante licencia dual, como hemos dicho en la sección db4o si queremos utilizarlo de forma libre nos permite utilizarlo bajo varias licencias, siendo la que a nosotros nos interesa la licencia GNU GPL v3. Java Mail API, publicada bajo varias licencias entre ellas GNU GPL v2 y BSD, la que a nosotros nos interesa es esta última ya que GNU GPL v2 no es compatible con GNU GPL v3, que es como nosotros queremos liberar nuestra aplicación. Iconos, fuentes y demás recursos, utilizamos licencias libres compatibles con GNU GPL, 80

82 como son licencias CC-BY-SA v3 o dominio público, que no es exactamente una licencia pero nos da total libertad de uso. Después de comprobar que todas las licencias utilizadas son compatibles con la licencia con la cuál queremos publicar nuestro proyecto, ya podemos hacerlo, y realizar los cambios pertinentes como son el cambio de todas las cabeceras de todas las clases con el manifiesto: /* Copyright 2010 Cesar Valiente Gordo This file is part of QuiteSleep. QuiteSleep is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. QuiteSleep is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. */ You should have received a copy of the GNU General Public License along with QuiteSleep. If not, see < Además, añadimos archivos diciendo el tipo de licencia que tienen los archivos de recursos como las imágenes o fuentes, y especificando también la licencia bajo la que está el icono principal creado específicamente para nuestra aplicación. Por último, añadimos también los archivos COPYING con la licencia en formato texto plano y README con datos correspondientes al proyecto, autor, contacto, etc. 81

83 6.2. Fase 2: Proyecto en una forja de software libre Para la publicación y mantenimiento de una comunidad sobre un proyecto de software, hay que publicar este haciendo uso de una de las múltiples forjas de software que hay disponibles como SourceForge [55], BerliOS, [56], Google Code [57], Launchpad [58], etc., que nos proveen no solo de espacio para poder alojar nuestro proyecto, sino que también nos ofrecen todo tipo de herramientas con las que poder llevar un proyecto colaborativo a buen puerto, como son, el repositorio para el código fuente, uso de foros, blogs, bugtracker 33, descargas de diferentes versiones de tarballs, documentación, historial, etc. Para nuestro proyecto nos decidimos por Google Code, ya que los proyectos open source de Android en general, se suelen alojar allí, debido a la delgada linea que separa Android y todos los servicios de Google. Google Code se trata, como decimos, de la forja para proyectos software de Google, en apariencia más sencilla que otros como SourceForge o BerliOS, Google Code ofrece todo lo que se le puede pedir a una forja, como son las características antes mencionadas. El sitio del proyecto se reserva al poco de comenzar el proyecto, y en el se anuncia en que estamos trabajando y cuando, más o menos, pensamos tenerlo terminado, y se planea su subida. El tutor nos sugiere subirlo al poco de empezar el proyecto, porque como bien dice, recibir visitas y apoyo de otros desarrolladores es complicado sin una relativa publicidad, con lo que si nosotros no hacemos uso de ella seguramente no tengamos. Finalmente se decide subirlo cuando se finalice la primera versión, más que nada por motivos de incumplir licencias y tener claro todo este aspecto legal, ya que durante el desarrollo de este proyecto, se estaba cursando la asignatura del máster, Software Libre [59] y se quiere aprender todos los aspectos de los proyectos libres antes de publicarlo. Como decimos, el día 18/05/2010 se decide publicar el proyecto, en el sitio del Proyecto en Google Code [60], donde se utilizan los siguientes recursos: Proyecto en un repositorio de tipo distribuido como es Mercurial [61]. Bugtracker. Descripción e historial. 33 Sitio dedicado exclusivamente al seguimiento de errores en un proyecto software 82

84 Aplicación lista para instalar y utilizar, en formato.apk de Android. Tarball con el código fuente, archivos de configuración, recursos, etc. Documentación en formato de API utilizando JavaDoc. La Figura 36 muestra la página principal del proyecto en Google Code. Figura 36: Captura de pantalla del proyecto QuiteSleep en Google Code. Junto con el proyecto en el sitio de la forja utilizada se crea también un grupo en Google Groups [62] para que la posible comunidad creada en torno al proyecto, tenga un sitio web donde poner todo lo relativo al mismo, con noticias, comentarios, bugs, etc. Como vemos en la Figura 37 el grupo del proyecto en Google Groups [63] es un sitio web sencillo con miembros, y posts donde se pone todo lo relativo a el. 83

85 Figura 37: Captura de pantalla del proyecto QuiteSleep en Google Groups Fase 3: Publicación en el Android Market Con la publicación del proyecto en el sitio de Google Code, se procede también a publicar el proyecto en el Android Market, para que los usuarios de móviles con sistema operativo Android con versiones iguales o superiores a la 2.0 se puedan descargar la aplicación, totalmente gratis, instalarla y utilizarla. Para poder subir aplicaciones al Android Market se necesita ser un desarrollador subscrito al Market, esto se realiza haciendo un pago de 25$ (dólares), y una vez hecho, como desarrolladores podemos subir nuestras aplicaciones, hacer dinero con ellas, comprar dispositivos de desarrollador, etc. Mediante la consola del desarrollador se hace todas las gestiones pertinentes a la publicación de la aplicación, muy pocos pasos que realizar y sencillez es lo que resume el proceso. En la Figura 38 podemos ver parte de la consola de desarrollador donde especificamos los datos necesarios y subimos el programa listo para instalar en formato.apk. 84

86 Figura 38: Captura de pantalla de la consola de desarrollador en Android Market. Una vez subida la aplicación al instante estará disponible en el Android Market de todos los países en los que hayamos especificado que está disponible (todos los posibles), y lista para que los usuarios hagan uso de ella Fase 4: Publicidad de QuiteSleep Con la puesta en marcha del lanzamiento del proyecto en todos los sitios mencionados anteriormente, se intenta dar un poco de publicidad, dentro de lo posible, a la aplicación. Como nuestra meta es la creación de un proyecto de software libre y que pueda ser atractivo para que otros desarrolladores se unan a el, la publicidad está centrada en la comunidad, no está orientada a descargas o utilización. Así, se da paso a publicitar el proyecto en los sitios open source Freshmeat [64] y Ohloh [65] que son básicamente sitios web donde tienen referencias de multitud de proyectos de software libre. En la Figura 39 y Figura 40 podemos ver los sitios web mencionados con sus correspondientes referencias al proyecto QuiteSleep. Compaginando con estos sitios, también se ha publicitado el proyecto desde el comienzo, y aunque no tiene la capacidad de alcance que los anteriores, ni mucho menos, en el sitio web (blog) del autor. En la Figura 41 podemos ver una imagen del mismo haciendo referencia a 85

87 Figura 39: QuiteSleep en Freshmeat [66] Figura 40: QuiteSleep en Ohloh [67] alguna de las noticias relacionadas con el proyecto. Sitios web donde dedicados a aplicaciones Android (pero en la parte de market) y que han referenciado también el proyecto han sido AndroidZoom [43], AndroLib [44], Bubiloop [69], Appbrain [70] y Cyrket [71]. Figura 41: Captura de pantalla del blog del autor con referencias al proyecto [68]. [72]. Además, cada anuncio nuevo del proyecto, se ha anunciado también en el twitter del autor 6.5. Fase 5: Logros y actividades Con el desarrollo de este proyecto, no solo se ha intentado realizar una aplicación que funcionase, si no que se ha intentado crear un proyecto de software libre a todas las escalas. 86

88 Durante todo el proceso se ha acudido a diversos sitios web de referencia en el desarrollo de Android, y en el transcurso y visita de estos sitios web, un día encontré una nueva comunidad de desarrolladores Android en Madrid llamada AndroidStartup [73], en ella comentaban en un post que les interesaba crear reuniones donde hablar del desarrollo en Android, lo que engloba a este sistema operativo, hablar de posibles modelos de negocio que se pueden abrir, networking, etc. yo me apunté y desde ese momento he sido, con los dos miembros fundadores, un valor muy importante para la comunidad ya que me puesto en contacto en numerosas ocasiones con la mayoría de grupos Android españoles como son and.roid.es [74], el grupo LibreSoft [76] del grupo GSyC de la Universidad Rey Juan Carlos, Android-Spa [75] e incluso Google con los que mantengo con todos buenas relaciones en cuanto a intereses comunes, que no es más, que la difusión del conocimiento. En Febrero de 2010, acudí a un evento organizado por Google y GSyC LibreSoft, llamado Android Developer Lab, que se trataba una charla en la que acudía un ponente y empleado de Google para contarnos aspectos relacionados con el sistema operativo y el desarrollo. En esta sesión acudió Reto Meier evangelizador de Android para Europa, África y medio Asia. En la charla además a los presentes se nos obsequió por parte de Google de un Nexus One que es ni más ni menos que el teléfono que Google sacó a comienzos de este año. Derivado de la charla de Android y de la creación y fomento de la comunidad Android- Startup, fui invitado a presenciar la keynote de Google I/O [77], donde se me ofreció si quería realizar alguna presentación una vez acabada la keynote, así que acepté, y el 20/5/2010 realicé dos presentaciones, una de mi grupo de Android junto con mis compañeros, y otra de mi aplicación para darle así la mayor publicidad posible, ya que era un evento orientado para desarrolladores principalmente. En la Figura 42 y 43 se pueden ver un par de imágenes de mi presentación en las oficinas de Google en Madrid (las fotos fueron realizadas por David Martin [78]). También cabe destacar que desde que se publicó el proyecto, se han puesto en contacto conmigo responsables de Markets de China y Korea del Sur solicitándome mi permiso para poder publicar QuiteSleep en sus respectivos mercados de aplicaciones móviles. Entre ellos, la empresa de origen Sur Koreana, se mostró totalmente dispuesta a traducir la aplicación a su idioma, con lo que se puede anunciar que QuiteSleep estará traducida, además de al inglés y al español, al koreano. 87

89 Figura 42: Google I/O 2010 Madrid (1). Figura 43: Google I/O 2010 Madrid (2). Por último destacar que gracias a los contactos realizados y los conocimientos adquiridos, he sido invitado a realizar una ponencia/charla en la Tenerife Lan Party 2010 [79] en Julio 2010 sobre el desarrollo Android, a la que por supuesto que acudiré Fase 6: Actualizaciones post-release Una vez que se publicó la aplicación en el Android Market, se tuvo constancia de fallos en la implementación del programa. En muchas ocasiones se tuvo constancia de que el sistema operativo Android por como maneja la gestión de sus recursos nos mataba la aplicación de igual forma que lo hacía en la 2 a forma explicada en la sección que se producía cuando se recibía una llamada, con lo que la aplicación produce un mal funcionamiento. Así que se decide actualizar el proceso de gestión de servicios de la llamada haciendo uso de servicios y threads, con los que realizaremos tareas en hilos separados, para comprobar si se produce una mejor respuesta. Ahora en vez de seguir lo reflejado en la Figura 18 pasamos a implementar lo que se muestra en la Figura

90 Figura 44: Diagrama de flujo actualizado del proceso de una llamada procesada por QuiteSleep 89

91 Como se puede apreciar, ahora se implementa todo en servicios y threads, cuando el teléfono detecta una llamada entrante, crea un servicio que se va a encargar de procesar esa llamada. Una vez creado el servicio, este, que funciona en background, comprobará si la llamada necesita ser filtrada, una vez comprobado esto, se crean unos threads tanto para el envío de SMS como el envío de correo electrónico, para que de forma independiente se encarguen de esos procesos. Cuando se ha terminado de procesar todo, el servicio creado se elimina así mismo para liberar memoria y tiempo de proceso. Esta nueva actualización es mucho más óptima ya que aprovecha mucho mejor los recursos del sistema y puede atender sin problemas llamadas sucesivas con poco margen de tiempo entre cada una, ya que cada llamada es tratada de forma independiente. Una vez solucionado este problema y otros menores, el día 29/5/2010, se publica en el Android Market esta nueva actualización, y desde entonces todo ha ido de forma perfecta sin reportar errores similares a los anteriores. Junto a esta actualización se pasa también a realizar ajustes en el envío de SMS ya que fue reportado y comprobado en persona que en el envío de SMS utilizando emuladores todo era correcto, siempre se enviaban y recibían, pero a la hora de hacer las pruebas en el dispositivo real Nexus One, el envío nunca se realizaba obteniendo un feedback del envío de error indeterminado con lo que nuestra labor de comprobación de por que no funciona se volvía complicada. Comprobando código de otros proyectos software y documentación se realizan unos ajustes y se consigue realizar el envío con el teléfono antes mencionado en ocasiones indeterminadas, es decir por alguna causa no se envía en todas las ocasiones, intuimos que se debe producir por algún bug en el sistema utilizando los métodos de la api como ocurre en otro teléfono como es el HTC Tatoo y que ya ha sido reportado en el bugtrack de Android Fase 7: Estadísticas En esta fase, y como fase final de resumen vamos a realizar un apunte basado en las estadísticas de las que tenemos referencia. Sitio del proyecto en Google Code Al crear el sitio del proyecto, realizamos también su adición en el sistema Google Analytics [80] para que nos hiciera un estudio de las visitas a nuestro sitio web. 90

92 Durante el desarrollo del proyecto, hubo pocas visitas, ya que el sitio no tenia nada interesante más que algún anuncio, pero no se había subido ni código ni se había publicitado nada, como hemos dicho antes, una vez se publicó la aplicación al repositorio y se publicó en el Android Market, se produjo un incremento a día de hoy de un 868, 75 % de visitas con lo que es un incremento elevadísimo. Las visitas se diversifican por todo el mundo como se pude apreciar en la Figura 45 en la que se puede ver como los países de procedencia de una gran parte de los usuarios es España, USA y China sobretodo. Figura 45: Mapa del mundo del origen de las visitas. En cuanto a descargas del proyecto, no se ofrecen datos de las veces que el mismo ha sido descargado desde el repositorio en Mercurial, pero si de los paquetes creados de tarball, documentación y.apk, siendo las descargas totales (agrupando las de las dos actualizaciones) a día de hoy (5/6/2010): tarball, 20 descargas..apk, 19 veces. api doc, 8 veces. 91

93 Lo mismo se puede decir, referido al número de visitas, al blog del autor, el cual desde que se publicó la aplicación se ha visto incrementado notablemente el número de visitas diarias. Con respecto a descargas de la aplicación en el Android Market, como se pude ver en la Figura 46 hay un número considerable de descargas (320), si nos atenemos a que en el market hay unas aplicaciones, la visibilidad es muy complicada. En cuanto a puntuación se tiene una valoración de cinco votos con una media de 3 estrellas, no está mal si tenemos en cuenta que los usuarios, al utilizar la aplicación, si esta da algún problema o no funciona como ellos creen que debe funcionar, juzgan de manera voraz. Figura 46: Captura de pantalla con los datos asociados a la aplicación en el Android Market. También cabe destacar el número de aplicaciones que actualmente están instaladas 114(35 %), estadísticas en las cuales se ve claramente, como se pudo comprobar al inicio del lanzamiento de la aplicación, que los fallos iniciales hicieron daño a lo que corresponde este valor. Desde que se subió la aplicación ambas cantidades, descargas e aplicaciones actualmente instaladas, se han visto incrementadas. 92

94 7. Conclusiones Para finalizar, las conclusiones generales después de haber realizado el proyecto desde su etapa más temprana en la que se pensaba que trabajo hacer hasta las etapas más recientes con las actualizaciones, puesta en marcha en el Android Market, creación y difusión del proyecto de software libre, etc. son las siguientes: QuiteSleep se posiciona en un lugar muy interesante en las aplicaciones para Android, útiles para el usuario y que no abundan demasiado. Nuestra aplicación compite con las anteriormente mencionadas CallFillter, SweetDreams y Locale pero no de forma en que teniendo una no puedes tener otra, son aplicaciones diferentes cada una ofrece una funcionalidad global muy parecida pero no igual en la forma y en el fondo. Estas aplicaciones son desarrolladas por empresas, nuestra aplicación ha sido desarrollada por un único desarrollador en relatívamente muy poco tiempo. El desarrollo de esta aplicación me ha permitido aprender como no es lo mismo programación para máquinas del tipo de ordenadores personales, aplicaciones web, etc. que no hay mucho en que preocuparse por los recursos, que realizar aplicaciones para dispositivos móviles con memoria y capacidad limitadas, así como espacio de pantalla, otros modos de interacción, etc. El desarrollo de la aplicación ha seguido una linea ascendente, en la que al principio fue de forma lenta, hasta conseguir un desarrollo ágil y rápido debido a la experiencia conseguida. Los procesos críticos que tienen cabida en la aplicación deben tratarse con la máxima eficiencia posible, y aún así esto no asegura su funcionamiento como se tenía pensado al depender de la gestión interna del sistema operativo. Destacar en el Android Market es una tarea difícil y seguramente costosa, difícil por que la visibilidad de cualquier aplicación que no esté bajo el desarrollo de una gran empresa o sea una de las primeras aplicaciones creadas cuando estas no abundaban es muy poca, 93

95 y costosa porque para mejorar esta visibilidad se ha de emplear tiempo y esfuerzo en dar a conocer la aplicación. Los usuarios muchas veces no hacen caso a los detalles puestos por la aplicación ni a la funcionalidad real de esta, en ocasiones quieren que realice algo que en realidad no hace. La información que se ofrece al desarrollador una vez publicada la aplicación es bastante escasa, debiendo hacer uso complementariamente de otras fuentes para un mayor feedback del producto. Se ha puesto en marcha un proyecto software libre desde cero, desde que no es más que una idea, hasta que se ofrece a la comunidad con una licencia, una funcionalidad, recursos para acceder al mismo, canales de comunicación entre los desarrolladores, publicidad, etc. La compatibilidad de licencias es un asunto muy importante que muchas veces se descuida, pero es vital por los aspectos éticos y legales que pueden derivar. En muchas ocasiones querremos utilizar dos licencias, pero a la hora de usarlas, veremos que son son compatibles, con lo que tendremos que hacer ajustes, utilizar otras librerías (con otras licencias), ver si se puede publicar bajo otra licencia que también satisfaga nuestros deseos, etc. Al publicar un proyecto como software libre, y publicitarlo al menos un poco, se obtienen referencias de otros sitios web relacionados, mensajes de usuarios, desarrolladores, etc. La evolución de un proyecto de software libre ofrece tomar varias vías para crear nuevas implementaciones, nuevos caminos por los que orientar la aplicación, etc. Como se ha podido ver en la sección 6.7, la creación de un proyecto de software libre, y las vías de acceso que ofrecen los sitios web de referencia al mismo, hace que el número de visitas a el crezca de forma importante. La creación (involucración) de un proyecto de software libre, me ha permitido de una forma u otra, adentrarme en la comunidad de desarrolladores de Android, conociendo gente, compartiendo conocimientos, teniendo nuevas experiencias, etc. Como decimos, con este con este proyecto, hemos ocupado un sector muy interesante en cuanto a funcionalidad en el universo Android y si a esto le añadimos que hemos la desarrollado el proyecto como software libre, podemos afirmar, sin miedo a equivocarnos, que hemos 94

96 creado, seguramente, una de las pocas aplicaciones españolas completamente FLOSS que se encuentran en el Android Market, accesible para cualquier desarrollador que esté interesado y completamente vivo, con actualizaciones en relativamente poco tiempo (y muchos planes para mejorarla) Futuras ampliaciones Este proyecto se empezó con el ánimo de ser un proyecto de software libre colaborativo (si hay interés), con lo que por parte del autor, este proyecto debe ser un proyecto que no muera de inactividad, así que estas son las futuras ampliaciones que se van a realizar a lo largo de lo que queda de año 2010: Filtrado de llamadas de números desconocidos. Filtrado de llamadas de todos los números. Exportación de la configuración actual de los contactos (bloqueados, sms y para enviar respuesta) a fichero de algún tipo ( xml?) para cuando se realice una nueva actualización/importación de contactos, mantener la vieja configuración de contactos que ya estuvieran configurados. Esta exportación también es válida para mantener una copia de seguridad de la configuración. Creación y gestión de grupos de usuarios. Varias franjas horarias/diarias. Nuevas vías para realizar filtrado, como acceso a Google Calendar [81], para comprobar reuniones, citas, vacaciones, etc. Cola de envío (FIFO) para el envio de mensajes y correo electrónico. Ayuda en formato html, accesible vía web para permitir acceso no solo desde el dispositivo móvil. Creación de wiki para el proyecto en el sitio web del mismo. Publicidad en sitios de referencia Android (blogs, webs, etc.). 95

97 Además de estas ampliaciones que ya están como propuestas, seguramente, a lo largo del desarrollo de estas surgirán otras nuevas mejoras que desarrollar, y si como se espera, el proyecto interesa, no solo a markets extranjeros o a usuarios convencionales, si no a desarrolladores, seguramente que el proyecto pueda tomar otros rumbos, manteniendo la idea original Implementaciones derivadas Además de las mejoras a la aplicación propuestas en el punto anterior, todo proyecto software ofrece nuevas vías de orientación del mismo siempre que no sea excesivamente maduro. Vamos a ver unos ejemplos de posibles evoluciones a este proyecto: Con la incorporación de la utilización del GPS, QuiteSleep podría hacer uso del mismo para comprobar números de teléfonos entrantes, comprobar su prefijo telefónico, y bien conectándose a algún servicio vía web donde obtener a que localización corresponde el mismo, o bien teniendo de forma pregrabada la misma información, poder filtrar llamadas, si por ejemplo nosotros nos encontramos en un país y la llamada se realiza desde otro, para así evitar molestarnos con llamadas de alto coste. Se podría hacer uso de plugins con los que hacer crecer la aplicación al estilo Locale, donde podríamos hacer uso de por ejemplo, un plugin para grabar nuestra configuración en un sitio remoto y obtenerla cuando la necesitemos, o acceder a servicios web para realizar estadísticas asociadas al número de llamadas, coste del número total de mensajes enviados, etc. Se podría utilizar las diversas secciones del programa, las cuales están bien diferenciadas, para ser utilizadas como bloques en otras aplicaciones que por ejemplo hagan uso de contactos, o de franjas horarias, sin que tengan que tener una funcionalidad parecida a QuiteSleep. Se podría hacer utilizando la funcionalidad de la aplicación que la misma se convirtiera en un objeto de vídeo vigilancia, tanto de fotografía como de audio o vídeo grabando lo que sucede alrededor, cuando por ejemplo suena una llamada. Derivado de lo anterior, y utilizando la interceptación de llamadas, se podría realizar 96

98 acciones de diversos tipos, como enviar la localización del teléfono en caso de perdida y que un número concreto haga la llamada. En conclusión al ser un proyecto completo pero bien estrucutrado, se puede, partiendo de la base, conseguir otro tipo de funcionalidad totalmente diferente de la funcionalidad original de la aplicación QuiteSleep. 97

99 8. Apéndice: Manual de usuario Vamos a explicar ahora de la forma más sencilla y breve posible como se utiliza la aplicación QuiteSleep; como se verá, es muy fácil de utilizar y sacar todo su provecho. Se va a dividir el manual en secciones que estarán ligadas a las pestañas de funcionalidad concreta en la que está dividida la aplicación, por supuesto esta no es la única manera de configurar y utilizar la aplicación, pero si la más intuitiva por seguir un orden. La primera vez que se instala la aplicación, y si nunca ha estado previamente instalada, se realizará una primera sincronización de los datos de los contactos del usuario. Solo se utilizarán contactos que tengan al menos un teléfono, ya que los que no tienen, no nos interesan Contactos En la primera pestaña, Contactos, configuramos los contactos que establecemos como bloqueados. Figura 47: Pestaña Contactos. Hay tres botones: Añadir Este botón lo utilizaremos para añadir contactos al estado de bloqueados para que la aplicación filtre sus llamadas. Como vemos en la Figura 48, una vez pulsado el botón de Añadir, se muestra una lista con todos los contactos que tenemos, si apretamos el botón 98

100 menú aparecerá el botón de añadir todos, con lo que podremos realizar esta tarea de forma mucho más rápida y cómoda. Figura 48: Lista de contactos listos para bloquear. Si pulsamos el botón de añadir todos se notificará al usuario que que esta acción puede llevar un tiempo dependiendo de la cantidad de contactos que tengamos en nuestra base de datos. Figura 49. Figura 49: Aviso antes de añadir todos los contactos a bloqueados. Si en vez de añadir todos, seleccionamos uno de los contactos para añadir de forma individual se nos mostrará una pantalla con los datos de ese contacto, y en donde podremos 99

101 configurar que números de teléfono serán usados para enviar SMS si nos llama desde alguno de ellos, o que direcciones de correo utilizar si nos llama desde cualquiera de sus teléfonos, además de añadirlo como contacto bloqueado. Figura 50. Figura 50: Detalle de un contacto al añadirlo como bloqueado. Quitar y editar Este botón se usa cuando queremos quitar algún contacto que tenemos como bloqueado de la lista de bloqueados o si queremos editar la configuración de este, modificando los números de teléfono o direcciones de correo electrónico que se utilizarán para el envío de mensajes. Sigue el mismo patrón que el botón Añadir, cuando lo pulsamos nos aparecerá una lista y pulsando el botón menú nos aparecerá un botón donde quitar todos los contactos bloqueados de ese estado. En la figura Figura 51, se puede apreciar la activity creada para este proceso. 100

102 Figura 51: Detalles de un contacto que ya está bloqueado. Sincronizar Pulsando este botón se producirá una nueva sincronización/importación de contactos. Esto es útil para actualizar los contactos que maneja de forma interna el programa, si hemos añadido nuevos contactos al teléfono, o si hemos modificado alguno que ya estaba. Cuando el usuario aprieta el botón se le comunicará que este proceso eliminará la configuración actual y que puede llevar un tiempo dependiendo de los contactos. Esta confirmación también eliminará el historial de llamadas de la aplicación. Figura 52. Figura 52: Aviso al realizar una nueva sincronización/importación de contactos. 101

103 8.2. Horario En esta segunda pestaña vamos a realizar la gestión correspondiente con la franja horaria y diaria en la que la aplicación podrá realizar su cometido. Figura 53: Pestaña de gestión de horario (franja horaria/diaria). Como vemos hay tres botones que realizan las siguientes funciones: Hora inicial Con este botón especificaremos la hora inicial en la que la aplicación bloqueará las llamadas de los contactos bloqueados. Al pulsarlo nos aparecerá un dialog donde especificaremos hora y minuto, para proceder a aceptar o cancelar con el cambio realizado. Figura 54: Especificación de la hora en la franja horaria. 102

104 Hora final Es exactamente igual que el caso anterior, una vez pulsado el botón nos aparecerá un cuadro de dialogo donde podremos introducir la hora de fin de la franja horaria. Días de la semana Como se muestra, hay siete checkboxes correspondientes con los que podremos definir que días de la semana funcionará la aplicación si esta está activa. Una vez establecido los días que queremos, los guardamos pulsando el botón de Confirmar días de la semana, nos aparecerá una notificación y ya estará todo listo Configuración En esta pestaña estableceremos los parámetros de configuración de los mensajes SMS y de correo electrónico, así como activar o desactivar su envío, y activar y desactivar el proceso general de QuiteSleep. Figura 55: Pestaña de configuración de servicios. Si pulsamos este botón nos aparecerá una ventana donde podremos establecer los parámetros de : Usuario (de la cuenta de Gmail). 103

105 Contraseña (de la cuenta de Gmail). Asunto (sbuject) del correo electrónico a enviar. Contenido (body) del correo electrónico a enviar. Figura 56: Configuración del correo electrónico. Podremos guardar la configuración establecida, y activar o desactivar el servicio de envío de correo electrónico. Al activar el servicio se notificará al usuario que usar esta característica puede llevar un coste dependiendo de nuestro operador. El usuario puede volver a desactivar, o modificar los datos cuando quiera. Figura 57: Aviso de la posible tarificación extra según el operador al activar el envío. 104

106 Figura 58: Servicio QuiteSleep arrancado. Figura 59: Servicio QuiteSleep parado. SMS Al igual que el botón de , con este botón configuraremos y activaremos el servicio de envío de SMS a los contactos que tengamos especificados que se le envíe un mensaje de texto. La opción a configurar es solo el texto del mensaje, ya que los mensajes de texto (SMS) no tienen título ni ningún otro dato. Podremos guardar la configuración (texto del mensaje) y activar o desactivar el servicio de envío de SMS, donde también nos será notificado al activarlo, que puede estar ligado a una tarificación extra según nuestro operador. Activar/Desactivar servicio QuiteSleep Pulsando este botón activaremos o desactivaremos (según su estado anterior) el servicio QuiteSleep. Al activarlo se nos notificará mediante una notificación en la barra de estado, y al desactivarlo lo hará mediante una notificación de tipo toast. Figuras 58 y Historial En esta pestaña podremos ver el historial de llamadas filtradas que ha procesado el servicio de QuiteSleep. En la Figura 60 podemos ver como se muestra la lista de las llamadas que ha procesado la aplicación como son: 105

107 Contacto. Teléfono. Fecha y hora. Envío de SMS. Envío de correo electrónico. Figura 60: Pestaña de historial con los botones accesibles tras pulsar la tecla de menú. Estos elementos no son clickables con lo que por mucho que los pulsemos no conseguiremos nada. Si apretamos la tecla menú podremos ver como aparecen dos botones: Actualizar Si pulsamos este botón, se actualizará la lista de llamadas del historial, eliminando la lista y actualizándola con nuevos datos. Al pulsar, y para que el usuario esté seguro de lo que realiza se pedirá confirmación al usuario indicando que esta tarea puede llevar un tiempo dependiendo de los datos a actualizar. Borrar Si pulsamos este botón, la lista se quedará vacía y se eliminarán los datos correspondientes al histórico de llamadas filtradas. Antes de realizar esta acción, se pedirá confirmación al usuario ya que esta acción es irreversible. 106

108 8.5. Acerca de y Ayuda Figura 61: Botones de Acerca de y Ayuda accesible desde las pestañas. En las pestañas de Contactos, Horario y Configuración, si se pulsa la tecla menú se tendrá acceso a dos nuevos botones: Acerca de Aquí se mostrará información de la aplicación, autor, licencia, contacto, etc. En esta información aparecen enlaces a sitios web como el sitio del proyecto, el grupo habilitado para discutir sobre el mismo, y la dirección de correo electrónico personal del autor para hacerle toda clase de comentarios, si se pulsa alguno de ellos el sistema abrirá la aplicación correspondiente, ya sea navegador web o cliente de correo electrónico para realizar las acciones pertinentes. Ayuda Aquí se mostrará información del uso de la aplicación (parecido al manual de usuario aquí explicado). Como vemos el funcionamiento de la aplicación es muy sencilla y configurarla nos llevará un tiempo determinado por el número de contactos que queramos configurar, una vez configurada, no habrá que realizar nada más salvo cuando se quiera realizar nuevos ajustes. Ni siquiera habrá que acceder a la aplicación cuando se encienda el teléfono de nuevo, porque QutieSleep se activará (si se dejó activada) por ella misma sin intervención alguna por parte del usuario y notificándoselo en la barra de estado. 107