diseño e implementación de una aplicación android para ... · diofrecuencia capaces de crear...

José Díaz de Greñu de Pedro

Juan José Olarte Larrea

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Grado en Ingeniería Informática

2014-2015

Título

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

Diseño e implementación de una aplicación Android paragestionar redes XBee a través de Device Cloud by

Etherios

Autor/es

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2015

publicaciones.unirioja.esE-mail: [email protected]

Diseño e implementación de una aplicación Android para gestionar redesXBee a través de Device Cloud by Etherios , trabajo fin de grado

de José Díaz de Greñu de Pedro, dirigido por Juan José Olarte Larrea (publicado por la Universidad de La Rioja), se difunde bajo una Licencia

Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los

titulares del copyright.

Facultad de Ciencias, Estudios Agroalimentarios e Informática

TRABAJO FIN DE GRADO

Grado en Ingeniería Informática

Diseño e implementación de una aplicación Android para

gestionar redes XBee a través de Device Cloud by Etherios

Alumno:

José Díaz de Greñu de Pedro

Tutores:

Juan José Olarte Larrea

Logroño, julio, 2015

Resumen

Los modulos XBee fabricados por Digi International son modulos de ra-diofrecuencia capaces de crear redes XBee, faciles de usar y energeticamenteeficientes . Sus aplicaciones abarcan desde los casos mas sencillos, como re-emplazar un par de cables en una comunicacion serial, hasta sistemas demonotorizacion y deteccion de incendios.

XBee Gateway for Android es una aplicacion Android pensada parausuarios que quieran introducirse en la tecnologıa XBee que permite conec-tar una red de dispositivos XBee con la nube de dispositivos de Digi (DigiDevice Cloud), evitando la necesidad de adquirir un XBee Gateway paraesta tarea. Ademas facilita interaccionar directamente tanto con el moduloXBee local como con los remotos existentes en la red mediante la interfazgrafica.

Palabras clave: XBee, Nube de dispositivos, M2M, Android, gateway.

Abstract

The XBee modules manufactured by Digi International are easy to use,low power RF modules capable of establishing XBee networks. Their usesgo from the simple operations, such as replacing a pair of serial cables, toeven more complex tasks like forest fire prevention in harsh enviroments.

The XBee Gateway for Android is an Android app for new users inter-ested in XBee technology which allows to connect a XBee network with theDigi Device Cloud, eliminating the need of acquiring a XBee Gateway forthis task. It also allows the user to interact directly both with the localXBee module and remote ones in the network using the graphical interface.

Keywords: XBee, Device Cloud, M2M, Android, gateway.

Indice general

1 Introduccion 11.1 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Digi Device Cloud . . . . . . . . . . . . . . . . . . . . 21.1.2 Dispositivos XBee . . . . . . . . . . . . . . . . . . . . 21.1.3 Terminos . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Planificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 Seguimiento y Control . . . . . . . . . . . . . . . . . . . . . . 8

2 Desarrollo 102.1 Analisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . 102.1.2 Requisitos de la aplicacion . . . . . . . . . . . . . . . . 12

2.2 Diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.1 Interfaz grafica . . . . . . . . . . . . . . . . . . . . . . 142.2.2 Arquitectura de la aplicacion . . . . . . . . . . . . . . 152.2.3 Modelo de datos y clases de utilidad . . . . . . . . . . 26

2.3 Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.1 Tecnologıas y software empleado durante el desarrollo 282.3.2 Librerıas utilizadas . . . . . . . . . . . . . . . . . . . . 292.3.3 Estructura del proyecto . . . . . . . . . . . . . . . . . 292.3.4 Ejemplos de implementacion . . . . . . . . . . . . . . 32

2.4 Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.4.1 Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . 472.4.2 Pruebas de integracion . . . . . . . . . . . . . . . . . . 48

3 Conclusiones 493.1 Propuesta de mejoras . . . . . . . . . . . . . . . . . . . . . . 493.2 Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . 50

Referencias 51

Capıtulo 1

Introduccion

Este documento recoge los aspectos mas importantes del Trabajo Fin deGrado titulado Diseno e implementacion de una aplicacion Android paragestionar redes XBee a traves de Device Cloud by Etherios realizado porJose Dıaz de Grenu de Pedro para la empresa Digi International bajo latutorıa de David Escalona Ozaeta y Diego Escalona Ozaeta por parte dedicha empresa y de Juan Jose Olarte Larrea por parte de la Universidad deLa Rioja.

En esta seccion introduciremos a la empresa comentando algunos con-ceptos importantes para el desarrollo de este Trabajo Fin de Grado y pre-sentaremos el proyecto realizado.

1.1 Antecedentes

Digi International es una empresa que ofrece soluciones M2M (machine tomachine) que consisten en la interaccion de diferentes maquinas utilizandodispositivos embebidos encargados de realizar la comunicacion y servidoresque se ocupan de realizar el envıo, recepcion y gestion de la informacionde las maquinas utilizadas. Su principal vıa de desarrollo es el hardware,disenando dichos sistemas que se conectan a Internet y permiten el accesoy control de forma remota.

El estudiante realizo una estancia en la oficina de Logrono durante elprimer semestre del ano academico completando la asignatura PracticasExternas I ası como un periodo de practicas extracurriculares. Durante estetiempo se desarrollo un pequeno juego para Android con el objetivo deaprender las bases de la programacion en este sistema operativo, utilizandotanto libros introductorios y de consulta [1] [2] [3] como la documentacionoficial de Android [4].

Vamos a detallar algunos de los productos relacionados con el este pro-yecto.

1

2 1.1. Antecedentes

Figura 1.1: Esquema basico comunicacion usando Digi Device Cloud paracontrolar dispositivos remotos.

1.1.1 Digi Device Cloud

Digi Device Cloud (anteriormente llamada Device Cloud by Etherios) es unaplataforma de administracion de dispositivos y un servicio de informacionque permite conectar cualquier dispositivo con cualquier aplicacion. Facilitaa los usuarios comunicarse con dispositivos remotos para administrarlos ytambien ofrece un servicio de almacenamiento de datos al que los dispositivospueden subir informacion de forma autonoma.

Para comenzar a usar esta nube basta con crear una cuenta (nombre deusuario y contrasena). Una vez disponemos de cuenta, podemos conectarun dispositivo con esta nube utilizando uno de los conectores1 que DigiInternational ofrece. Entre las funcionalidades ofrecidas por este serviciodestacamos:

• Configuracion, control e intercambio de informacion con dispositivosremotos mediate RCI (Remote Command Interface) [11].

• Recepcion y almacenaje de datos en forma de datapoints2 por partede dispositivos remotos.

El resto de caracterısticas y funcionalidades pueden consultarse en [7].

1.1.2 Dispositivos XBee

XBee es el nombre de una familia de modulos de radiofrecuencia3 (RF mo-dules) de bajo consumo y productos manufacturados por Digi.

Existen multitud de modulos XBee segun el perfil hardware y el firmwareque usen. En funcion de estos, cada modulo XBee recibe un nombre y quedan

1Los cloud connectors o conectores con la nube son APIs de sencillo uso disponiblespara diversas tecnologıas (C, Java SE, Java ME, MQX...).

2Valores tipados (enteros, reales, cadenas de texto...) con posible informacion adicionalcomo localizacion GPS o calidad de la informacion.

3Un modulo de radiofrecuencia es un pequeno circuito electronico que se usa paratransmitir y recibir senales de radio en distintas frecuencias.

Capıtulo 1. Introduccion 3

determinadas tanto la funcionalidad que proporciona como el protocolo decomunicacion que utiliza. Dicho protocolo determina la topologıa de las redesXBee que pueden formar. Ademas su comportamiento varıa en funcion delmodo operativo en el que esten configurados:

• AT (Aplication Transparent): Toda la informacion recibida por elpuerto serie es transmitida por radio directamente y viceversa.

• API: La informacion intercambiada con el modulo se estructura enAPI frames. Este modo permite configurar distintos parametros4 delpropıo modulo XBee, de modulos remotos en la red, recibir confirma-cion de cada paquete enviado por radio, y otras funciones.

• API escapado: Similar al anterior, salvo que determinados bytes de-ben ser escapados. Resulta util para evitar conflictos con determinadoscaracteres que tienen un significado especial en un API frame.

Existen multitud de aplicaciones para los XBee entre las que se incluyencontrol de incendios [19], riego automatizado [20], automatizacion de siste-mas de manufacturacion [21], energıas renovables [22], tratamiento de aguasy aguas residuales [23] y muchos otros.

Estos dispositivos estan disenados para ser muy eficientes energeticamen-te y por tanto poseen funcionalidad limitada, en concreto no son capaces decomunicarse con Digi Device Cloud directamente. Por este motivo, Digi ofre-ce distintos gateways5 que permiten conectar redes de dispositivos XBee condicha nube, tal y como se muestra en la figura 1.2.

Figura 1.2: Esquema basico de la comunicacion de una red XBee con DigiDevice Cloud empleando un XBee Gateway.

4Puede consultarse [15] para una lista completa y descripcion de dichos parametros.5Se entiende por gateway un dispositivo que permite interconectar dos redes de dispo-

sitivos con protocolos y arquitecturas distintas.

4 1.1. Antecedentes

1.1.3 Terminos

A continuacion se explican varios terminos que apareceran a lo largo deldocumento:

• Terminos relacionados con la tecnologıa XBee:

– Direccion XBee: Puede referirse a lo siguiente:

∗ Direccion de 64 bits: Identifica al XBee unıvocamente.

∗ Direccion de 16 bits: Identifica al XBee en la red.

– Baud rate : Tasa de baudios o baudaje, es el numero de unidadesde senal por segundo. Es un parametro requerido para la conexioncon un modulo XBee mediante USB o puerto serie.

– ZigBee: Conjunto de protocolos de comunicacion de alto nivelbasada en el estandar IEEE 802.15.4.

• Terminos relaccionados con Digi Device Cloud :

– Device ID: Codigo de la forma 01234567-89ABCDEF-01234567-89ABCDEF que Digi Device Cloud utiliza para identificar a undispositivo. Puede ser generado a partir de la MAC6 o del IMEI7

del dispositivo.

– Vendor ID: Codigo de la forma 0x12345678 que identifica unacuenta en Digi Device Cloud. Cuando un dispositivo se conectamediante algun Cloud Connector, es necesario especificar dichoidentificador.

– Keep alive : Este valor determina la frecuencia en segundos conla que el Cloud Connector envıa mensajes keep alive8 a Digi De-vice Cloud para mantener abierta la conexion.

– Server keep alive : Este valor es similar al anterior, pero deter-mina la frecuencia con la que Digi Device Cloud envıa mensajeskeep alive al conector.

– Tiempo de espera: Determina el numero de paquetes keep ali-ve (enviados o recibidos) tras el cual se dara la conexion comoperdida.

– Descriptor XML: Los descriptores son ficheros XML que mo-delizan un dispositivo de cara a Digi Device Cloud, determinandoque peticiones pueden procesar, que parametros pueden ser soli-citados, etc.

6Una direccion MAC (Media access control) o direccion fısica es un identificador de 48a 68 bits que corresponde de forma unica a una tarjeta de red.

7El IMEI (International Mobile System Equipment Identity) es un codigo que identificaa un dispositivo movil mundialmente usado en redes GSM.

8Los mensajes keep alive son aquellos que se envıan con el unico proposito de comprobarque la conexion sigue abierta.


1.2 Objetivos

El objetivo de este proyecto es desarrollar una aplicacion para Android quepermita utilizar el dispositivo Android para realizar las labores de un XBeegateway, es decir, comunicar una red de dispositivos XBee con Digi DeviceCloud. La aplicacion tambien permitira al usuario interactuar directamentecon la red XBee. En concreto abarca los siguientes puntos:

• Diseno e implementacion de la aplicacion principal Android.

– Conexion con un dispositivo local de radio XBee utilizando unaAPI o librerıa.

– Comunicacion con dispositivos remotos de la red XBee.

– Recepcion, procesamiento (mediante la red XBee) y respuesta depeticiones de la nube de dispositivos Digi Device Cloud.

– Recepcion de peticiones de la red XBee y transmision hacia DigiDevice Cloud.

– Capacidad para permitir a terceras aplicaciones interaccionar conla red XBee.

• Adaptacion de la librerıa Cloud Connector for Android, actualizandolae incorporando la posibilidad de integracion por parte de los usuarioscon el sistema de logging.

Por su parte, entre los objetivos de esta aplicacion se encuentra ofre-cer una alternativa mas economica (aunque con menos funcionalidad) a losusuarios que quieran introducirse al uso de modulos XBee, con aplicacionesmas simples como la domotica9 o las listadas en [24], eliminando la necesi-dad de que adquieran un XBee Gateway al poder usar cualquier dispositivoAndroid del que dispongan.

9Se denomina domotica al conjunto de sistemas capaces de automatizar una vivienda.

6 1.3. Planificacion

1.3 Planificacion

A la hora de realizar la planificacion del proyecto se han valorado los si-guientes aspectos:

• El cliente no tiene completamente definida la funcionalidad final delproducto, en su lugar hay una idea para la aplicacion con una seriede requisitos obligatorios y un conjunto de funcionalidad adicionalopcional. Esto permite realizar una planificacion flexible.

• El proyecto se va a desarrollar en solitario, unicamente por el alumno,lo que facilita su seguimiento y control.

• El alumno no cuenta con ninguna experiencia previa en ninguna de lasprincipales tecnologıas a emplear (Redes XBee, Android, Digi DeviceCloud), lo que dificulta detectar problematicas y estimar los tiemposde las distintas tareas.

A partir de estas consideraciones, se decide no realizar una planificaciondemasiado exhaustiva y en su lugar emplear una metodologıa de desarrolloagil iterativa incremental donde se iran implementando una por una cadauna de las distintas funciones exigidas, anadiendo mas o menos funcionalidadsegun del ritmo de desarrollo del proyecto.

Se realizaran reuniones semanales en las que participaran tanto el alumnocomo Diego y David Escalona en calidad de tutores y clientes, que valoraranel progreso realizado y seleccionaran la siguiente funcionalidad a implemen-tar.

El desarrollo del proyecto se llevara a cabo principalmente en la oficinade Digi en Logrono durante las mananas de los dıas laborales en un horarioflexible, pudiendo emplear tambien el alumno tiempo libre en su casa tardeso fines de semana si fuera necesario.

La descomposicion del proyecto en tareas se presenta en la tabla 1.1.


Tarea Descripcion Estimacion

Analisis Recopilacion de requisitos 12 h.Diseno Diseno a alto nivel de la aplicacion 20 h.

AppPreferencesDiseno e implementacion delmenu de preferencias de la aplica-cion

10 h.

MainActivityDiseno e implementacion de la acti-vidad principal de la aplicacion

16 h.

DashboardDiseno e implementacion del frag-mento del dashboard

34 h.

LocalXBeeDiseno e implementacion del frag-mento del XBee local

20 h.

XBeeNetworkDiseno e implementacion del frag-mento de la red de XBees

24 h.

LogDiseno e implementacion del frag-mento de registro de sucesos

6 h.

BackgroundServiceDiseno e implementacion del servi-cio en segundo plano de la aplica-cion

40 h.

Servicio AIDLCreacion de la interfaz AIDL ywrappers necesarios

10 h.

Peticiones RCIDiseno e implementacion del siste-ma de procesamiento y respuesta delas peticiones RCI

20 h.

PruebasRealizacion de pruebas de integra-cion de la aplicacion antes del cierredel proyecto

20 h.

Documentacion Documentacion del codigo 6 h.

ReunionesReuniones de seguimiento y controlcon los tutores de la empresa

20 h.

MemoriaRealizacion del documento para elTrabajo Fin de Grado

30 h.

PresentacionRealizacion de las diapositivas ypreparacion de la defensa ante el tri-bunal

12 h.

Total 300

Tabla 1.1: Descomposicion del proyecto en tareas.

8 1.4. Seguimiento y Control

1.4 Seguimiento y Control

Para el correcto seguimiento y control del proyecto se utilizaran principal-mente las siguientes herramientas.

• JIRA10: Los tutores David y Diego crearan las distintas tareas y sub-tareas definiendo el orden de implementacion de las distintas funcio-nalidades. El alumno por su parte las marcara como realizadas o uti-lizara el sistema de comentarios para detallar las posibles dificultadesque le puedan surgir. El estado del proyecto quedara ası documentadocon esta herramienta.

• Reuniones semanales: Se realizaran de una a dos reuniones sema-nales en las que se llevara a cabo el control y seguimiento, revisandoel trabajo realizado esa semana y dando el visto bueno para seguiradelante o rectificando las posibles desviaciones que pudieran habersurgido.

La tabla 1.2 resume el tiempo empleado en cada tarea ası como lasdistintas desviaciones que han surgido a lo largo del proyecto.

Tarea Estimacion Dedicacion Desviacion

Analisis 12 h. 8 h. -33 %Diseno 20 h. 18 h. -10 %AppPreferences 10 h. 12 h. 20 %MainActivity 16 h. 14 h. -12 %Dashboard 34 h. 40 h. 17 %LocalXBee 20 h. 35 h. 75 %XBeeNetwork 24 h. 14 h. -58 %Log 6 h. 20 h. 233 %BackgroundService 40 h. 42 h. 5 %Servicio AIDL 10 h. 12 h. 20 %Peticiones RCI 20 h. 16 h. -20 %Pruebas 20 h. 10 h. -50 %Documentacion 6 h. 4 h. -33 %Reuniones 20 h. 17 h. -15 %Memoria 30 h. 34 h. 13 %Presentacion 12 h. 10 h. -16 %

Total 300 302 0,67 %

Tabla 1.2: Tiempos planificados, dedicados y desviaciones de las distintastareas.

10JIRA es una aplicacion basada en web desarrollada por Atlassian para el seguimientode errores, de incidentes y para la gestion operativa de proyectos.


El proyecto se ha completado en las horas previstas. La mayorıa de ta-reas se han completado en un periodo ligeramente mas corto que el previsto,a pesar de implementar gran parte de la funcionalidad adicional. A conti-nuacion se comentan las desviaciones mas importantes:

• AppPreferences: Al ser la primera parte de la implementacion quese realizo, parte del tiempo fue dedicado a establecer el entorno dedesarrollo y solucionar los problemas derivados de los primeros usos.

• LocalXBeeFragment: Parte de la funcionalidad de este fragmento(lectura y modificacion de parametros) era muy parecida a la del frag-mento XBeeNetwork por lo que se implemento una componente masgenerica que pudiera ser aprovechada en ambos fragmentos. Esto pro-voco un incremento de horas en esta tarea pero redujo la siguientenotablemente.

• LogFragment: En el momento de la planificacion parecio un com-ponente casi trivial, sin embargo durante la implementacion surgieronvarios problemas no previstos difıciles de detectar y solucionar debidoa que la componente de logging debıa ser thread-safe e interactua conel hilo de la interfaz (que no debe ser bloqueado).

El principal requisito funcional adicional (la lista se presenta en el apar-tado 2.1.2) que no se implemento fue la actualizacion del firmware, ya queno lo permite la librerıa Java XBee Library (esto no se conocia durante lafase de analisis, ya que esta librerıa fue finalizada despues).

Capıtulo 2

Desarrollo

En este capıtulo se detalla el trabajo realizado durante las distintas fasesde desarrollo del proyecto. En las siguientes secciones, especialmente en losapartados de diseno e implementacion, son imprescindibles ciertos conceptospropios del desarrollo de aplicaciones Android. Las limitaciones de tamanode esta memoria no permiten detallarlos, sin embargo se explican brevemen-te segun aparecen. En cualquier caso se puede consultar la documentacionoficial [4] para clarificarlos.

Para el desarrollo del proyecto se realizo una etapa de analisis para laaplicacion, mientras que las etapas de diseno implementacion y pruebas sefueron repitiendo para cada incremento de funcionalidad. Esta seccion nosigue el orden cronologico, sino que se ha estructurado en cuatro grandessubapartados (analisis, diseno, implementacion y prueban) en los que sedocumentan las distintas fases del desarrollo.

2.1 Analisis

A continuacion se presenta el proceso de analisis de la aplicacion.

2.1.1 Casos de Uso

En una primera reunion con David y Diego, se plantearon los objetivosgenerales de la aplicacion y se propusieron los casos de uso que aparecen enla figura 2.1. Estan basados tanto en lo que permiten algunos XBee Gatewaysde la companıa como en la aplicacion XCTU [14] que permite interactuar yconfigurar un modulo XBee desde un ordenador. A continuacion se explicanlos actores que aparecen.

• Usuario Android: Se refiere a la persona fısica que interactuara conla aplicacion mediante la interfaz grafica.

• Device Cloud : El Cloud Connector for Android puede recibir peti-ciones de la Digi Device Cloud que pueden haber sido originadas de

10

Capıtulo 2. Desarrollo 11

varias formas: bien por un usuario que esta empleando alguna aplica-cion conectada a la nube, acciones planificadas o automatizadas lleva-das a cabo por los servidores, o en general por cualquier uso de la APIde la nube. Este actor representa cualquiera de estos usos.

• Aplicacion Android: La aplicacion Android a desarrollar ofrecera unaserie de servicios que cualquier otra aplicacion Android puede utilizar.Esas posibles terceras aplicaciones Android que hacen uso de estosservicios estan representadas por este actor.

Figura 2.1: Diagrama de casos de uso

12 2.1. Analisis

2.1.2 Requisitos de la aplicacion

A partir de los casos de uso se establecen los siguientes requisitos funcionales,algunos adicionales en funcion del ritmo de desarrollo del proyecto:

• Requisitos funcionales:

– La aplicacion permitira visualizar y controlar el estado de la co-nexion tanto con la Digi Device Cloud como con el XBee local,informando de los posibles errores que se produzcan e impliquenuna desconexion.

– Se podran leer y modificar todos los parametros que el XBee localsoporte.

– Se podra descubrir la red XBee utilizando el modulo XBee lo-cal, listando los nombres y direcciones de 64 bits de los XBeeencontrados. Tambien se permitira limpiar la red.

– La aplicacion permitira leer y modificar todos los parametros decualquier XBee remoto encontrado en la red.

– El usuario sera capaz de consultar un registro de los eventos ocu-rridos en la aplicacion, clasificados en funcion del origen del even-to (librerıa del Cloud Connector / librerıa de XBee / propia apli-cacion) y su importancia (debug / informativo / advertencia /error).

– La aplicacion sera capaz de recibir y procesar peticiones RCIdesde Digi Device Cloud. En particular, soportara al menos lossiguientes comandos RCI:

∗ Discovery request

∗ Query setting

∗ Query state

∗ Radio command

∗ Set setting

∗ Set factory default

El comportamiento en su procesamiento y respuesta debera serlo mas parecido posible al realizado por el resto de gateways ofre-cidos por Digi, al menos en los casos estandar (se permitiranintroducir codigos de error adicionales).

– (adicional) La aplicacion permitira actualizar el firmware del dis-positivo XBee local y de los remotos.

– (adicional) El usuario podra activar o desactivar un servicio dealmacenamiento de datos que permitira subir los valores de laslıneas IO y valores de paquetes de datos recibidos desde la redXBee a Digi Device Cloud.


– (adicional) La aplicacion permita mediante algun tipo de API aterceras aplicaciones al menos las siguientes operaciones:

∗ Conexion y desconexion tanto de la nube como del dispositivoXBee local.

∗ Lectura y escritura de parametros de XBee locales y remotos.

∗ Lectura de los siguientes parametros de conexion a Digi Devi-ce Cloud : direccion ip local, Device ID, version firmware, des-cripcion, Vendor ID, tiempo de reconexion, tiempo de keep-alive por parte del cliente, tiempo de keep-alive por parte delservidor, tiempo de espera, URL de conexion, tipo de cone-xion (segura o no segura) y estado de la reconexion (activadao desactivada).

∗ Lectura de la direccion de 64 bits del dispositivo XBee local.

∗ Descubrir y limpiar la red de dispositivos XBee.

Tambien permitira que las aplicaciones se subscriban para sernotificadas antes los siguientes eventos:

∗ Cambios en el estado de la conexion tanto con Digi DeviceCloud como con el XBee local (desconexiones, errores, inten-tos de conexion, conexiones exitosa).

∗ Recepcion de paquetes XBee:

· Paquetes de datos.

· Paquetes con los valores de las lıneas de entrada y salida(I/O Samples).

· Paquetes de cambio en el estado del modem.

∗ Dispositivos XBee remotos descubiertos.

Los requisitos que han sido listados son los de mayor prioridad, noobstante un objetivo de maximos (que no se pretende alcanzar) serıaconseguir una funcionalidad similar a la proporcionada por el XBeeZigBee Gateway de Digi, que puede ser consultada con detalle en [16].Muchas de las opciones ofrecidas por el software XCTU [14] tambienserıan interesantes para implementar en esta aplicacion.

• Requisitos no funcionales:

– Estetica de la aplicacion: La interfaz sera simple y seguira elestilo y colores propios de la empresa. Se visualizara correcta-mente al menos en los dispositivos moviles con las resoluciones1080x720. Adicionalmente es deseable que se adapte a la mayorıade resoluciones posibles, incluyendo tablets y pantallas full hd.

– Experiencia de uso: Hay que tener en cuenta que muchas ope-raciones pueden tener una latencia importante (tanto trabajando

14 2.2. Diseno

con Digi Device Cloud como con XBee remotos). La interfaz de laaplicacion debe mantenerse con capacidad de respuesta en todomomento, e informar al usuario debidamente de las operacionesque estuvieran realizando en segundo plano y de sus resultados.

– Eficiencia: Dada la gran diversidad de dispositivos Android, esnecesario cuidar tanto el consumo de CPU como el de memoriaRAM, intentando minimizarlos.

– Conectividad XBee: La aplicacion permitira conectar con XBeeen modo API y API escapado, mediante USB. Adicionalmente,soportara XBee en esos modos conectados mediante puerto serie.

– Portabilidad: La aplicacion debera funcionar correctamente almenos en todos los dispositivos Android API nivel 17 que tengansoporte para USB host1 [6]

– Localizacion: La aplicacion estara disponible al menos en inglesy permitira incorporar traducciones a otros idiomas de forma sim-ple.

– Desarrollo: El desarrollo del producto debera ser en ingles, estoincluyo el codigo, sus comentarios y todas las intervenciones y co-mentarios que se hagan en los distintos servicios de Digi (Stash,Confluence, Jira, ...) para el seguimiento del proyecto, documen-tacion, almacenamiento del codigo, etc.

2.2 Diseno

En esta seccion se detallan los aspectos mas importantes de la fase de disenodel proyecto. En los distintos diagramas que aparecen durante la seccion sehan usado colores para diferenciar el origen de las distintas clases y compo-nentes: los azules son componentes proporcionados por Android, los naran-jas los implementados por esta aplicacion y los morados los componentes deposibles terceras aplicaciones Android.

2.2.1 Interfaz grafica

Se decide usar una vista principal que contenga 4 pestanas:

• Vista del estado de la aplicacion que permita controlar los estados deconexion (dashboard).

• Vista del XBee local.

• Vista de la red XBee.1Este requisito es necesario para que la librerıa XBee Java Library funcione correcta-

mente con dispositivos XBee conectados por USB, aunque no es esencial para trabajarcon XBee conectados por puerto serie.


• Vista del registro de eventos (log).

Por otra parte, la aplicacion contara con una vista de las preferencias.Junto con David y Diego en calidad de clientes, se realiza un mockup de lainterfaz que ofrecera la aplicacion (figura 2.2). Para la vista de las prefe-rencias se decide utilizar la que ofrece Android por defecto, por lo que noresulta necesario realizar ningun esquema.

No se incluye un diagrama de navegacion dada la sencillez del mismo: elusuario puede elegir la pestana a la que quiere acceder mediante el menu su-perior o bien arrastrar el dedo sobre la vista actual hacia uno u otro lado paramoverse a una adyacente. El boton Settings en la parte inferior izquierdadel primer fragmento permite acceder al menu de preferencias.

Otros elementos de la interfaz grafica que no se muestran incluyen elicono de la aplicacion, que sera realizado por David y/o Diego, y distintoscuadros de dialogo que se utilizaran para interactuar con el usuario. Para eldiseno de estos ultimos se seguira la lınea de Android: interfaces sencillas conpocos elementos (habitualmente un TextView indicando al usuario que seespera que introduzca y un EditText para recibir la respuesta), un botonpositivo a la derecha y otro para cancelar la opcion a la izquierda.

2.2.2 Arquitectura de la aplicacion

Al tratarse de una aplicacion Android, la arquitectura de la aplicacion quedadeterminada por sus componentes2 y las relaciones entre ellos. Estos son loscomponentes principales de la aplicacion:

• MainActivity: Actividad principal de la aplicacion. Se encargara demostrar las cuatro vistas de la interfaz principal.

• PreferencesActivity: Esta actividad sera la encargada de mostrarlas preferencias de la aplicacion.

• BackgroundService: Este servicio se iniciara cuando el dispositivose encienda y continuara ejecutandose en segundo plano en todo mo-mento. Se encargara de iniciar las librerıas de conexion a Digi DeviceCloud y al XBee, y servira de interfaz entre estas y las actividadesque quieran usarlas, tanto MainActivity como aplicaciones android deterceros.

2Los componentes de aplicacion son los bloques de construccion principales de unaaplicacion Android, los mas importantes son:

• Activity: Representa una pantalla con una interfaz para el usuario.

• Service: Se ejecuta en segundo plano para realizar tareas de larga duracion.

• Broadcast receiver: Escucha y responde a intents (explicados mas adelante) sobredistintos eventos.

16 2.2. Diseno

Figura 2.2: Mockup de la interfaz principal de la aplicacion.


• ServiceStarter: Este receiver es necesario para poder iniciar el ser-vicio anterior cuando el dispositivo Android arranque. Esa es su unicafuncion.

La aplicacion interactua con el sistema Android mediante los siguientesintents3:

• android.intent.action.BOOT COMPLETED: El sistema produ-ce este intent cuando el dispositivo se inicia. Lo utilizaremos paracomenzar el servicio en segundo plano.

• android.intent.action.MAIN: Android envıa este intent cuando elusuario solicita iniciar la aplicacion. Como respuesta se iniciara y mos-trara la componente MainActivity.

• Intent.ACTION BATTERY CHANGED: Se produce cuando haycambios en el estado del telefono como baterıa baja, baterıa llena, car-gando, etc; aunque no hay documentacion clara sobre los casos exactos.Se utilizara para comprobar si el modulo XBee USB ha sido desconec-tado.

Ademas nuestra aplicacion define los siguientes intents para notificaral sistema, a aplicaciones de terceros y a otras componentes de nuestraaplicacion sobre cambios en las conexiones.

• XBeeManager.ACTION XBEE STATUS CHANGED: Envia-do cuando se produce un cambio en el estado de conexion con el XBeelocal. Incluye un codigo indicando el nuevo estado de conexion (conec-tando, conectado, desconectado, error) y una descripcion con informa-cion adicional.

• CloudManager.ACTION CC STATUS CHANGED: Similar alanterior, en cuanto la conexion con Digi Device Cloud. Lleva la mismainformacion.

Las dos activities se bindearan4 al servicio para poder tanto obtenerdistinta informacion sobre el estado de las conexiones XBee y Digi Device

3Los intents son el mecanismo basico en Android para la comunicacion asıncrona desucesos o acciones a realizar entre componentes. Cada componente puede enviar intentsal sistema operativo que se encargara de notificar a otras que hayan registrado escuchado-res. Este mecanismo es necesario porque distintas componentes pueden estar en distintosprocesos.

Otro uso de los intents es enviar mensajes al sistema operativo para que este realicedeterminadas operaciones, como iniciar otra componente.

4Una activity (y algunas otras componentes) pueden bindearse (enlazarse) a un serviciopara enviar peticiones, recibir respuestas e incluso realizar comunicacion entre procesos.Es el mecanismo propio de Android para comunicacion prolongada entre componentes.(http://developer.android.com/guide/components/bound-services.html#Binding)

http://developer.android.com/guide/components/bound-services.html#Binding

18 2.2. Diseno

Figura 2.3: Diagrama de componentes, las flechas representan intents.

Cloud como realizar distintas peticiones. Tambien terceras aplicaciones An-droid que quieran hacer uso de la API que esta aplicacion ofrece, como severa con mas detalle en el apartado 2.3.4.

Todas estas relaciones aparecen en la figura 2.3, donde tambien se indi-can los distintos intents mediante flechas. Por simplicidad, las flechas querepresentan intents destinados al sistema para iniciar o comunicarse conotras componentes (startService, bindService y startActivity) tienen el ex-tremo en dicha componente en lugar de en el sistema Android (aunque enrealidad los intents van dirigidos a este).

Una vez visto el funcionamiento general de la aplicacion y sus interaccio-nes con el entorno, vamos a profundizar en las componentes fundamentales(no nos detendermos en los BroadcastReceivers, ya que en todos los casossolo constan de un callback).

MainActivity

Esta es la componente principal de la interfaz grafica de la aplicacion. Lamayor parte del tiempo la aplicacion se estara ejecutando en segundo planosin interfaz grafica, pero cuando el usuario quiera intervenir y abra la apli-cacion, esta componente se inicia y se encarga de lo siguiente:

• Estado: Distintas partes de la interfaz necesitan mostrar parte delestado la aplicacion ası como habilitar o deshabilitar ciertas accionesen funcion de este. MainActivity se encarga de, al iniciarse, consultarel estado actual al servicio y mantenerlo consistente en todo momento(notificando a las vistas de los cambios que se producen), para lo quehace uso de un BroadcastReceiver pendiente de posibles intents quelance el servicio.

• Interfaz: La gestion de la interfaz resulta sencilla utilizando los meto-dos proporcionados por Android para el diseno de interfaces mediante


fragmentos. Se hace uso de un FragmentPagerAdapter para la gestionde fragmentos y una ActionBar junto con su TabListener para mostrarlos tıtulos de los fragmentos y permitir desplazarse entre ellos.

• Comunicacion con el servicio: Se realizara un bind con la compo-nente BackgroundService para comunicar con ella y poder realizar lasacciones que el usuario solicite mediante la interfaz grafica. Tambienes necesario un atributo de tipo ServiceConnection para ser notifica-dos del inicio y posibles perdidas de la conexion entre la activity y elservicio.

Los distintos fragmentos estan disenados segun el mockup de la aplica-cion (figura 2.2) con una excepcion: la parte inferior del segundo y tercerfragmento tienen apariencia comun, por lo que se disena un quinto fragmen-to que se utilizara como fragmento anidado en los fragmentos dos y tres.Ademas se utilizara una clase abstracta para la funcionalidad comun:

• Nombre del fragmento.

• Callback para ser notificado sobre cambios en el estado de conexion.

• Acceso al servicio (mediante una referencia a la MainActivity que pro-porciona acceso al servicio).

A continuacion se presenta la funcionalidad de cada fragmento (en elmismo orden que en el que se presentaron los mocksups):

• DashboardFragment: En la parte izquierda de la vista se muestra elestado actual de la conexion con la Digi Device Cloud (parte superior)y con el modulo XBee local (parte inferior). Los posibles estados paraambas son conectado, conectando, desconectado y error.

En la parte derecha se muestran tres paneles, de arriba abajo: conexionDigi Device Cloud, conexion XBee, y preferencias. Los dos primerospermiten conectar o desconectar, en funcion del estado actual de di-cha conexion y en caso de que el estado actual sea error muestraninformacion adicional. El ultimo inicia la actividad de preferencias.

Si se producen cambios en el estado de la conexion mientras esta vistaesta en pantalla, es necesario que se actualice en el momento mostrandoel nuevo estado (para lo que se hara uso del callback que proporcionala clase abstracta).

• LocalXBeeFragment: Si la conexion con el modulo XBee local noesta establecida, se muestra una vista alternativa estatica y sin funcio-nalidad que informa de que esta pestana solo esta disponible cuandoun modulo XBee esta conectado.

20 2.2. Diseno

En otro caso, la parte superior muestra la informacion mas importan-te sobre el modulo XBee (por este orden): MAC, version hardware,version firmware, protocolo y nombre. A la derecha del nombre unboton permitira al usuario cambiar el nombre del dispositivo median-te un cuadro de dialogo. La parte inferior muestra una lista con losparametros soportados por el dispositivo y sus valores. Los parame-tros modificables podran ser alterados por el usuario seleccionando suvalor e introduciendo uno nuevo. A la izquierda de cada parametroaparecera un icono de ayuda que mostrara informacion adicional so-bre dicho parametro al hacer click en el. La parte inferior izquierda,vacıa al cargar la vista, se utilizara para notificar mensajes al usuario.En la parte inferior derecha se dispondra de dos botones para volvera leer el valor de todos los parametos, y para escribir el valor de losparametros en la memoria no volatil del modulo.

• XBeeNetworkFragment: Esta vista se comporta de modo similar ala anterior si no hay un XBee conectado.

Cuando sı existe conexion con el modulo XBee local, en la parte supe-rior se mostrara una lista de los dispositivos remotos que forman la red.Aparecera vacıa al cargar la vista, y el usuario dispondra de dos boto-nes: uno para realizar un descubrimiento de dispositivos remotos (queseran mostrados en la lista) y otro para limpiar la red. Al seleccionarcualquier dispositivo remoto, la parte inferior se actualizara ofreciendola misma funcionalidad que la parte inferior del LocalXBeeFragment,pero interactuando con el dispositivo remoto seleccionado.

• LogFragment: Se compondra de dos listas: la superior mostrara loseventos relacionados con el cloud connector, la inferior los relacionadoscon el XBee. Los eventos deben comenzar con la hora a la que seprodujeron.

Este fragmento usara la clase de utilidad Logger para acceder a la listade eventos registrados. Tambien utilizara un SchedulerExecutor paraactualizar la vista a intervalos regulares.

AppPreferences

El diseno de AppPreferences es muy sencillo utilizando las herramientasestandar que Android proporciona: para la interfaz grafica se usara una Pre-ferenceActivity que mostrara un unico PreferenceFragment mientras que unfichero xml definira las distintas preferencias, que se muestran a continua-cion:

• Informacion (cabecera de seccion):


– Estado de la conexion a Digi Device Cloud (valor binario, sololectura).

– Device ID (cadena de texto, solo lectura).

– Direccion IP (cadena de texto, solo lectura).

– Version firmware (cadena de texto, solo lectura).

• Preferencias de Digi Device Cloud :

– Nombre del hardware (cadena de texto).

– Descripcion (cadena de texto).

– Vendor ID (cadena de texto).

– Servidor (lista de valores).

– Avanzadas (subseccion, se muestra sobre la vista anterior):

∗ Usar conexion segura (valor binario).

∗ Activar reconexion automatica (valor binario).

∗ Tiempo de reconexion (valor numerico).

∗ Keep alive (valor numerico).

∗ Server keep alive (valor numerico).

∗ Tiempo de espera (valor numerico).

• Preferencias del gateway :

– Subir paquetes de muestras de IO (valor binario).

– Subir paquetes de datos (valor binario).

– Intervalo de subida (entero, en milisegundos).

– Tamano del buffer de paquetes (entero).

Sera necesario tanto un BroadcastReceiver, para recibir notificacionessobre cambios en el estado de las conexiones y mostrarlas al usuario entiempo real, como una referencia al BackgroundService para obtener el valoractual de las distintas preferencias (para obtenerla es necesaria una subclasede ServiceConnection). Tambien se implementara un metodo para obtener elvalor de las preferencias a partir de su nombre usando el BackgroundService.

La figura 2.4 muestra el diagrama de clases de las componentes vistashasta el momento, aunque por claridad no se muestran los objetos de lainterfaz (ListView, Button, TextView, etc), si no lo relevante para la fun-cionalidad de las clases.

22 2.2. Diseno

Figura 2.4: Diagrama de clases simplificado sobre las Activities (se han omi-tido los elementos graficos).


BackgroundService

Esta componente se inicia cuando el dispositivo arranca, y continua en ejecu-cion continuamente5. Es la parte crıtica de la aplicacion ya que de su correctodiseno e implementacion dependen tanto la funcionalidad como la eficien-cia de la aplicacion. La clase BackgroundService extendera de Service y selimitara a implementar los requisitos de un servicio Android. Creara unanotificacion que informe al usuario de que el servicio esta en ejecucion yademas proporcionara un stub6 para permitir que tanto nuestra aplicacioncomo aplicaciones de terceros puedan interactuar con este servicio. Usara condos clases que proporcionan la funcionalidad real que ofrece:

• XBeeManager: Proporcionara una serie de metodos que permitan in-teraccionar con el modulo XBee. Ademas esta interfaz debe ser thread-safe, ya que la librerıa usada no lo es y nuestra aplicacion debera sercapaz de procesar peticiones de distintos hilos (peticiones del usua-rio mediante la interfaz, peticiones recibidas de la nube, eventos delsistema como la desconexion del modulo XBee USB...).

Tambien gestionara el estado de conexion del modulo XBee, mante-niendo consistente y permitiendo consultar el estado actual ası comoinformando mediante intents al sistema de los cambios que se produz-can. Necesitara por tanto un BroadcastReceiver pendiente de eventosde conexion y desconexion del puerto USB del dispositivo. Ademascuenta con atributos serialPort y baudRate, con sus respectivos get-ters y setters, para determinar el modo de conexion con el moduloXBee.

Por ultimo, si el servicio de subida de datos a la nube esta activado, seencargara tanto de escuchar y almacenar los paquetes adecuados pro-venientes de la red XBee como de subirlos a la nube de forma periodica(utilizando el CloudManager que se define en el siguiente punto). Deesta forma se solucionan dos problemas: por una parte disminuimosel trafico de red (resulta mas eficiente subir periodicamente listas dedatapoints que subirlos individualmente segun se reciban) y ademasevitamos que puedan perderse datapoints si la conexion sufre proble-mas puntuales. No obstante, dados los requisitos no funcionales sobreel uso de memoria, existira un tamano maximo de paquetes a almace-nar. Se usara una cola circular que descarte los paquetes mas viejos encaso de llenarse. En resumen, esta es la funcionalidad proporcionada:

5En realidad en Android es imposible garantizar que el proceso estara siempre enejecucion, ya que el sistema operativo podrıa terminarlo abruptamente en casos de extremaescasez de memoria. En cualquier caso si eso llega a suceder el servicio volvera a ser iniciadoen cuanto la carga de procesos lo permita.

6Clase que implementa una interfaz usando un servicio remoto como si fuera local,encargandose de la serializacion y deserializacion de los parametros y valores de retorno ydel envio y recepcion de informacion con el proceso remoto.

24 2.2. Diseno

– Proporcionar interfaz thread-safe para interactuar con el diposit-vo.

– Gestion del estado de la conexion XBee.

– Parte de la implenetacion del servicio de subida de datos desde lared XBee a la nube: escucha y almacenamiento de los paquetes.

• CloudManager: Similar al anterior, gestiona el acceso al CloudCon-nector proporcionado por el Cloud Connector for Android exportandouna intefaz thread-safe.

Permite consultar el estado de conexion, modificarlo y enviar data-points a la nube. Cuenta con una subclase de EventsListener pararesponder a los eventos de conexion producidos por el CloudConnec-tor.

Por otra parte, atiende las peticiones recibidas desde la nube para loque cuenta con un objeto de la clase IAndroidRCIExtension encar-gado de recibir dichas peticiones y contestarlas. Existen dos tipos depeticiones:

– Valor de un parametro: Se recibe una tupla (grupo, setting, ındi-ce, nombre) que identifica el parametro que la nube solicita. Secontesta con un String que contiene el valor correctamente for-mateado.

– Peticion RCI: Se recibe una cadena XML con una peticion mascompleja. La respuesta debe ser un documento XML valido cum-pliendo la especificacion RCI [11].

Para estas ultimas, se utilizara la clase XMLCloudRequestParser queinterpretar la peticion xml y crea un objeto de la clase XBeeRequest(esta clase sera analizada en el apartado 2.2.3) que se encarga de pro-porcionar una repuesta en forma de documento xml. Para procesarambos tipos de peticiones, es necesario utilizar el XBeeManager.

En la figura 2.5 se detalla la estructura de esta parte de la aplicacion.


Figura 2.5: Diagrama de clases sobre la componente BackgroundService.

26 2.2. Diseno

2.2.3 Modelo de datos y clases de utilidad

En este apartado se analizan las clases de utilidad y los distintos modelos im-plementados en la aplicacion. Logicamente tambien se usan continuamenteclases del modelo de datos proporcionadas por las librerıas, como XBeeDe-vice, CloudConnector, XBee64BitAddress, etc.

A continuacion se presentan las clases que han tenido que ser implemen-tadas para modelizar distintos conceptos. Los detalles se proporcionan en lafigura 2.6.

• XBeeRequest: Representa una peticion RCI recibida desde Digi De-vice Cloud que puede o no haber sido procesada (y por tanto contar conla respuesta xml). Para ello almacena los parametros de la peticion,proporciona un metodo para procesarla a partir de un XBeeDevice(que crea la respuesta xml) y permita consultar dicha respuesta xml(si ha sido procesada previamente).

• RCIError: Tipo enumerado que representa los distintos tipos de erro-res que se pueden producir al procesar una peticion RCI.

• RequestException: Excepcion que se produce si ocurre un error RCIal procesar una peticion. Ademas del tipo de error, almacena informa-cion adicional sobre el contexto en el que se produjo.

• XmlElement: Representa un elemento XML de un descriptor. Se usadurante el parseo de una XBeeRequest.

• XBeeProperty: Representa los distintos parametros de un moduloXBee.

• XBeeDataType: Representa los tipos de datos correspondientes avalores de parametros XBee.

• XBeeCapabilities y XBeeInternalProperty: Representan las ca-pacidades y caracterısticas internas de las que dispone un moduloXBee.

Estas cuatro ultimas clases representan modelos mucho mas concretossobre la tecnologıa XBee, por lo que sus valores e interpretaciones resultanmas complejos. No es el objetivo de esta seccion explicarlos pero se puedeconsultar la documentacion proporcionada en la bibliografıa para algunosde ellos (para otros no existe documentacion publica).

La figura 2.6 muestra el diagrama de clases para las clases del modelode datos.


Figura 2.6: Diagrama de clases del modelo de datos.

28 2.3. Implementacion

Ademas se emplearan las siguientes clases de utilidad:

• CircularFifoQueue: Cola circular con tamano establecido que, alllenarse, descarta los elementos mas antiguos. Se utiliza tanto en elregistro de eventos como en el almacenamiento de datapoints.

• FormatHelper: Gestiona las conversiones entre String y byte[] parael intercambio de informacion entre Digi Device Cloud y el moduloXBee.

• Logger: Gestiona el log integrando los distintos sistemas (logging enAndroid, librerıa de logging utilizada por XBee Java Library, y el pro-pio logging de la aplicacion).

• WorkingThreadManager: Singleton que encapsula un ThreadPoo-lExecutor, se usa para realizar tareas lentas evitando bloquear la in-terfaz (se vera con mas detalle en el apartado 2.3.4).

2.3 Implementacion

En esta seccion se documenta la fase de implementacion del proyecto. Enprimer lugar veremos algunos aspectos generales del proyecto para despuescomentar con mas detalle las partes mas interesantes ası como algunos pro-blemas y las soluciones dadas.

2.3.1 Tecnologıas y software empleado durante el desarrollo

En el proceso de desarrollo del proyecto se han empleado varias tecnologıasy software. Por supuesto la principal tecnologıa empleada ha sido Android,para la que se ha programado utilizando Eclipse junto con el plugin ADT(Android Development Kit).

Otra tecnologıa empleada es XML, por un lado como parte del desarrolloAndroid para la definicion de las interfaces graficas, menus de preferencias,cadenas, etc y por otro lado para las comunicaciones con Digi Device Cloud.Esto ultimo incluye el parseo de las peticiones entrantes, la serializacion enxml de sus respuestas, y la creacion de un descriptor XML que informe aDigi Device Cloud de las capacidades de nuestro dispositivo.

Para determinadas partes del codigo (en concreto XBeeProperty.java,XBeeInteralProperty.java, XBeeCapabilities.java y partes del procesamientode peticiones RCI) fue necesario analizar codigo C, en concreto partes delcodigo fuente del ConnectPort X2e7.

Durante las pruebas con redes XBee se utilizo XCTU [14] para la confi-guracion de los distintos modulos.

7Uno de los productos gateway distribuidos por Digi, http://www.digi.com/products/xbee-rf-solutions/gateways/connectportx2ese.

http://www.digi.com/products/xbee-rf-solutions/gateways/connectportx2ese

http://www.digi.com/products/xbee-rf-solutions/gateways/connectportx2ese


Para las modificaciones en el Cloud Connector for Android fue necesarioutilizar tanto el plugin de desarrollo de eclipse para Java ME8 (ya queeste conector esta basado en el de Java SE, que a su vez utiliza un nucleodel conector disenado para dicha plataforma), como Maven para obtener ycompilar estos proyectos y sus dependencias.

Como control de versiones se utilizo un repositorio Git en el sistemaStash9 de la empresa. Git Extensions

Por ultimo para esta memoria se ha empleado Microsoft Visio 2010para los distintos diagramas que aparecen y LaTeX (en concreto TexMakercon el compilador MiKTeX) para el resto del documento.

2.3.2 Librerıas utilizadas

La aplicacion desarrollada se basa en distintas librerıas para la comunicaciontanto con Digi Device Cloud como con el XBee local y su red XBee. Enconcreto estas son las librerıas utilizadas:

• CloudConnectorAndroid.jar: Permite conectar dispositivos con Di-gi Device Cloud. Esta basado en el Cloud Connector for Java SE [12].Durante el desarrollo del proyecto fue necesario realizar modificacio-nes para anadir capacidad de integracion en el logging y actualizar elproyecto tras los ultimos cambios en el Cloud Connector for Java SE.

• XBeeJavaLibrary: XBee Java Library [18] desarrollada por Digi per-mite interaccionar con modulos XBee. En este proyecto se ha utilizadouna version no oficial con soporte para modulos conectados por USB[17].

• slf4j-api.jar: Simple Logging Facade for Java [25] es una liberıa delogging utilizada por XBeeJavaLibrary. Ademas de incluir esta librerıapor ser una dependencia de la anterior, para poder recibir las distintasentradas de logging, en el proyecto creamos una implementacion parapoder integrar el logging generado por esta librerıa con nuestro propiosistema (proporcionado por la clase Logger) para ası poder motrarloen nuestra vista de registro de eventos.

2.3.3 Estructura del proyecto

Al tratarse de un proyecto Android se generan muchos tipos de ficheros, nosolo ficheros .java con el codigo fuente. En esta seccion se muestran todoslos ficheros generados y se explica el uso que se les da.

8Java ME (Micro Edition) es una especificacion de un subconjunto de Java para su usoen dispositivos con menos recursos, como sistemas embebidos.

9Stash es un producto de Atlassian que permite gestionar respositorios Git. Ademassoporta integracion con otros productos de esta companıa como Jira. (https://es.atlassian.com/software/stash)

https://es.atlassian.com/software/stash)

https://es.atlassian.com/software/stash)


La figura 2.7 muestra todos los ficheros con codigo fuente generados consus respectivos paquetes en una estructura similar a la vista en el apartadoanterior (diseno).

Figura 2.7: Ficheros de codigo generados. De izquierda a derecha: paquetede la interfaz grafica, paquete del servicio y clases de utilidad y modelo dedatos. Abajo a la izquierda implementacion de logging para slf4j

El resto de ficheros reciben el nombre de recursos de la aplicacion, y seencuentran clasificados bajo la carpeta res. Las distintas subcarpetas puedentener un sufijo (qualifier) que determina bajo que circunstancia se usan losficheros que contienen. Por ejemplo, la carpeta layout contiene los ficherosxml que definen la disposicion de los elementos en cada vista. Se puedenutilizar otras carpetas como layout-landscape o layout-xxxhdpi que conten-gan ficheros especiales para vistas en modo horizontal o para dispositivoscon alta resolucion, respectivamente10. La figura 2.8 muestra los recursosutilizados en nuestra aplicacion, clasificados de la siguiente manera:

• A la izquierda aparece el contenido de la carpeta drawable, que contie-ne distintos elementos que son dibujados en la interfaz grafica. Los dosprimeros ficheros son documentos XML que definen las caracterısticasde un boton (color de fondo, de texto, tamano, etc y todo ello en fun-

10El sistema de recursos de Android ofrece muchas mas posibilidades que las explica-das aquı brevemente, se puede consultar http://developer.android.com/guide/topics/resources/providing-resources.html.

http://developer.android.com/guide/topics/resources/providing-resources.html

http://developer.android.com/guide/topics/resources/providing-resources.html


cion del estado: habilitado, deshabilitado, pulsado...) mientras que elresto son ficheros png que contienen distintas imagenes.

• En el centro se muestran los ficheros .xml que definen las distintasvistas de la aplicacion.

• En la parte derecha se muestran las distintas librerıas utilizadas (android-support-v4.jar es una librerıa autogenerada para compatibilidad conversiones anteriores de Android).

• La carpeta raw contiene distintos ficheros para su lectura directa porla aplicacion.

– connector config.txt define el valor de algunos parametros delCloud Connector for Android.

– descriptor.xml contiene un descriptor xml con algunos parame-tros XBee que Digi Device Cloud puede solicitar a esta aplicacion.

– xbee descriptors.txt contiene varios descriptores xml que definenlos comandos RCI que nuestra aplicacion puede recibir. Se utili-zan para parsear y verificar las peticiones RCI recibidas.

• La carpeta values contiene distintos ficheros definiendo varios valoresque se utilizan de manera global en la aplicacion, entre ellos

– Colores, estilos y dimensiones de textos empleados, lo que permitemodificar el aspecto de la aplicacion globalmente.

– Cadenas mostradas, facilitando la realizacion de traducciones.

– Listas de opciones, como por ejemplo los baud rates que el usuariopuede elegir cuando configura la conexion con el modulo XBeelocal.

• La carpeta xml contiene el fichero cloud settings.xml, que define laspreferencias de la aplicacion.


Figura 2.8: Otros ficheros generados. De izquierda a derecha y de arribaabajo: imagenes, ficheros xml que definen las distintas vistas, librerıas yotros ficheros.

2.3.4 Ejemplos de implementacion

Dadas las limitaciones de tamano de esta memoria, no es posible detallar laimplementacion realizada de cada funcionalidad. En esta seccion se docu-mentan las mas interesantes.

AIDL

En Android, cada aplicacion se ejecuta en su propio proceso, por lo quecada una tiene su propio espacio de memoria y no puede acceder a los delresto. Para poder comunicarse, es necesario utilizar el sistema operativocomo puente para transferir la informacion.

AIDL [5] (Android Interface Definition Language) permite definir unainterfaz que el servicio implementara y la clase cliente usara de forma quepuedan comunicarse incluso si estan ejecutandose en distintos procesos. Paraello, una de las utilidades distribuidas con el ADT (Android DevelopmentToolkit) se encargara de crear las clases necesarias a partir de un fichero .aidlescrito por el desarrollador, definiendo la interfaz. Estas clases se encargantanto de descomponer los objetos en tipos primitivos, pasarlos de un procesoa otro a traves del sistema operativo y recomponerlos al otro lado; comode sincronizar los hilos que interactuan y otras labores. Despues basta conimplementar la interfaz y exportarla por medio de un servicio para que otrasaplicaciones puedan hacer uso de ella.

La figura 2.9 muestra las distintas clases y la interfaz que se generan a


Figura 2.9: Diagrama de clases que se generan a partir de un fichero .aidl.

partir de un fichero .aidl, usando como ejemplo la interfaz IBackgroundSer-vice:

• Interfaz con el mismo nombre que el fichero .aidl, contiene los mis-mos metodos. Sera usada por el cliente del servicio para acceder a lafuncionalidad.

• Stub: clase abstracta interna a la interfaz anterior. El proveedor delservicio debe definir una clase heredando de esta donde quede imple-mentada la funcionalidad. Ademas proporciona el metodo asInterfa-ce(IBinder) que debe ser usado por el cliente para obtener la interfaza usar.

• Proxy: clase interna a la anterior, encargada de realizar la comunica-cion entre procesos. Internamente cuenta con un IBinder, que es conquien realiza la comunicacion remota. Esta clase nunca es usada di-rectamente por el desarrollador, en su lugar .Stub.asInterface(IBinder)encapsula el IBinder en un .Stub.Proxy solo si la comunicacion entreprocesos es necesaria (el cliente del servicio siempre usa la interfaz delprimer punto).

A pesar de que de esta forma se facilita enormemente la comunicacionentre procesos existen varios problemas:

• No se soportan excepciones.

• Solo se permiten determinados tipos de datos:


– Tipos java primitivos.

– String y CharSequence.

– List y List<String>.

– Map.

– Parcelable (otros tipos pueden implementar esta interfaz parapoder ser usados en AIDL).

• No se soportan tipos parametricos (a excepcion de List<String>).

Desafortunadamente no resulta facil trabajar con AIDL: documentacionincompleta y un compilador AIDL muy rıgido y con diagnosticos de errorpracticamente inexistentes; llegando a generar codigo que no compila a partirde un fichero .aidl que considera valido.

Ademas no hay que olvidar las distintas implicaciones que tiene trabajarentre procesos, entre ellas, referencias a otros objetos que no sean serializadosno son validas, referencias estaticas a atributos refieren a atributos distintos(la clase se carga en cada proceso) y otros contextos que normalmente songlobales dejan de serlo (preferencias Android, otras componentes, ...).

La mayorıa de estos problemas se pudieron solucionar durante la fasede implementacion de una forma u otra, pero una dificultad importante fueno poder usar excepciones. Hay que tener en cuenta que cuando estamosinteraccionando con un dispositivo remoto muchas cosas pueden ir mal, y sise produce algun tipo de error es necesario informar al usuario de que errorse produjo proporcionando toda la informacion posible. Dado que AIDL nopermite usar excepciones, se valoraron distintas alternativas:

• Devolver un boolean indicando si la operacion fue exitosa o no, con-vertir los valores devueltos en parametros de salida.

Esta solucion es la mas facil y rapida de implementar ademas de pro-porcionar un servicio funcional. La gran desventaja es que en caso deproducirse algun error, el usuario no recibe ningun tipo de informacionadicional.

• Utilizar codigos de error. Esta tecnica es utilizada ampliamente entecnologıas que no disponen de excepciones, por ejemplo en muchas li-brerıas C. Es similar a la anterior, pero en lugar de devolver un boolean,se devuelve un valor entero. Por otra parte, se definen un conjunto deconstantes enteras que representan distintos tipos de errores. De estaforma el usuario sabe que tipo de error se produjo.

Esta solucion es mas compleja de implementar, ya que habrıa quedeterminar todos los tipos de excepciones que se pueden producir.Ademas, las excepciones pueden contener una cantidad arbitraria de


informacion11 por lo que puede no ser posible establecer una biyeccionentre estas y los enteros representables. Tampoco hay que olvidar queuna interfaz de este tipo serıa mas difıcil de usar y extrana para otrosdesarrolladores Java.

• Utilizar la excepcion sin usar los mecanismos de lanzado de excepcio-nes, como un tipo mas. Entre estas alternativas estan:

– Devolver la excepcion, o null si no se produce. Esta alternativa nopermite utilizar el valor de retorno como resultado de la llamadade la funcion, por lo que perjudica la semantica de la interfaz ysu facilidad de uso.

– Devolver la excepcion como un parametro de salida (null si nose produce). Una alternativa estrictamente mejor que la anterior,pero que sigue perjudicando la interfaz.

– Utilizar como valor de retorno un tipo que represente el objetoresultado de la funcion o una excepcion con la causa del error.Serıa la solucion ideal si fuera posible utilizar tipos parametri-cos como Optional<T>12, sin embargo las limitaciones de AIDLhacen que se tuviera que emplear algo como Bundle13, lo quetambien perjudica la interfaz.

Todas las alternativas planteadas perjudican la interfaz de un modo uotro, por lo que se escogio la ultima opcion para definir la interfaz peroutilizando otra clase (ServiceAdapter) que se encargara de desencapsularlas excepciones y ası proporcionar una interfaz mas limpia. Esto tambiennos permite exponer los parametros adecuados para los tipos parametricoscomo List y Map.

A continuacion se muestra el codigo usado para escribir y leer las ex-cepciones a traves de un Bundle. Escribir y leer excepciones serializables noresulta complicado, pero el codigo tambien es capaz de transmitir el tipo ymensaje correcto para excepciones no serializables. Todos los metodos delservicio tienen una estructura similar: se crea un Bundle vacıo y se anade elresultado del metodo, si alguna excepcion ocurre se captura y se almacenaen el Bundle; por ultimo se devuelve dicho objeto:

public Bundle xBeeGetLocalParameters(List<String> params)

throws RemoteException {

Bundle retValue = new Bundle();

11Por ejemplo, una excepcion desde Digi Device Cloud podrıa encapsular un documentoxml con una descripcion del error.

12Esta clase esta disponible a partir de Java 8, pero un contenedor con la misma semanti-ca para nuestros propositos resulta facil de implementar, de hecho fue implementado du-rante la realizacion de este proyecto aunque termino in darsele uso.

13Representa un envoltorio que contiene distintos objetos Parcelables identificados porString, http://developer.android.com/reference/android/os/Bundle.html.

http://developer.android.com/reference/android/os/Bundle.html


Figura 2.10: Flujo de informacion para comunicar dos componentes en pro-cesos distintos.

try {

ArrayList<byte[]> value = xbeeManager.getLocalParameters(params);

retValue.putSerializable(EXTRA_VALUE, value);

} catch (Exception e) {

writeException(retValue, e);

}

return retValue;

}

private static void writeException(Bundle bundle, Exception exception) {

bundle.putString(EXTRA_EXCEPTION, exception.getClass().getName());

bundle.putString(EXTRA_EXCEPTION_MSG, exception.getMessage());

try {

bundle.putSerializable(EXTRA_EXCEPTION_DATA, exception);

} catch (Exception ignored) {}

}

Durante la lectura se recupera el tipo parametrico correcto mediante uncast ya que el lenguaje no es capaz de recordar el tipo en tiempo de compila-cion. Por tanto es responsabilidad del desarrollador del servicio realizar lasconversiones adecuadamente, sin embargo el desarrollador de la aplicacionque usa nuestro servicio no se tiene que preocupar de nada, que es el objetivoprincipal. Tambien se recupera la excepcion de la mejor forma posible:

@SuppressWarnings("unchecked")

public List<byte[]> xBeeGetLocalParameters(List<String> params)

throws Exception {

Bundle value = backgroundService.xBeeGetLocalParameters(params);

checkException(value);

return (List<byte[]>) value.getSerializable(EXTRA_VALUE);

}

private static void checkException(Bundle bundle) throws Exception {

String exceptionClassName = bundle.getString(EXTRA_EXCEPTION);

if (exceptionClassName != null) {

String exceptionDescription = bundle.getString(EXTRA_EXCEPTION_MSG);

Exception toThrow;


try {

// Try to get the whole exception

toThrow = (Exception) bundle.getSerializable(EXTRA_EXCEPTION_DATA);


try {

// Try to get the right type and description

Class<?> exceptionClass = Class.forName(exceptionClassName);

Constructor<?> c = exceptionClass.

getDeclaredConstructor(String.class);

toThrow = (Exception) c.newInstance(exceptionDescription);

} catch (Exception e2) {

// At least throw something!

toThrow = new RuntimeException("(" +

exceptionClassName + ") " + exceptionDescription);

}

}

throw toThrow;

}

}

Otro de los problemas surge cunado es necesario utilizar tipos distintos alos soportados por AIDL. La solucion ofrecida por esta tecnologıa es adaptarnuestros tipos para que sean compatibles con AIDL, para lo que solo hacefalta implementar la interfaz Parcelable14. Esto soluciona el problema paralos tipos que nosotros definimos pero no es de ayuda a la hora de usar tiposde terceros, por ejemplo tipos definidos en las librerıas que usamos comoXBeeRemoteDevice, XBee64BitAddress, IOSample, etc. Se han usado lassiguientes soluciones para este problema:

• Los tipos suficientemente simples pueden ser sustituidos por tipos di-rectamente soportados en AIDL. Por ejemplo XBee64BitAddress (querepresenta una direccion de 64 bits de un modulo XBee) puede sersustituido por el tipo String: basta con usar el metodo toString() y elconstructor XBee64BitAddress(String) para realizar las conversiones.Otros tipos mas complejos como XBeeRemoteDevice pueden ser a ve-ces sustituidos por otro tipo que representa menos informacion, comoXBee64BitAddress (y este a su vez por String); aunque esto dependede la semantica de cada metodo.

• Para otros tipos mas complejos, como escuchadores, se puede utilizarel patron Adapter disenando una clase contenedor.

14En realidad ademas de implementar dicha interfaz es necesario crear una cla-se interna como se detalla en http://developer.android.com/reference/android/os/

Parcelable.html.Otro requisito imprescindible si el tipo se usa con direccion out o inout en la interfaz

AIDL y que no aparece documentado es la implementacion del metodo void readFrom-Parcel(Parcel).

http://developer.android.com/reference/android/os/Parcelable.html

http://developer.android.com/reference/android/os/Parcelable.html


Figura 2.11: Ejemplo del esquema seguido para adaptar los escuchadorespudiendo usarlos con AIDL.

La figura 2.11 muestra el esquema seguido para utilizar los escuchadorescon AIDL. En verde se muestra el escuchador proporcionado por la librerıa.A su derecha la interfaz equivalente que se crea para ser usada medianteAIDL. En la parte inferior aparece la clase implementada para adaptar lainterfaz que se usa con AIDL de forma que pueda ser usada por la librerıa.A continuacion presentamos la implementacion del unico metodo de dichaclase:

public void ioSampleReceived(RemoteXBeeDevice remoteDevice,

IOSample sample) {

byte[] samplePayload;

// Hack using reflection to get the private field with the payload

// TODO: Get a real implementation (compute the payload back

// from the getters or wait for library update)

try {

Field f = IOSample.class.getDeclaredField("ioSamplePayload");

f.setAccessible(true);

samplePayload = (byte[]) f.get(sample);


// If reflection fails, nothing can be done yet...

samplePayload = null;

}

try {

listener.ioSampleReceived(remoteDevice.get64BitAddress().toString(),

samplePayload);

} catch (RemoteException e) {

Logger.w(TAG, "IPC failed, event lost: ioSampleReceived:"

+ remoteDevice + ",", e);

}

}

Se ha elegido este de entre los distintos wrappers implementados por serel mas problematico. Como se aprecia en la implementacion del metodo, launica labor es realizar la transformacion de tipos y llamar al escuchadorencapsulado. Sin embargo en este caso la librerıa no proporciona metodos


para obtener el payload15 del paquete recibido. Este problema sera solucio-nado con la siguiente version de la librerıa que incorporara un getter paraese campo. Mientras tanto, la solucion pasa por romper la encapsulacionproporcionada por Java y obtener el campo privado directamente usandoreflexion16.

XML

Como hemos visto, en varios momentos la aplicacion interactua con docu-mentos XML. Vamos a detallar como se ha realizado el proceso de lectura delos ficheros descriptores, por ser algo mas complejo (el caso de las peticionesRCI es muy parecido).

El fichero de descriptores se lee una unica vez durante el inicio de laaplicacion, almacenando los descriptores de los distintos comandos RCI en-contrados en memoria que luego son usados durante la lectura de peticionesRCI. Es deseable minimizar el coste de esta operacion, tanto en operacionescomo en memoria requerida. Ademas no es necesario modificar este fiche-ro ni conservar el arbol DOM para ningun otro proposito. Por todos estosmotivos, se decide utilizar XmlPullParser. Ademas de esta forma se com-plementa la formacion recibida en la universidad, donde se ha usado XMLmediante arboles DOM en la mayorıa de asignaturas.

A traves de esta clase, podemos ir leyendo el fichero y generando nosotrosmismos las clases adecuadas para su representacion. Los principales metodosa usar son:

• int next(): Avanza hasta el siguiente evento de lectura y devuelve unentero que identifica el estado actual en el que se encuentra el Xml-PullParser. Los mas usados son START DOCUMENT, START TAG,TEXT, END TAG, END TAG.

• String getTag(): Devuelve el nombre del tag en el que se encuentra elparser. Solo es valido si el estado actual es START TAG o END TAG(en otro caso lanza una excepcion).

• String getAttributeName(int index) y int getAttributeCount():Devuelven el nombre de un atributo y el numero de atributos del tagactual, respectivamente. Solo son validos si el parser se encuentra enel estado START TAG.

• String text(): Devuelve el nodo de texto actual. Solo es valido en elestado TEXT.

15El payload o carga util es la parte del paquete que contiene la informacion que sedesea transmitir (sin las cabeceras ni otras informaciones sobre el propio paquete).

16La reflexion es la capacidad de un programa para examinar y modificar su estructuray comportamiento durante la ejecucion.


Las construcciones utilizando esta clase suelen tener la siguiente estruc-tura:

• Un bucle que ejecuta su cuerpo hasta que se ha procesado el elemen-to activo completamente. Para ello se puede usar un contador de laprofundidad en la que nos encontramos, incrementandolo y decremen-tandolo en los comienzos y fines de etiquetas respectivamente.

• Una llamada a next(), que continua con el procesamiento del docu-mento XML.

• En funcion del estado devuelto por la llamada anterior, se actua deuna forma u otra. En comienzo de elemento, se suele preguntar elnombre y posiblemente atributos, si el estado es TEXT, es probableque queramos guardar el texto contenido en dicho nodo, etc.

Por ejemplo, el siguiente fragmento de codigo avanza un elemento com-pleto (se utiliza frecuentemente durante el procesamiento del fichero de des-criptores, ya que muchos elementos no son de nuestro interes):

protected static void skipCurrentTag(XmlPullParser parser)

throws XmlPullParserException, IOException {

if (parser.getEventType() != XmlPullParser.START_TAG) {

throw new IllegalStateException();

}

String tagName = parser.getName();

int depth = 1;

while (depth > 0) {

switch (parser.next()) {

case XmlPullParser.END_TAG:

depth--;

break;

case XmlPullParser.START_TAG:

depth++;

break;

}

}

parser.require(XmlPullParser.END_TAG, null, tagName);

}

Un ejemplo algo mas complejo es el codigo que se emplea para leer elfichero de descriptores. Cada descriptor es leıdo por el metodo Descrip-tor.parseFromXml, que contiene codigo parecido, obteniendo el nombre dedistintos atributos y subelementos.

El fichero de descriptores contiene en primer lugar descriptores vacıosque contienen el nombre de comandos do command17, que son almacenados

17Uno de los permitidos por RCI, se pueden consultar detalles en la documentacion,apartado 3.8 [11].


en un Map<String, Descriptor> con claves nulas, utilizandolo como si fueraun Set<String>. Mas adelante durante el fichero se situan los descriptoresde cada comando, y son incorporados al mapa.

private void readDescriptors() throws XmlPullParserException, IOException {

(...)

parser.setInput(descriptorsStream, null);

int eventType = parser.getEventType();

while (eventType != XmlPullParser.END_DOCUMENT) {

if(eventType == XmlPullParser.START_TAG) {

String tag = parser.getName();

if (tag.equals(Descriptor.XML_TAG)) {

Descriptor descriptor = Descriptor.parseFromXml(parser);

String dName = descriptor.getName();

if (dName == null) {

/* Unknown descriptor, skip */

} else if (dName.equals(XML_DO_COMMAND_ELEMENT)) {

/* Contains the name of the commands.

* Add the commands to commandDescriptors with null descriptors.

* Actual descriptors will be added later on.

*/

Attribute target = descriptor.getFirstAttribute("target");

if (target != null) {

for (Descriptor d : target.getDescriptors()) {

String commandName = d.getName();

if (commandName != null) {

Logger.d(TAG, "Read command: " + commandName);

commandDescriptors.put(d.getName(), null);

}

}

for (ErrorDescriptor errorDesc : target.getErrorDescriptors()) {

errorDescriptors.put(errorDesc.getName(), errorDesc);

}

}

} else if (commandDescriptors.containsKey(dName)) {

/* Descriptor for a read command.

* Map the command to its descriptor. */

commandDescriptors.put(dName, descriptor);

}

}

}

eventType = parser.next();

}

Multithreading e hilo principal

Android es un sistema operativo multihilo en el que varias aplicaciones consus respectivos procesos y uno o mas hilos en cada una se ejecutan al mismotiempo. Sin embargo existe un hilo de gran importancia: cuando una compo-nente de aplicacion se inicia y la aplicacion no tiene ninguna otra componenteen ejecuccion, el sistema Android comienza un nuevo proceso Linux con un


unico hilo. Este se conoce como hilo principal o hilo de la interfaz (mainthread, UI thread) y es el encargado de procesar todos los eventos asociadosa la interfaz, como dibujado de vistas y llamadas a callbacks registrados envistas.

Para garantizar un uso correcto del sistema android, y por tanto unaexperiencia de navegacion fluida y correccion en las interacciones con lainterfaz, basta cumplir dos reglas:

i. No bloquear ni realizar tareas de largo tiempo de ejecucion en el hiloprincipal.

ii. No interactuar con elementos de la interfaz desde un hilo que no seael principal.

Sin embargo una interaccion con el usuario habitual sigue el siguienteesquema:

1. El usuario solicita iniciar una operacion.

2. La operacion (posiblemente costosa de realizar) comienza.

3. La operacion termina y se notifica al usuario.

Observar que del paso 1 al 2 es necesario usar un hilo distinto al principalpara comenzar la ejecucion de la tarea, ya que de otra forma estarıamosviolando la regla i, de la misma forma del paso 2 al 3 es necesario que seael hilo principal (y no el que estaba realizando la tarea) quien notifique alusuario, si no violarıamos la regla ii.

Para este tipo de flujos tan habituales y con esa problematica, Androidproporciona la clase AsynTask que proporciona tres metodos (uno para pre-parar la ejecucion de la tarea, otro para realizarla, y el ultimo para notificara la interfaz) que son llamados desde el hilo correcto, facilitando la tareaal desarrollador. Sin embargo se ha optado por no utilizarla debido a losiguiente:

• Las interacciones no siempre corresponden con el esquema presenta-do: a veces es necesario notificar a la interfaz varias veces durante elproceso de una tarea, otras veces distintas tareas interaccionan entreellas, tambien ocurre que el comienzo de la tarea es debido a un eventono relacionado con la interfaz grafica, etc.

• AsynTask utiliza un hilo para cada tarea, lo que resulta adecuado parala gran mayorıa de ocasiones. Sin embargo en entornos con mayorconcurrencia (nuestra aplicacion procesa eventos recibidos desde lainterfaz grafica, desde la nube y desde la red XBee concurentemente)la eficiencia cobra mayor importancia y existen mejores alternativas,como un pool de hilos.


¿Como mover trabajo del hilo principal a otro hilo o viceversa? Pa-ra ejecutar una tarea en el hilo principal, existen varias alternativas, comoView.post(Runnable) o Activity.runOnUiThread(Runnable) (basicamente equi-valentes, aunque el ultimo es mas eficiente si se llama desde el hilo principal).Tambien se puede usar un Handler18 asociado al hilo principal.

Para ejecutar una tarea en un hilo distinto al principal se utilizan las mis-mas tecnicas que en cualquier otro entorno Java. Las mas basicas consistenen crear un nuevo hilo y ejecutar ahı la tarea (new Thread(Runnable).start())o utilizar algun tipo de Executor.

Antes de ver ejemplos de codigo del proyecto donde es necesario teneren cuenta todo lo explicado presentamos la implementacion de la clase deutilidad WorkingThreadManager. Se ha utilizado un tipo enumerado paraimplementar el patron singleton. La clase simplemente envuelve un Thread-PoolExecutor creado convenientemente: utiliza entre N y 2N hilos, dondeN es el numero de nucleos disponibles (hay que tener en cuenta que estoshilos pasan gran parte del tiempo realizando operaciones I/O, luego se pue-de superar el numero de nucleos disponibles para maximizar la eficiencia)y una LinkedBlockingQueue (es necesario que la cola bloqueante utilizadanunca bloquee la operacion de encolar, de otra forma el hilo principal podrıaquedar bloqueado y violarıamos la regla i).

public enum WorkingThreadManager {

INSTANCE;

private int NUMBER_OF_CORES = Runtime.getRuntime()

.availableProcessors();

private final int KEEP_ALIVE_TIME = 1;

private final TimeUnit KEEP_ALIVE_TIME_UNIT = TimeUnit.SECONDS;

private final BlockingQueue<Runnable> workQueue =

new LinkedBlockingQueue<>();

private final ThreadPoolExecutor threadPoolExecutor =

new ThreadPoolExecutor(

NUMBER_OF_CORES, // Initial pool size

2*NUMBER_OF_CORES, // Max pool size

KEEP_ALIVE_TIME,

KEEP_ALIVE_TIME_UNIT,

workQueue);

WorkingThreadManager() {

Logger.i(TAG, "WorkingThreadManager running,

using " + NUMBER_OF_CORES + " cores.");

}

public ThreadPoolExecutor getExecutor() {

return threadPoolExecutor;

}

18Un Handler se asocia a un hilo y mediante sus metodos se le pueden enviar mensajesdesde cualquier otro hilo para que sean ejecutados tan pronto como sea posible, o planifi-cados para que sean ejecutados mas tarde (http://developer.android.com/reference/android/os/Handler.html).

http://developer.android.com/reference/android/os/Handler.html

http://developer.android.com/reference/android/os/Handler.html


public void run(Runnable r) {

getExecutor().submit(r);

}

}

Como ejemplo se muestra el codigo que se ejecuta como respuesta cuan-do el usuario modifica uno de los parametros mostrados en una lista deparametros (en la parte inferior de la segunda o tercera vista). Este codigocomienza su ejecucion en el hilo principal (al ser la respuesta a un evento dela interfaz grafica), comienza la tarea en un hilo trabajador del pool de hilosy cuando esta termina notifica el resultado al usuario mediante un Handlerasociado a la interfaz.

public void onParamRead(XBeeProperty property, String newValue,

final int position) {

try {

final byte[] value = property.getDataType().toBytes(newValue);

final String param = property.getAtCommand();

WorkingThreadManager.INSTANCE.run(

new Runnable() {

public void run() {

try {

getBackgroundService().

xBeeSetParameter(getAddr(), param, value);

handler.obtainMessage(

ACTION_PARAM_WRITTEN,

new ParamUpdateInfo(position, value)

).sendToTarget();


handler.obtainMessage(ACTION_ERROR, e).sendToTarget();

}

}

});

} catch (IllegalArgumentException e) {

handler.obtainMessage(ACTION_ERROR, e).sendToTarget();

}

}

});

Interfaz grafica

Android permite definir las vistas mediante documentos XML, donde cadaelemento xml es un elemento grafico y los atributos permiten definir el ta-mano que ocupan, la alineacion, margenes, etc. La forma en la que se anidanlos elementos xml definen la relacion contenido/contenedor de los elementosgraficos. A continuacion se muestra a modo de ejemplo el documento xmlque define cada una de las filas de la lista de parametros de un XBee:

<?xml version="1.0" encoding="utf-8"?>

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"

android:layout_width="match_parent"

android:layout_height="match_parent"

android:padding="5dp" >

<ImageView

android:id="@+id/help_image"

android:layout_width="0px"

android:layout_weight="5"

android:layout_height="30dp"

android:src="@drawable/help" />

<TextView

android:id="@+id/setting_name"



android:layout_height="wrap_content"

android:textColor="@color/DarkGray"

android:textStyle="bold"

android:textSize="18dp"

android:labelFor="@+id/setting_value"/>



<EditText

android:id = "@+id/setting_value"



android:layout_height="wrap_content"


android:focusable="false"/>

<TextView

android:id="@+id/units"



android:paddingLeft="15dp"


android:layout_height="wrap_content"/>

</LinearLayout>

Ademas de las cuatro vistas que se muestran en la imagen 2.12 otros ele-mentos graficos son los cuadros de dialogo ChangeNameDialog, ReadParam-Dialog, XBeeConnectionDialog y XBeePropertyInfo. Tambien fue necesariocrear la clase StringCheckBoxPreference que hereda de la proporcionadapor Android CheckBoxPreference y la unica funcionalidad que anade es quepermite consultar el valor como una String con valores True/False. Esto fuenecesario dado que el Cloud Connector for Android lee directamente la pre-ferencia como una String. La interfaz grafica de la vista de preferencias esgenerada por Android automaticamente a partir del fichero de definicion depreferencias.


Figura 2.12: Interfaz grafica mostrada por la aplicacion.


Todas las imagenes de la aplicacion fueron proporcionadas por Diego yDavid, algunas adquiridas de otros proyectos de la empresa (principalmentedel XCTU) y otras creadas para este proyecto.

2.4 Pruebas

En los dos siguientes apartados se describen las pruebas realizadas duranteel desarrollo del proyecto.

2.4.1 Pruebas unitarias

Las pruebas unitarias se realizaron por el propio desarrollador segun se com-pletaba cada funcionalidad. A continuacion se muestra un ejemplo de laspruebas realizadas en las que se encontro un error.

Prueba Lectura de parametrosDescripcion Lectura de distintos parametros del XBee local.Resultado Todos los parametros se leen correctamente, salvo DH/DL que no

es reconocido. INCORRECTOComentarios El problema ha sido resuelto.

El problema estaba causado por el parametro DH/DL. En realidad esun par de parametros (DH y DL, Destination Adrress High/Low) que repre-sentan una direccion de 64 bits de un dispositivo, almacenando los 32 bitssuperiores en DH y los 32 inferiores en DL. En los descriptores y en generalde cara a Digi Device Cloud, es unico parametro cuyo comando AT asociadoes DH/DL. En realidad el comando AT DH/DL no es valido, y para leer omodificar el valor es necesario utilizar dos comandos AT (DH y DL). Parasolucionarlo se implemento un metodo que llama al metodo ofrecido por lalibrerıa en la mayor parte de casos pero tambien contempla este caso especial(ademas, utiliza una cache para dispositivos remotos).

private byte[] getParam(XBee64BitAddress addr, String param)

throws XBeeException, IllegalArgumentException {

byte[] value = null;

AbstractXBeeDevice target = getTarget(addr);

if (param.length() == 2) {

value = target.getParameter(param);

} else if ("DH/DL".equals(param)) {

byte[] highPart = target.getParameter("DH");

byte[] lowPart = target.getParameter("DL");

byte[] total = new byte[highPart.length + lowPart.length];

System.arraycopy(highPart, 0, total, 0, highPart.length);

System.arraycopy(lowPart, 0, total, highPart.length, lowPart.length);

value = total;

} else {

throw new IllegalArgumentException("Unknown parameter: " + param);

}

48 2.4. Pruebas

return value;

}

2.4.2 Pruebas de integracion

En la fase final del proyecto se realizo una prueba de integracion para verifi-car el correcto funcionamiento de toda la aplicacion. Se utilizo una red XBeeformada por ocho modulos incluyendo el conectado al dispositivo Android,una cuenta en el servidor de pruebas (test.idigi.com) y otra en el servidorestadounidense; y los siguientes dispositivos Android:

• Samsung Galaxy S3 (movil).

• Motorola Moto G (movil).

• ConnectCore 6 SBD (single board computer).

• Asus 7”(tablet).

Durante las pruebas se activo el servicio de subida de datos, tanto depaquetes con muestreo IO como paquetes de datos, y se configuraron dosmodulos XBee remotos para emitir paquetes a la red a intervalos de 1.5segundos. De forma concurrente, se realizaron peticiones XML desde la nubey se realizaron lecturas y modificaciones de algunos parametros mediante lainterfaz grafica.

La mayorıa de las funciones respondieron correctamente. Se encontrarony solucionaron problemas al intentar iniciar el descubrimiento de dispositi-vos remotos en la red mediante una peticion XML si el descubrimiento seencontraba en ejecucion por haberlo iniciado desde la interfaz grafica. Tam-bien se solucionaron errores de inconsistencia de la informacion mostradapor la interfaz al realizar algunas tareas mientras la interfaz grafica estabaen segundo plano.

Capıtulo 3

Conclusiones

De cara al cliente se considera que el proyecto cumple con los objetivos pro-puestos. Se ha desarrollado una aplicacion Android que permite dispositivosAndroid hacer las funciones de un XBee Gateway con un comportamientosimilar. El producto cumple todos los objetivos listados en la seccion 1.2 .Diego y David han expresado su satisfaccion con la aplicacion desarrollada.

El alumno considera la experiencia muy positiva. No solo se han apren-dido y utilizado varias tecnologıas (XBee, Digi Device Cloud, Android...) enlas que no se contaba ninguna experiencia previa, si no que se ha disenadoe implementado una aplicacion que las integra. Por tanto se considera queeste proyecto muestra de forma integrada las competencias y conocimientosadquiridos durante el grado, cumpliendo ası con lo esperado de un TrabajoFin de Grado.

3.1 Propuesta de mejoras

Existen muchas posibles mejoras para este proyecto, acercando la funciona-lidad de la aplicacion a la de un XBee Gateway o la del software XCTUpara la interaccion con dispositivos XBee. Algunas de ellas son:

• Permitir actualizar el firmware de dispositivos XBee locales y remotos.

• Contar con una base de datos que permita identificar el modulo XBeeconectado, lo que permite conocer los parametros y rangos de valoresvalidos para ese dispositivo, y mostrar informacion mas concreta alusuario.

• Permitir a terceras aplicaciones android recibir peticiones desde la nu-be y actuar en consecuencia.

• Generar notificaciones Android ante distintos eventos configurablespor el usuario, tanto paquetes desde la red XBee como peticiones desdela nube.

49

50 3.2. Agradecimientos

• Permitir la ejecucion de parametros arbitrarios en el XBee local y enlos remotos.

3.2 Agradecimientos

Agradezco a Digi International y sus empleados por integrarme en la oficinadesde el primer dıa, tratandome como a un empleado mas y por proporcio-narme todos los recursos necesarios para la realizacion del proyecto (modulosXBee, conectores especıficos para mi movil, diversos dispositivos Android,...).

En especial, me gustarıa dar las gracias a David y Diego por la propuestade un proyecto tan interesante, por los distintos trainings recibidos a lolargo de mi estancia en Digi y por su labor como tutores: confiando en miy dejandome enfrentarme y solucionar los diversos problemas que surgıanpero tambien aportando soluciones efectivas cuando lo he necesitado.

Por ultimo agradezco a Juanjo su labor como tutor desde la universidad,asegurandose de que el Trabajo Fin de Grado seguıa el ritmo correcto du-rante su desarrollo y proporcionando correcciones y sugerencias sobre estamemoria.

Referencias

[1] E. Burnette, Hello, Android.

[2] J. Steele, N. To, The Android Developer’s Cookbook.

[3] S. Hashimi, S. Komatineni, D. MacLean, Pro Android 2.

[4] Documentacion oficial Android, http://developer.android.com/

index.html

[5] Android Interface Definition Language (AIDL), http://developer.

android.com/guide/components/aidl.html

[6] Documentacion oficial del modo USB Host de Android,https://developer.android.com/guide/topics/connectivity/

usb/host.html

[7] Documentacion sobre Digi Device Cloud, http://ftp1.digi.com/

support/documentation/html/90001150/Current/Default.htm

[8] Documentacion sobre Etherios Device Cloud, http://ftp1.digi.com/support/documentation/html/90001415/90001415-13_A/index.

html

[9] Digi Device Cloud Europe, https://devicecloud-uk.digi.com/

login.do

[10] Digi Device Cloud United States, https://devicecloud.digi.com/

login.do

[11] Documentacion RCI (Device Cloud by Etherios), http://ftp1.digi.com/support/documentation/90000569_G.pdf

[12] Cloud Connector for Java SE, http://ftp1.digi.com/support/

documentation/html/90001415/90001415-13_A/index.html

[13] Conceptos basicos XBee y Zigbee, http://ftp1.digi.com/

support/documentation/html/90001399/90001399_A/Files/

XBee-concepts.html

51

http://developer.android.com/index.html

http://developer.android.com/index.html

http://developer.android.com/guide/components/aidl.html

http://developer.android.com/guide/components/aidl.html

https://developer.android.com/guide/topics/connectivity/usb/host.html

https://developer.android.com/guide/topics/connectivity/usb/host.html

http://ftp1.digi.com/support/documentation/html/90001150/Current/Default.htm

http://ftp1.digi.com/support/documentation/html/90001150/Current/Default.htm

http://ftp1.digi.com/support/documentation/html/90001415/90001415-13_A/index.html



https://devicecloud-uk.digi.com/login.do

https://devicecloud-uk.digi.com/login.do

https://devicecloud.digi.com/login.do

https://devicecloud.digi.com/login.do

http://ftp1.digi.com/support/documentation/90000569_G.pdf

http://ftp1.digi.com/support/documentation/90000569_G.pdf



http://ftp1.digi.com/support/documentation/html/90001399/90001399_A/Files/XBee-concepts.html



52 Referencias

[14] XCTU, urlhttp://www.digi.com/products/xbee-rf-solutions/xctu-software/xctu

[15] Tabla de referencia para comandos XBee, http://examples.digi.

com/wp-content/uploads/2012/07/XBee_ZB_ZigBee_AT_Commands.

pdf

[16] XBee ZigBee Gateway de Digi, http://www.digi.com/products/

wireless-routers-gateways/gateways/xbee-gateway#overview

[17] XBee Java Library (rama con soporte USB), https://github.com/

digidotcom/XBeeJavaLibrary/tree/android_support

[18] Documentacion de XBee Java Library, https://docs.digi.com/

display/XBJLIB/XBee+Java+Library

[19] XBee para monotorizar incendencios en entornos difıci-les, http://www.digi.com/learningcenter/stories/

xbee-helps-libelium-monitor-harsh-environments

[20] XBee en sistemas de riego http://www.digi.com/industries/

industrial/precision-agriculture

[21] XBee en automatizacion de manufacturazion, http://www.digi.com/industries/industrial/manufacturing-automation

[22] XBee en energıas renovables, http://www.digi.com/industries/

energy/renewable-energy

[23] XBee en tratamiento de aguas, http://www.digi.com/industries/

government/water-waste-water

[24] Ejemplos sencillos de uso de XBee, http://examples.digi.com/

[25] Simple Logging Facade for Java (SLF4J), http://www.slf4j.org/

http://examples.digi.com/wp-content/uploads/2012/07/XBee_ZB_ZigBee_AT_Commands.pdf



http://www.digi.com/products/wireless-routers-gateways/gateways/xbee-gateway#overview

http://www.digi.com/products/wireless-routers-gateways/gateways/xbee-gateway#overview

https://github.com/digidotcom/XBeeJavaLibrary/tree/android_support

https://github.com/digidotcom/XBeeJavaLibrary/tree/android_support

https://docs.digi.com/display/XBJLIB/XBee+Java+Library

https://docs.digi.com/display/XBJLIB/XBee+Java+Library

http://www.digi.com/learningcenter/stories/xbee-helps-libelium-monitor-harsh-environments

http://www.digi.com/learningcenter/stories/xbee-helps-libelium-monitor-harsh-environments

http://www.digi.com/industries/industrial/precision-agriculture

http://www.digi.com/industries/industrial/precision-agriculture

http://www.digi.com/industries/industrial/manufacturing-automation

http://www.digi.com/industries/industrial/manufacturing-automation

http://www.digi.com/industries/energy/renewable-energy

http://www.digi.com/industries/energy/renewable-energy

http://www.digi.com/industries/government/water-waste-water

http://www.digi.com/industries/government/water-waste-water

http://examples.digi.com/

http://www.slf4j.org/

diseño e implementación de una aplicación android para ... · diofrecuencia capaces de crear...

Documents