David García Romero

Diseño e implementación de extensiones en Eclipse parala optimización del desarrollo software en sistemas

embebidos de 32 bits bajo Android

Angel Luis Rubio García

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Proyecto Fin de Carrera

Matemáticas y Computación

2012-2013

Título

Autor/es

Director/es

Facultad

Titulación

Departamento

PROYECTO FIN DE CARRERA

Curso Académico

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

publicaciones.unirioja.esE-mail: publicaciones@unirioja.es

Diseño e implementación de extensiones en Eclipse para la optimización del desarrollo software en sistemas embebidos de 32 bits bajo Android, proyecto fin

de carrerade David García Romero, dirigido por Angel Luis Rubio García (publicado por la

Universidad de La Rioja), se difunde bajo una LicenciaCreative 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.

1

Agradecimientos

Quisiera dar la gracias a todos los que han hecho posible este proyecto.

Gracias a D. Ángel Luis Rubio por aconsejarme y apoyarme a pesar de mi falta de constancia.

Gracias a Digi International Spain S.A por darme la oportunidad de llevar a cabo este proyecto

con ellos y tratarme como a uno más y en especial a D. David Escalona, sin cuya ayuda, este

proyecto no habría llegado a buen fin.

Gracias también a todos lo que, contra todo pronóstico, han confiado en que este día llegaría.

Muchas gracias a todos.

2

Índice de contenido

1. Introducción ...................................................................................................................... 8

2. Documento de objetivos del proyecto ............................................................................... 9

2.1. Antecedentes ............................................................................................................ 9

2.1.1. Productos previos ............................................................................................ 10

2.2. Objetivos ................................................................................................................. 10

2.3. Entregables.............................................................................................................. 11

2.4. Alcance .................................................................................................................... 11

2.5. Metodología y ciclo de vida ..................................................................................... 11

2.6. Planificación ............................................................................................................ 11

2.6.1. Estructura de descomposición del proyecto (EDP) ............................................ 12

2.6.2. Duración estimada del proyecto....................................................................... 14

2.7. Plan de riesgos......................................................................................................... 15

2.7.1. Cancelación del proyecto ................................................................................. 15

2.7.2. Falta de formación o conocimientos necesarios ............................................... 16

2.7.3. Mala elección de herramientas ........................................................................ 16

2.7.4. Pérdida de datos .............................................................................................. 17

2.7.5. Errores en la planificación ................................................................................ 17

2.7.6. Cambios en los requisitos ................................................................................. 17

2.7.7. Errores en el diseño ......................................................................................... 18

2.7.8. Problemas de disponibilidad del alumno .......................................................... 18

2.7.9. Disconformidad del cliente con el producto resultante .................................... 18

2.8. Tecnologías y herramientas utilizadas y costes de las mismas .................................. 19

2.8.1. Eclipse ............................................................................................................. 19

2.8.2. Java.................................................................................................................. 19

2.8.3. ADT (Android Development Tools) ................................................................... 20

2.9. Arquitectura del producto ....................................................................................... 20

2.9.1. Presentación .................................................................................................... 20

2.9.2. Lógica de negocio............................................................................................. 20

2.9.3. Persistencia...................................................................................................... 21

3. Análisis ............................................................................................................................ 22

3.1. Especificación de requisitos ..................................................................................... 22

3.1.1. Requisitos no funcionales................................................................................. 22

3.1.2. Requisitos funcionales ..................................................................................... 22

3

3.1.2.1 Crear proyecto Android ................................................................................ 24

3.1.2.2 Crear proyecto de ejemplo Android.............................................................. 25

3.1.2.3 Visualizar dispositivos disponibles ................................................................ 25

3.1.2.4 Añadir dispositivo......................................................................................... 26

3.1.2.5 Editar dispositivo.......................................................................................... 26

3.1.2.6 Eliminar dispositivo ...................................................................................... 27

3.1.2.7 Conectar dispositivo ..................................................................................... 27

3.1.2.8 Desconectar dispositivo ............................................................................... 28

3.1.2.9 Instalar aplicación en el dispositivo .............................................................. 28

3.1.2.10 Tomar captura de pantalla del dispositivo ................................................ 29

4 Diseño ............................................................................................................................. 30

4.1 Complementos de Eclipse (Plug-ins)......................................................................... 30

4.1.1 Asistentes para la creación de proyectos .......................................................... 31

4.1.1.1 Com.digi.android.build ................................................................................. 32

4.1.1.2 Com.digi.android.build.actions ..................................................................... 33

4.1.1.3 Com.digi.android.build.internal .................................................................... 33

4.1.1.4 Com.digi.android.build.nature ...................................................................... 34

4.1.1.5 Com.digi.android.build.wizards .................................................................... 35

4.1.1.6 Com.digi.android.build.wizards.pages .......................................................... 35

4.1.2 Vista de Eclipse con un gestor de dispositivos .................................................. 36

4.1.2.1 Com.digi.android.ui ...................................................................................... 37

4.1.2.2 Com.digi.android.ui.actions .......................................................................... 37

4.1.2.3 Com.digi.android.ui.avd ............................................................................... 39

4.1.2.4 Com.digi.android.ui.internal ......................................................................... 39

4.1.2.5 com.digi.android.ui.perspectives .................................................................. 40

4.1.2.6 Com.digi.android.ui.views ............................................................................ 41

4.1.2.7 Dispositivos y categorías .............................................................................. 42

4.1.2.8 Contenedor de dispositivos .......................................................................... 44

5 Implementación .............................................................................................................. 46

5.1 Creación de plug-ins ................................................................................................ 46

5.2 Naturaleza Android .................................................................................................. 48

5.3 Asistente de nuevos proyectos Android ................................................................... 49

5.3.1 Constructor del asistente ................................................................................. 49

5.3.2 Método addPages ............................................................................................ 49

4

5.3.3 Método createProject ...................................................................................... 49

5.3.4 Clase ProjectBuilderOperation ......................................................................... 50

5.3.5 Clase ManagedProjectCreator .......................................................................... 51

5.3.6 Clase DigiAndroidWizard .................................................................................. 52

5.3.7 Páginas del asistente de proyectos Android ..................................................... 55

5.4 Asistente de proyectos Android de ejemplo ............................................................. 58

5.4.1 Páginas del asistente de proyectos de ejemplo ................................................ 59

5.5 Gestor de dispositivos Android (Vista) ..................................................................... 62

5.5.1 Creación de una vista ....................................................................................... 62

5.5.2 Creación de las acciones .................................................................................. 62

5.5.2.1 Crear dispositivo .......................................................................................... 63

5.5.2.2 Eliminar dispositivo ...................................................................................... 65

5.5.2.3 Editar dispositivo.......................................................................................... 67

5.5.2.4 Conectar dispositivo ..................................................................................... 67

5.5.2.5 Desconectar dispositivo ............................................................................... 69

5.5.2.6 Instalar aplicación ........................................................................................ 70

5.5.2.7 Tomar captura de pantalla ........................................................................... 71

5.5.3 Adición de las acciones en la barra de herramientas ........................................ 72

5.5.4 Vista en forma de árbol .................................................................................... 73

5.5.5 Categorías de dispositivos ................................................................................ 74

5.5.6 Adición de dispositivos a la vista ...................................................................... 74

5.5.7 Conexión y desconexión de dispositivos del ADB .............................................. 76

5.5.8 Proveedor de contenido................................................................................... 76

5.5.9 Proveedor de etiquetas .................................................................................... 77

5.5.10 Menú contextual .............................................................................................. 77

5.5.11 Apariencia final del gestor de dispositivos ........................................................ 78

5.6 Problemas encontrados ........................................................................................... 79

6 Seguimiento del proyecto................................................................................................ 80

6.1 Problemas encontrados ........................................................................................... 83

6.2 Tareas no realizadas ................................................................................................ 83

7 Conclusiones ................................................................................................................... 84

7.1 Conclusiones finales sobre el proyecto .................................................................... 84

8 Glosario........................................................................................................................... 85

9 Bibliografía ...................................................................................................................... 86

5

10 Referencias de interés ................................................................................................. 87

6

Índice de ilustraciones

Ilustración 1: Logo de Digi ......................................................................................................... 9

Ilustración 2: Splash de Digi ESP .............................................................................................. 10

Ilustración 3: Estimación de la duración del proyecto .............................................................. 15

Ilustración 4: Diagrama de casos de uso .................................................................................. 23

Ilustración 5: Arquitectura de Eclipse ...................................................................................... 30

Ilustración 6: Estructura de paquetes de los asistentes de proyectos....................................... 31

Ilustración 7: Clases del paquete com.digi.android.build ......................................................... 32

Ilustración 8: Clases del paquete com.digi.android.build.actions ............................................. 33

Ilustración 9: Clases del paquete com.digi.android.build.internal ............................................ 33

Ilustración 10: Jerarquía de clases de AndroidProjectNature ................................................... 34

Ilustración 11: Jerarquía de clases de los asistentes................................................................. 35

Ilustración 12: Jerarquía de clases de las páginas de los asistentes .......................................... 36

Ilustración 13: Estructura de paquetes de la vista de dispositivos ............................................ 36

Ilustración 14: Estructura de clases de com.digi.android.ui ..................................................... 37

Ilustración 15: Estructura de clases del paquete com.digi.android.ui.actions ........................... 38

Ilustración 16: Estructura de clases del paquete com.digi.android.ui.avd ................................ 39

Ilustración 17: Estructura del paquete com.digi.android.ui.internal ......................................... 40

Ilustración 18: Perspectiva para proyectos Android ................................................................. 41

Ilustración 19: Jerarquía de clases de DeviceManagerView ..................................................... 41

Ilustración 20: Jerarquía de clases de los dispositivos .............................................................. 42

Ilustración 21: Clase Category ................................................................................................. 43

Ilustración 22: Clase AbstractAndroidDevice ............................................................................ 43

Ilustración 23: Clase NetworkAndroidDevice ........................................................................... 44

Ilustración 24: Jerarquía de la clase TreeViewer ...................................................................... 45

Ilustración 25: Editor del MANIFEST.MF .................................................................................. 46

Ilustración 26: Puntos de extensión de los asistentes .............................................................. 47

Ilustración 27: Puntos de extensión de la vista ........................................................................ 47

Ilustración 28: Dependencias necesarias para la naturaleza .................................................... 48

Ilustración 29: Declaración de la naturaleza Android ............................................................... 48

Ilustración 30: Constructor de la clase AndroidProjectWizard .................................................. 49

Ilustración 31: Método addPages de la clase AndroidProjectWizard ........................................ 49

Ilustración 32: Método createProject de la clase AndroidProjectWizard .................................. 50

Ilustración 33: Comprobación de la existencia previa del proyecto .......................................... 51

Ilustración 34: Creación del proyecto a través de la clase ManagedProjectCreator .................. 51

Ilustración 35: Método createProject de la clase ManagedProjectCreator ............................... 52

Ilustración 36: Parámetros del método setProject para proyectos Android .............................. 53

Ilustración 37: Páginas del asistente del ADT ........................................................................... 53

Ilustración 38: Nombre y localización del proyecto.................................................................. 53

Ilustración 39: Selección del SDK del proyecto......................................................................... 54

Ilustración 40: Aplicación, paquete, actividad y versión mínima del SDK .................................. 54

Ilustración 41: Método performFinish de la clase DigiAndroidWizard ...................................... 55

Ilustración 42: Clase AndroidNameLocationPage ..................................................................... 55

Ilustración 43: Pagina de nombre y localización ...................................................................... 56

7

Ilustración 44: Clase AndroidApplicationPage .......................................................................... 57

Ilustración 45: Pagina de aplicación ......................................................................................... 57

Ilustración 46: Paginas del asistente del ADT para proyectos de ejemplo ................................ 58

Ilustración 47: Pagina de selección de ejemplos ...................................................................... 59

Ilustración 48: Estructura de un archivo Project.xml ................................................................ 60

Ilustración 49: Página de resumen de los ejemplos seleccionados ........................................... 61

Ilustración 50: Atributos de la clase DeviceManagerView ........................................................ 62

Ilustración 51: Creación de una acción .................................................................................... 63

Ilustración 52: Crear dispositivo .............................................................................................. 63

Ilustración 53: Crear dispositivo virtual ................................................................................... 64

Ilustración 54: Crear dispositivo en red ................................................................................... 64

Ilustración 55: Gestión del dispositivo a través del AvdManager ............................................. 65

Ilustración 56: Comprobación de ejecución de dispositivo virtual ............................................ 65

Ilustración 57: Confirmación para la eliminación del dispositivo virtual ................................... 66

Ilustración 58: Eliminación del dispositivo virtual .................................................................... 66

Ilustración 59: Eliminación de dispositivo de red ..................................................................... 66

Ilustración 60: Editar dispositivo virtual ................................................................................... 67

Ilustración 61: Editar dispositivo de red................................................................................... 67

Ilustración 62: Clase ADBTool .................................................................................................. 68

Ilustración 63: Conexión de un dispositivo de red .................................................................... 68

Ilustración 64: Desconexión de dispositivos virtuales .............................................................. 69

Ilustración 65: Desconexión de dispositivos de red .................................................................. 69

Ilustración 66: Selección de archivos apk................................................................................. 70

Ilustración 67: Método runWithProgress ................................................................................. 70

Ilustración 68: Método declareInstallRunnable ....................................................................... 71

Ilustración 69: Captura de pantalla .......................................................................................... 71

Ilustración 70: Inserción de elementos en las barras de acciones de la vista ............................ 72

Ilustración 71: Inserción de las acciones en la barra de herramientas ...................................... 72

Ilustración 72: Barra de herramientas sin dispositivo seleccionado ......................................... 72

Ilustración 73: Barra de herramientas con dispositivo seleccionado ........................................ 73

Ilustración 74: Barra de herramientas con dispositivo conectado ............................................ 73

Ilustración 75: Creación de la vista de árbol ............................................................................ 73

Ilustración 76: Columnas de la vista de árbol ........................................................................... 73

Ilustración 77: Estilo de la vista de árbol .................................................................................. 74

Ilustración 78: Declaración e inicialización de las categorías .................................................... 74

Ilustración 79: Adición de los dispositivos de red a su categoría .............................................. 75

Ilustración 80: Adición de los dispositivos virtuales a su categoría ........................................... 75

Ilustración 81: Método refreshList ........................................................................................... 76

Ilustración 82: Creación de un elemento del menú contextual ................................................ 78

Ilustración 83: Añadir entrada al menú contextual .................................................................. 78

Ilustración 84: Vista del gestor de dispositivos ........................................................................ 78

Ilustración 85: Vista del gestor de dispositivos con el menú contextual ................................... 79

Ilustración 86: Duración real del proyecto ............................................................................... 82

8

1. Introducción

En el presente proyecto se documenta el desarrollo de diversos complementos para el

entorno de desarrollo integrado (IDE por sus siglas en inglés) Eclipse. Estos complementos

están destinados al desarrollo de aplicaciones Android y al manejo de dispositivos que cuenten

con este sistema operativo y forman parte de “Digi ESP”, versión personalizada de Eclipse

desarrollada por la empresa Digi International Spain S.A. para facilitar el desarrollo por parte

de sus clientes de aplicaciones relacionadas con sus dispositivos.

9

2. Documento de objetivos del proyecto

En esta sección se describirá de una manera más completa, pero sin profundizar, el

contenido de esta memoria. El origen del proyecto y su finalidad.

2.1. Antecedentes

Ilustración 1: Logo de Digi

Digi International [1] es una empresa especializada en soluciones Connectware que se

dedica al desarrollo de productos y tecnologías que facilitan la conexión de dispositivos a la red

local (LAN). Ofrece a sus clientes una gran variedad de dispositivos como servidores de

dispositivos integrados y externos, servidores de terminales, dispositivos de administración por

consola, adaptadores asíncronos…

Algunos datos clave para definir la empresa:

Fundada en 1985 como DigiBoard

Sale a bolsa en 1989 como Digi International

Cotiza en NASDAQ como DIGI

Cuenta con más 400 personas en sus filas

Su sede se encuentra en Minnetonka (Estados Unidos)

Tiene sucursales en más de 10 países

Su única oficina en España se encuentra en Logroño

10

2.1.1. Productos previos

Ilustración 2: Splash de Digi ESP

Los complementos desarrollados a lo largo de este proyecto están destinados a formar

parte del IDE Digi ESP, desarrollado por la empresa a partir de Eclipse [2] por lo que cuenta con

todas las ventajas de este popular entorno de desarrollo. Cuenta con varias versiones como

Digi ESP for Embedded Linux, Digi ESP for NET+OS y Digi ESP for Python.

2.2. Objetivos

El objetivo del proyecto es la realización de varios complementos destinados a formar

parte de Digi ESP y facilitar la gestión de proyectos relacionados con dispositivos Android [6].

En concreto se trataran de desarrollar los siguientes complementos o plug-ins:

1. Un asistente (wizard) para la creación de proyectos Android

2. Un asistente (wizard) para la creación de proyectos Android de ejemplo

3. Una vista desde la que poder comprobar el estado de los dispositivos Android

disponibles, ya sean dispositivos físicos conectados por USB o por red o

dispositivos virtuales y desde la cual poder llevar a cabo diferentes acciones sobre

ellos:

Crear nuevos dispositivos virtuales

Editar sus configuraciones

Conectar dispositivos al ADB [5]

Desconectar dispositivos del ADB

Instalar aplicaciones en los dispositivos

Tomar capturas de pantalla de los dispositivos

4. Una vista desde la cual poder seleccionar los distintos componentes que serán

utilizados en un determinado dispositivo, generando un archivo XML que será

utilizado para gestionar la carga de los drivers necesarios en el sistema.

11

2.3. Entregables

Documento de objetivos del proyecto

Memoria del proyecto

Cada uno de los complementos desarrollados

2.4. Alcance

Al finalizar el proyecto se espera contar con lo siguiente:

Todos los complementos mencionados desarrollados en su totalidad e integrados

en el entorno de desarrollo de la empresa.

La memoria final del proyecto

Dado que la cantidad de dispositivos con los que realizar pruebas será limitada no se

asegura la compatibilidad y el correcto funcionamiento de los complementos con todos los

dispositivos Android ni con todas las versiones de dicho sistema operativo. No obstante se

intentara hacer las cosas de la manera más estándar posible para evitar en la medida de lo

posible cualquier problema con cualquier dispositivo o versión del sistema.

Tampoco se asegura la compatibilidad de los complementos con futuras versiones del

entorno de desarrollo o con futuras versiones del ADT (Android Development Tools, en el cual

se apoyan los complementos [4]).

2.5. Metodología y ciclo de vida

Dado que no se trata de un proyecto demasiado extenso y que en su desarrollo solo va a

estar involucrada una persona (aunque tenga apoyo de los tutores será el alumno el encargado

de todo el desarrollo) no se ha considerado necesario seguir de una manera estricta ninguna

metodología en concreto, aunque se tendrán en cuenta los conocimientos adquiridos a lo

largo de la carrera sobre el proceso unificado de desarrollo y el ciclo de vida iterativo e

incremental.

2.6. Planificación

El proyecto se desarrollará en varias fases tras cada una de las cuales se tendrá uno de los

complementos deseados.

12

El tiempo total estimado para la realización del proyecto es de aproximadamente 300

horas, tiempo que podrá variar en función de las dificultades o problemas que pudiesen surgir

a lo largo de su desarrollo.

2.6.1. Estructura de descomposición del proyecto (EDP)

Dirección del proyecto

Contiene las tareas relacionadas con la gestión y seguimiento del proyecto.

Creación del DOP (Estimación: 5 horas)

Creación del documento de objetivos del proyecto.

Planificación (Estimación: 5 horas)

Realización de la EDP y estimación del tiempo necesario para cada una de las tareas que la

componen.

Formación (Estimación: 40 horas)

Tareas de documentación y estudio necesarias tanto para familiarizarse con el desarrollo de

proyectos Android como para la adquisición de los conocimientos necesarios para completar el

proyecto.

Desarrollo de la memoria (Estimación: 80 horas)

Desarrollo del documento final de la memoria.

Defensa del proyecto (Estimación: 5 horas)

Preparación de la presentación y defensa del proyecto.

Análisis

Contiene las tareas necesarias para definir los productos que deben obtenerse llegada la

finalización del proyecto.

13

Captura de requisitos (Estimación: 5 horas)

Reuniones en las que se describirá por parte de la empresa los productos que espera obtener y

las condiciones que deben cumplir.

Especificación de los requisitos (Estimación: 10 horas)

Desarrollo de un documento en el que se describan de manera clara y completa los requisitos

capturados anteriormente.

Análisis de casos de uso (Estimación: 10 horas)

Estudio de los posibles actores y casos de usos que definirán la funcionalidad que se espera de

los complementos una vez estén terminados.

Análisis de clases (Estimación: 20 horas)

Descripción de las clases que se consideren necesarias para el desarrollo del proyecto.

Diseño

Contiene las tareas necesarias para definir de una manera más detallada los aspectos

analizados en la fase de análisis.

Desarrollo de diagramas de casos de uso (Estimación: 20 horas)

Desarrollo de los casos de uso analizados en la fase anterior.

Desarrollo de diagramas de clases (Estimación: 10 horas)

Desarrollo de las clases analizadas en la fase anterior.

Implementación

Contiene las tareas necesarias para el desarrollo del código de los complementos.

14

Desarrollo (Estimación: 80 horas)

Desarrollo propiamente dicho del código necesario para el correcto funcionamiento de los

complementos.

Revisión y pruebas (Estimación: 20 horas)

Se llevará a cabo a la par que el desarrollo y consistirá en la comprobación del correcto

funcionamiento de los complementos y en la corrección en caso de que fuese necesario del

código que no funcione de la manera esperada.

2.6.2. Duración estimada del proyecto

2011

Septiembre Octubre

L M X J V S D L M X J V S D

1 2 3 4 1 2

5 6 7 8 9 10 11 3 4 5 6 7 8 9

12 13 14 15 16 17 18 10 11 12 13 14 15 16

19 20 21 22 23 24 25 17 18 19 20 21 22 23

26 27 28 29 30 24 25 26 27 28 29 30

31

Noviembre Diciembre

L M X J V S D L M X J V S D

1 2 3 4 5 6 1 2 3 4

7 8 9 10 11 12 13 5 6 7 8 9 10 11

14 15 16 17 18 19 20 12 13 14 15 16 17 18

21 22 23 24 25 26 27 19 20 21 22 23 24 25

28 29 30 26 27 28 29 30 31

2012

Enero Febrero

L M X J V S D L M X J V S D

1 1 2 3 4 5

2 3 4 5 6 7 8 6 7 8 9 10 11 12

9 10 11 12 13 14 15 13 14 15 16 17 18 19

16 17 18 19 20 21 22 20 21 22 23 24 25 26

23 24 25 26 27 28 29 27 28 29

30 31

Documentación y análisis Implementación

Pruebas y revisiones Documentación

15

Ilustración 3: Estimación de la duración del proyecto

Este gráfico representa el porcentaje de las horas totales dedicadas al proyecto que se

estima serán destinadas a cada tarea.

Dirección del proyecto: 135 horas

Análisis: 45 horas

Diseño: 30 horas

Implementación: 100 horas

TOTAL: 310 horas

2.7. Plan de riesgos

En esta sección se enumerarán los posibles problemas que se pueden presentar a lo largo

del desarrollo del proyecto. También se dará una descripción de los mismos y las acciones

propuestas para intentar minimizar el daño en caso de que se produzcan estos problemas.

2.7.1. Cancelación del proyecto

Descripción: Al tratarse de un proyecto real encargado por una empresa cuyo objetivo en

principio es obtener el producto solicitado para ponerlo a disposición de sus trabajadores y

44%

14%

10%

32%

Estimación de la duración del proyecto

Dirección del proyecto

Análisis

Diseño

Implementación

16

clientes existe la posibilidad de que finalmente se decida que el producto no es necesario, o

prioritario, y se cancele o posponga el desarrollo del mismo.

Probabilidad: Baja

Plan de contingencia: Si la empresa decidiese no continuar con el proyecto o posponer su

desarrollo podrían tomarse dos acciones para intentar minimizar los daños. Si sucediese al

inicio del proyecto se podría contemplar la posibilidad de llevar a cabo un proyecto diferente

en el cual la empresa estuviese más interesada. Si el proyecto estuviese más avanzado la

“solución” sería llevar a cabo el proyecto de manera independiente ya fuese con la

colaboración de la empresa o sin ella.

2.7.2. Falta de formación o conocimientos necesarios

Descripción: Debido a que la naturaleza del proyecto requiere de conocimientos no solo de

Java sino del entorno de desarrollo Eclipse y de la programación en Android así como el

manejo de las herramientas que Google ofrece para el desarrollo de aplicaciones Android [6]

en Eclipse [2] (plug-in ADT [4]) es posible que el alumno desconozca estas tecnologías.

Probabilidad: Alta

Plan de contingencia: Esta es una situación habitual en cualquier proyecto, ya que en el

mundo de la informática siempre nos enfrentamos a nuevas tecnologías y herramientas que

desconocemos. La solución es informarse, buscar documentación o ayuda de personas con

conocimientos en la materia en cuestión y aprender de todo ello. No obstante puede darse la

situación de que dadas las características de un determinado proyecto la curva de aprendizaje

fuese demasiado alta, en cuyo caso podría hacer imposible el desarrollo del mismo, al menos

en un plazo de tiempo aceptable.

2.7.3. Mala elección de herramientas

Descripción: No todas las herramientas disponibles a la hora de llevar a cabo un proyecto

tienen las mismas funcionalidades ni ofrecen la misma compatibilidad a la hora de ser

utilizadas en diferentes entornos (sistemas operativos, versiones de los mismos…) o a la hora

de ser utilizadas en conjunción con otras herramientas. Esto puede provocar que una mala

elección de las herramientas utilizadas desemboque en una situación de bloqueo que nos

impida llevar a cabo ciertas acciones o en un problema de compatibilidad que haga que el

producto desarrollado no cumpla con los requisitos especificados ya sea en una o varias

plataformas.

Probabilidad: Baja

17

Plan de contingencia: Dado que el proyecto tiene unos requisitos muy claros con respecto a

las herramientas a utilizar (se trata de complementos para una versión modificada de Eclipse

[2]) no hay posibilidad de equivocarse en cuanto a la elección. Cualquier incompatibilidad o

carencia en el producto final vendría dada por el IDE o los plug-ins sobre los que se apoyan los

complementos desarrollados y que vienen impuestos por los requisitos del proyecto.

2.7.4. Pérdida de datos

Descripción: En cualquier momento podría perderse parte de la información recabada o del

código generado, bien sea por un error del alumno, por la pérdida de algún dispositivo de

almacenamiento como puede ser una memoria USB, por la corrupción de ciertos archivos

debido a un fallo técnico o por la acción de un virus informático.

Probabilidad: Media/Baja

Plan de contingencia: Dado que el desarrollo se llevara a cabo en las instalaciones de la

empresa la posibilidad de que se produzca un fallo informático o la infección del sistema

resultan muy improbables, no obstante siempre se guardara la información en varios lugares

para evitar cualquier pérdida. La información se almacenara tanto en el equipo en el que el

alumno este trabajando como en el servidor de la empresa como en una memoria USB.

2.7.5. Errores en la planificación

Descripción: La falta de experiencia por parte del alumno en cuestiones de planificación puede

desembocar en que sus estimaciones no se ajusten a la realidad del desarrollo del proyecto lo

cual haría que los tiempos y plazos fijados se viesen afectados.

Probabilidad: Alta

Plan de contingencia: Estos errores son difíciles de evitar cuando no se cuenta con experiencia

en la planificación de proyectos por lo que lo único que se puede hacer es realizar unas

estimaciones conservadoras y no demasiado optimistas para no encontrarnos con diferencias

demasiado abultadas entre las estimaciones iniciales y los tiempos reales del proyecto.

2.7.6. Cambios en los requisitos

Descripción: Durante el desarrollo del proyecto, y especialmente en casos como este en los

que se trata de un proyecto real es posible que se produzcan cambios en los requisitos

motivados por nuevas necesidades no contempladas en un primer momento o por la aparición

de cambios o nuevas versiones del software en el que se basa el proyecto.

18

Probabilidad: Media

Plan de contingencia: Adaptar el análisis, el diseño y la implementación realizados hasta el

momento añadiendo lo que resultase necesario o modificando lo ya existente para ajustarse a

las nuevas necesidades.

2.7.7. Errores en el diseño

Descripción: Dado el desconocimiento por parte del alumno de ciertas tecnologías requeridas

para el desarrollo del proyecto puede que el diseño propuesto resulte erróneo o ineficiente.

Probabilidad: Media

Plan de contingencia: Se revisara el diseño inicial y se propondrá uno nuevo documentando

los cambios realizados y el motivo de los mismos.

2.7.8. Problemas de disponibilidad del alumno

Descripción: Debido a diferentes causas (enfermedad, trabajo…) puede que el alumno no le

dedique al proyecto el tiempo previsto inicialmente, lo cual desembocaría en la imposibilidad

de cumplir con los plazos estimados para el desarrollo del proyecto.

Probabilidad: Media

Plan de contingencia: Se modificarán los plazos de entrega para ajustarse al tiempo “perdido”

durante el periodo en el que el alumno no se ha dedicado al desarrollo del proyecto.

2.7.9. Disconformidad del cliente con el producto resultante

Descripción: El producto final obtenido no cumple las expectativas del cliente bien sea por una

mala comprensión de los requisitos o por una mala implementación de los mismos.

Probabilidad: Baja

Plan de contingencia: Se intentará reducir la probabilidad de que se produzca mediante un

análisis de los requisitos lo más completo posible y mostrándole al cliente los avances que se

van produciendo a lo largo del desarrollo del producto.

19

2.8. Tecnologías y herramientas utilizadas y costes de las mismas

En esta sección se describirán las herramientas y tecnologías utilizadas para el desarrollo

del proyecto y los costes de las mismas en caso de que los hubiera.

2.8.1. Eclipse

Entorno de desarrollo integrado utilizado para el desarrollo de los complementos y en

cual deben integrarse los mismos.

Se trata de un programa multiplataforma compuesto por un conjunto de herramientas

de programación de código abierto. Dispone de un editor de texto con resaltado de sintaxis y

herramientas para el control de versiones, integración con Ant, asistentes para la creación de

proyectos y además es extensible mediante la instalación de complementos que aportan

diferentes funcionalidades.

Enlace: http://www.eclipse.org/

Licencia: http://www.eclipse.org/org/documents/epl-v10.php

Coste: Gratuito

2.8.2. Java

Lenguaje de programación utilizado para el desarrollo de los complementos

Dado que Eclipse, programa en el que tienen que integrarse los complementos

desarrollados, está programado principalmente en Java, que el código existente estaba

elaborado en este lenguaje y que el alumno tenia conocimientos previos del mismo ha sido el

elegido para la implementación del código.

Se trata de un lenguaje de programación de propósito general, concurrente, orientado a

objetos y basado en clases y que se creó pensando en la independencia del código con

respecto a la plataforma en la que se ejecutase, lo que en ingles se conoce como “WORA”

(write once, run anywhere) lo que quiere decir que no hace falta recompilar el código para

poder ejecutarlo en distintas plataformas.

Enlace: http://www.oracle.com/technetwork/java/javase/downloads/index.html

Licencia: http://www.oracle.com/technetwork/java/javase/terms/license/index.html

Coste: Gratuito

20

2.8.3. ADT (Android Development Tools)

Es un complemento para Eclipse que facilita el desarrollo de aplicaciones Android.

Este complemento es necesario para el desarrollo de los complementos ya que ofrece

funcionalidades en las cuales se apoyaran. Lo que más nos interesará serán los asistentes para

la creación de proyectos Android, que extenderemos, y el ADB (Android Debug Bridge), una

herramienta de línea de órdenes que permite comunicarse con dispositivos virtuales o físicos

basados en Android.

Enlace: http://developer.android.com/intl/es/tools/sdk/eclipse-adt.html

Licencia: http://www.eclipse.org/org/documents/epl-v10.php

Coste: Gratuito

2.9. Arquitectura del producto

Los complementos desarrollados se basarán en una arquitectura de 3 capas, cuyo

principal objetivo es separar la presentación, la lógica de la aplicación y el almacenamiento de

datos permitiendo así mantener por ejemplo la capa de datos intacta aunque cambie la lógica

o reutilizar las capas de datos y lógica utilizando una presentación diferente.

2.9.1. Presentación

Es la capa mediante la cual el usuario interactúa con el sistema. Se encarga de presentar

la información de una manera clara e inteligible y de recoger las interacciones del usuario o los

datos introducidos. En esta capa no suele haber ninguna lógica ni procesamiento de datos

salvo validaciones simples de los datos introducidos para asegurarse que tienen el formato

correcto.

En nuestro caso nos tendremos que preocupar de la manera en que se organiza la

información en la pantalla, pero no especialmente del aspecto de las ventanas ya que estilo de

las mismas será el definido por el sistema.

2.9.2. Lógica de negocio

Es la capa en la que se lleva a cabo cualquier procesamiento de datos o acciones. Se

encarga de hacer que se cumplan las reglas de negocio que definen el comportamiento de la

aplicación. Se comunicará tanto con la capa de presentación para enviarle los datos que debe

mostrar y para recoger los datos e interacciones llevadas a cabo por el usuario como con la

capa de persistencia para recoger y almacenar los datos generados.

21

2.9.3. Persistencia

Es la capa encargada de gestionar tanto la recogida como el almacenamiento de datos.

En el caso que nos ocupa esta capa no existirá ya que la aplicación no genera datos que haya

que almacenar y el acceso a los datos que necesitan mostrarse (las versiones del SDK y los

proyectos de ejemplo disponibles) ya está desarrollado.

22

3. Análisis

En esta sección se estudiaran los requisitos que debe cumplir el producto. Este análisis nos

permitirá más adelante poder realizar un diseño adecuado a las necesidades planteadas.

3.1. Especificación de requisitos

En este punto detallaremos las necesidades que debe satisfacer el sistema.

3.1.1. Requisitos no funcionales

Son aquellas condiciones que debe cumplir el sistema que no tienen que ver con

acciones concretas que el sistema debe llevar a cabo sino más bien con la manera en que

deben realizarse.

El código debe estar estructurado de la manera más legible y coherente posible y

adaptarse a la estructura previa del sistema en el que se integrará.

Cualquier información sensible debe tratarse de la manera más segura posible

evitando que quede expuesta.

El sistema debe tener un tiempo de respuesta razonablemente rápido.

Debe tener una interfaz que se ajuste a lo que en cada caso sea lo “habitual”

para facilitar su uso por personas que hayan utilizado herramientas similares y lo

suficientemente clara y sencilla como para que también pueda ser usada sin

problemas por usuarios sin experiencia.

Tanto el código como cualquier comentario que se haga dentro del mismo y los

textos que aparezcan en la interfaz deben estar en inglés.

3.1.2. Requisitos funcionales

Son aquellas funciones concretas que el sistema debe llevar a cabo.

Deben realizarse varios complementos cuya funcionalidad se especificara más adelante

mediante la realización de diagramas de casos de uso y especificación de los mismos.

23

Ilustración 4: Diagrama de casos de uso

24

3.1.2.1 Crear proyecto Android

Caso de uso Crear proyecto Android

Actores Usuario

Descripción El sistema deberá permitir al usuario poder crear un nuevo proyecto Android guiándole mediante un asistente que le permitirá seleccionar ciertas características del proyecto.

Secuencia normal 1 Usuario: Inicia el asistente. 2 Sistema: Muestra la primera página del asistente. 3 U: Especifica el nombre del proyecto. 4 U: Pulsa el botón de siguiente. 5 S: Muestra la segunda página del asistente. 6 U: Especifica el nombre del paquete. 7 U: Pulsa el botón de Finalizar. 8 S: Crea el proyecto basándose en los datos introducidos por el usuario.

Excepciones 3.1 U: Especifica una localización para el nuevo proyecto diferente a la establecida por defecto. 3.2 U: Selecciona un SDK de Android diferente al establecido por defecto. 6.1 U: Especifica un nombre para la aplicación diferente al establecido por defecto. 6.2.1 U: Desmarca la opción de crear una actividad en el proyecto. 6.2.2 U: Especifica un nombre para la actividad diferente al establecido por defecto. 6.3 U: Selecciona un SDK mínimo para el proyecto diferente al establecido por defecto.

Comentarios El usuario podrá cancelar el proceso en cualquier momento o volver a la página anterior del asistente.

25

3.1.2.2 Crear proyecto de ejemplo Android

Caso de uso Crear proyecto de ejemplo Android

Actores Usuario

Descripción El sistema deberá permitir al usuario crear un nuevo proyecto Android guiándole mediante un asistente que le permitirá seleccionar uno de los proyectos de ejemplo disponibles.

Secuencia normal 1 Usuario: Inicia el asistente. 2 Sistema: Muestra la primera página del asistente. 3 U: Selecciona el proyecto o proyectos de ejemplo que quiere crear. 4 U: Pulsa Siguiente. 5 S: Muestra la segunda página del asistente donde se le muestra al usuario un resumen de los datos seleccionados. 6 U: Pulsa el botón de finalizar 7 S: crea el /los proyectos de ejemplo seleccionados.

Excepciones 3.1 U: Marca la opción de mostrar únicamente los proyectos compatibles con una plataforma determinada. 3.2 U: Selecciona una de las plataformas disponibles. 3.3 S: Filtra los proyectos de ejemplo para mostrar únicamente aquellos compatibles con la plataforma seleccionada por el usuario.

Comentarios El usuario podrá cancelar el proceso en cualquier momento o volver a la página anterior del asistente.

3.1.2.3 Visualizar dispositivos disponibles

Caso de uso Visualizar dispositivos disponibles

Actores Usuario

Descripción El sistema deberá permitir al usuario visualizar los dispositivos Android disponibles en el sistema, ya sean dispositivos conectados físicamente mediante USB, dispositivos virtuales o dispositivos conectados por red.

Secuencia normal 1 Usuario: Muestra la vista “Android Device Manager” 2 Sistema: Muestra en esa lista una lista con los dispositivos Android disponibles.

Excepciones

Comentarios En la vista se mostrará diversa información de cada dispositivo como su nombre, su identificador si lo tiene, su estado (conectado/desconectado) y la versión de la API que utiliza. Los dispositivos se mostrarán agrupados por tipo (físico, virtual o conectado por red) en una estructura de árbol que podrá colapsarse/expandirse.

26

3.1.2.4 Añadir dispositivo

Caso de uso Añadir dispositivo

Actores Usuario

Descripción El sistema deberá permitir añadir dispositivos virtuales y de red.

Secuencia normal 1 Usuario: Selecciona la categoría de dispositivos virtuales. 2 U: Pulsa el botón de añadir dispositivo. 3 Sistema: Abre la ventana de creación de dispositivos virtuales propia del ADT (Android Development Tools). 4 U: Establece la configuración deseada para el dispositivo. 5 U: Pulsa el botón de crear AVD (Android Virtual Device). 6 S: Crea el dispositivo virtual.

Excepciones 1.1 U: Selecciona la categoría de dispositivos de red. 2.1 U: Pulsa con el botón derecho sobre la categoría deseada. 2.2 S: Muestra el menú contextual. 2.3 U: Pulsa la entrada del menú contextual correspondiente a crear dispositivo. 3.1 S: Abre la ventana de creación de dispositivo de red. 3.2 U: Establece los datos del dispositivo (nombre, IP y puerto). 3.3 U: Pulsa el botón de aplicar. 3.4 S: Crea el dispositivo de red.

Comentarios El usuario podrá cancelar el proceso en cualquier momento.

3.1.2.5 Editar dispositivo

Caso de uso Editar dispositivo

Actores Usuario

Descripción El sistema deberá permitir editar la configuración de los dispositivos virtuales y de red.

Secuencia normal 1 Usuario: Selecciona el dispositivo que desea editar. 2 U: Pulsa el botón de editar dispositivo. 3 Sistema: Muestra la pantalla de configuración del dispositivo. 4 U: Establece los datos de configuración del dispositivo deseados. 5 U: Pulsa el botón de aceptar. 6 S: Modifica la configuración del dispositivo editado.

Excepciones 1.1 U: Pulsa con el botón derecho sobre el dispositivo que desea editar. 1.2 S: Muestra el menú contextual. 2.1 U: Pulsa la entrada del menú correspondiente a editar dispositivo.

Comentarios El usuario podrá cancelar el proceso en cualquier momento.

27

3.1.2.6 Eliminar dispositivo

Caso de uso Eliminar dispositivo

Actores Usuario

Descripción El sistema deberá permitir eliminar los dispositivos virtuales y de red.

Secuencia normal 1 Usuario: Selecciona el dispositivo que desea eliminar. 2 U: Pulsa el botón de eliminar dispositivo. 3 Sistema: Muestra un mensaje al usuario avisándole de que la operación no se puede deshacer y pidiéndole que confirme la orden. 4 U: Confirma que desea eliminar el dispositivo. 5 S: Elimina el dispositivo

Excepciones 1.1 U: Pulsa con el botón derecho sobre el dispositivo que desea eliminar. 1.2 S: Muestra el menú contextual. 2.1 U: Pulsa la entrada del menú correspondiente a eliminar dispositivo. 4.1 U: Cancela la eliminación.

Comentarios Al eliminar un dispositivo virtual no solo se elimina de la lista sino que se eliminan los archivos y carpetas que lo componen.

3.1.2.7 Conectar dispositivo

Caso de uso Conectar dispositivo

Actores Usuario

Descripción El sistema debe permitir conectar un dispositivo al ADB (Android Debug Bridge).

Secuencia normal 1 Usuario: Selecciona el dispositivo que desea conectar al ADB. 2 U: Pulsa el botón de conectar dispositivo. 3 Sistema: Conecta el dispositivo seleccionado con el ADB.

Excepciones 1.1 U: Pulsa con el botón derecho sobre el dispositivo que quiere conectar al ADB. 1.2 S: Muestra el menú contextual. 2.1Pulsa la entrada del menú correspondiente a conectar dispositivo.

Comentarios En el caso de que se trate de un dispositivo virtual lo arrancara para poder conectarlo al ADB.

28

3.1.2.8 Desconectar dispositivo

Caso de uso Desconectar dispositivo

Actores Usuario

Descripción El sistema debe permitir desconectar un dispositivo del ADB (Android Debug Bridge).

Secuencia normal 1 Usuario: Selecciona el dispositivo que desea desconectar. 2 U: Pulsa el botón de desconectar dispositivo. 3 Sistema: Desconecta el dispositivo del ADB.

Excepciones 1.1 U: Pulsa con el botón derecho sobre el dispositivo que desea desconectar. 1.2 S: Muestra el menú contextual. 2.1 U: Pulsa la entrada del menú correspondiente a desconectar dispositivo.

Comentarios En el caso de que se trate de un dispositivo virtual cerrara el emulador al desconectarlo.

3.1.2.9 Instalar aplicación en el dispositivo

Caso de uso Instalar aplicación en el dispositivo

Actores Usuario

Descripción El sistema debe permitir instalar aplicaciones en los dispositivos.

Secuencia normal 1 Usuario: Selecciona el dispositivo en el que desea instalar la aplicación. 2 U: Pulsa el botón de instalar aplicación. 3 Sistema: Muestra un dialogo de selección de archivos. 4 U: Selecciona el archivo .apk que desea instalar en el dispositivo. 5 S: Instala la aplicación en el dispositivo.

Excepciones 1.1 U: Pulsa con el botón derecho sobre el dispositivo en el que desea instalar la aplicación. 1.2 S: Muestra el menú contextual. 2.1 U: Pulsa la entrada del menú correspondiente a instalar aplicación.

Comentarios

29

3.1.2.10 Tomar captura de pantalla del dispositivo

Caso de uso Tomar captura de pantalla del dispositivo

Actores Usuario

Descripción El sistema debe permitir tomar capturas de pantalla de los dispositivos.

Secuencia normal 1 Usuario: Selecciona el dispositivo del cual quiere hacer la captura de pantalla. 2 U: Pulsa el botón de tomar captura de pantalla 3 Sistema: Abre el cuadro de dialogo de captura de pantalla del ADT (Android Development Tools). 4 S: Captura una imagen de la pantalla del dispositivo. 5 U: Interactúa con el dialogo de captura de pantalla del ADT (refrescar, rotar, guardar, copiar, terminar).

Excepciones 1.1 U: Pulsa con el botón derecho sobre el dispositivo del cual quiere hacer la captura de pantalla. 1.2 S: Muestra el menú contextual. 2.1 U: Pulsa sobre la entrada del menú correspondiente a tomar captura de pantalla.

Comentarios

30

4 Diseño

En esta sección se describirán ciertas decisiones tomadas a la hora de implementar las

funcionalidades especificadas anteriormente y también algunas de las estructuras utilizadas.

4.1 Complementos de Eclipse (Plug-ins)

La funcionalidad requerida se va a implementar en forma de complementos o plug-ins de

Eclipse. El plug-in es la mínima unidad funcional de Eclipse que puede distribuirse de manera

independiente. Estos plug-ins pueden funcionar independientemente o agruparse para formar

herramientas con una funcionalidad mayor. En eclipse, salvo el “Platform Runtime”, toda la

funcionalidad esta implementada mediante plug-ins.

Ilustración 5: Arquitectura de Eclipse

Estos plug-ins pueden ser de varios tipos:

- Librerías que definan una interfaz pública que pueda ser usada por terceros.

- Extensiones de la plataforma a través de los puntos de extensión.

- Recursos sin ninguna lógica (documentación, traducciones, imágenes…)

Los plug-ins se desarrollan a través de los puntos de extensión [3] de la plataforma que son

básicamente interfaces que pueden ser implementadas por los desarrolladores para aportar

una funcionalidad concreta al entorno.

31

Para el desarrollo de los mismos utilizaremos una nomenclatura de paquetes y una

organización similar a la que tiene la empresa en otros proyectos, lo que resultara muy sencillo

ya que se trata de una organización muy intuitiva en la que las clases se organizan en

paquetes según la funcionalidad de las mismas.

La organización en paquetes no será la única que deberemos tener en cuenta. Los

asistentes formaran parte de un proyecto de Eclipse en el que definiremos plug-ins

relacionados con la creación de proyectos y la vista se incluirá dentro de un proyecto cuya

funcionalidad está relacionada con la interfaz gráfica de Eclipse.

4.1.1 Asistentes para la creación de proyectos

Se trata de plug-ins cuya funcionalidad consiste en guiar al usuario en el proceso de

creación de un proyecto. Para ello se le mostrarán una serie de páginas en las que podrá

configurar las opciones necesarias, y algunas opcionales, para poder crear un proyecto.

La empresa ya cuenta con asistentes para la creación de proyectos de otros tipos, así que

se utilizará la misma estructura e incluso se “copiaran” algunas clases (aunque evidentemente

habrá que modificarlas para adaptarlas a nuestras necesidades). Esto se ha hecho así

principalmente por dos motivos. El primero es que se trata de una estructura que sabemos

que funciona por lo que nos ahorrará trabajo y también la posibilidad de encontrarnos con

situaciones no previstas por la falta de experiencia que puedan suponer un contratiempo. El

segundo es que nuestra estancia en la empresa es temporal y el hecho de utilizar una

estructura bien conocida por los desarrolladores de la empresa facilitará el mantenimiento de

la misma y las posibles modificaciones que quieran hacerse en el futuro.

Ilustración 6: Estructura de paquetes de los asistentes de proyectos

32

4.1.1.1 Com.digi.android.build

Ilustración 7: Clases del paquete com.digi.android.build

Este paquete contendrá dos clases imprescindibles para el funcionamiento del plug-in y

estarán basadas en clases existentes de la empresa para la creación de otro tipo de proyectos

- AndroidBuildPlugin: Será la encargada de controlar el ciclo de vida del plug-in

implementando los métodos start y stop de la clase abstracta AbstractUIPlugin.

También proporcionara otros métodos que permitirán recoger la instancia del plug-in,

el espacio de trabajo y alguna cosa más. Para adaptarla a nuestras necesidades

únicamente tendremos que especificar el identificador del plug-in y los tipos de

proyectos con los que trabajará.

- AndroidBuildUIImages: Será la encargada de gestionar el control de las imágenes

utilizadas en la interfaz. Lo único que tendremos que hacer en este caso será añadir las

imágenes que utilizaremos en los asistentes.

33

4.1.1.2 Com.digi.android.build.actions

Ilustración 8: Clases del paquete com.digi.android.build.actions

Se trata de una clase previa de Digi que nosotros no utilizaremos.

4.1.1.3 Com.digi.android.build.internal

Será en este paquete donde encontraremos las clases que contendrán gran parte de la

lógica necesaria para poder crear los proyectos. Se aprovechará la estructura de clases

utilizada por la empresa en la creación de proyectos XBee [7]. Como se ha comentado

anteriormente esto facilitara tanto el desarrollo presente como el mantenimiento y posible

ampliación de las funcionalidades en el futuro.

Ilustración 9: Clases del paquete com.digi.android.build.internal

34

- ManagedProjectCreator: Será la encargada en última instancia de la creación de los

proyectos haciendo uso de la clase privada DigiAndroidWizard que estará declarada

dentro de ella.

- DigiAndroidWizard: Será la clase que se encargue de especificar los parámetros

recogidos en nuestras páginas y completar la creación del proyecto. Esta clase privada

declarada dentro de la anterior estará desarrollada íntegramente por nosotros y

extenderá el asistente de creación de proyectos del ADT.

- ProjectBuilderOperation: Será la encargada de controlar la creación de proyectos. En

función del tipo de proyecto del que se trate creara el proyecto de una manera u otra

sirviéndose de la clase ManagedProjectCreator.

- ProjectOverwriteQuery: Será la encargada de comprobar si el proyecto ya existe y

determinar si debe sobrescribirse o no en función de la elección del usuario.

4.1.1.4 Com.digi.android.build.nature

En este paquete tendremos una única clase encargada de definir una naturaleza que

asociaremos a nuestros proyectos.

Una naturaleza es como una “marca” o “etiqueta” que se le pone a un proyecto y que

permite especificar el tipo de proyecto con el que estamos tratando. A partir de aquí tanto el

entorno de desarrollo como los diferentes complementos instalados pueden comprobar las

naturalezas asociadas con un determinado proyecto y decidir si permiten realizar ciertas

acciones sobre ese proyecto, si desean mostrarlo en una determinada vista o no…

En nuestro caso solo la utilizaremos para definir un icono determinado que permita

distinguir este tipo de proyecto de los demás, pero dejaremos la puerta abierta para que

futuros complementos desarrollados por la empresa puedan especificar ciertos

comportamientos para este tipo de proyectos.

Ilustración 10: Jerarquía de clases de AndroidProjectNature

35

4.1.1.5 Com.digi.android.build.wizards

Este paquete contendrá las clases encargadas de inicializar los dos asistentes de proyectos,

controlar la navegación a través de sus páginas y llamar a las clases comentadas anteriormente

para llevar a cabo la creación de los proyectos. También se encargaran de mostrar y

seleccionar el proyecto creado en el explorador de paquetes de Eclipse.

En el caso del asistente de proyectos de ejemplo implementaremos una interfaz

definida por Digi que nos permitirá más adelante aprovecharnos de ciertas funcionalidades

provistas por la empresa para este tipo de asistentes.

Ilustración 11: Jerarquía de clases de los asistentes

4.1.1.6 Com.digi.android.build.wizards.pages

En este paquete crearemos las distintas clases que definirán las páginas que compondrán los

asistentes. Cada una de estas páginas tendrá una funcionalidad diferente que explicaremos

más adelante.

36

Ilustración 12: Jerarquía de clases de las páginas de los asistentes

En el caso del asistente de proyectos de ejemplo extenderemos unas clases previas

creadas por Digi que facilitaran la organización de la información en las páginas del asistente.

4.1.2 Vista de Eclipse con un gestor de dispositivos

En este caso nos encontraremos con un proyecto ya creado, con muchas clases

desarrolladas debido a que la empresa había creado anteriormente una perspectiva propia

para los proyectos Android. El único paquete que tendremos que crear nosotros será “views”,

donde estará la clase que implemente la vista, y añadiremos las clases proveedoras de

contenido y etiquetas en “internal”.

Ilustración 13: Estructura de paquetes de la vista de dispositivos

Igual que hemos hecho anteriormente haremos un recorrido a través de las clases que

componen los paquetes comentando su utilidad.

37

4.1.2.1 Com.digi.android.ui

Ilustración 14: Estructura de clases de com.digi.android.ui

- AndroidUIPlugin: Al igual que pasaba en los asistentes esta clase será la encargada de

controlar el ciclo de vida del plug-in a través de los métodos start y stop de la clase

AbstractUIPlugin.

- AndroidUIImages: Será la encargada de controlar la gestión de las imágenes mostradas

en la interfaz.

- AndroidUIStartup: Se encargará de controlar la perspectiva utilizada en Eclipse.

4.1.2.2 Com.digi.android.ui.actions

Igual que ocurría en el paquete actions [Com.digi.android.build.actions] de los

asistentes aquí nos encontraremos con varias clases previas que no utilizaremos.

38

Ilustración 15: Estructura de clases del paquete com.digi.android.ui.actions

39

4.1.2.3 Com.digi.android.ui.avd

Este paquete contendrá las clases previas desarrolladas por Digi para el control de

dispositivos virtuales a través del gestor de dispositivos proporcionado por el ADT.

Ilustración 16: Estructura de clases del paquete com.digi.android.ui.avd

4.1.2.4 Com.digi.android.ui.internal

En este paquete crearemos las clases que nos permitirán controlar la gestión del contenido

de la vista y de la información mostrada en la misma en función del contenido. Para mostrar

esa información al usuario haremos uso de un tipo de “viewer” de JFace [Contenedor de

40

dispositivos], lo que nos permitirá abstraernos del control y la gestión del contenido mostrado

utilizando las clases aquí definidas.

Ilustración 17: Estructura del paquete com.digi.android.ui.internal

- AndroidDevicesContentProvider: Será la clase encargada de proveer métodos que nos

permitan gestionar el contenido de la vista.

- AndroidDevicesLabelProvider: Será la clase encargada de proveer métodos que nos

permitan especificar la información mostrada en la vista en función del contenido de la

misma.

- AndroidWizardRegistry: Esta es una clase previa creada por Digi para la gestión de

proyectos XBee que nosotros no utilizaremos.

4.1.2.5 com.digi.android.ui.perspectives

En este paquete encontraremos una clase definida por Digi que define una perspectiva de

Eclipse propia para proyectos Android. Se encarga de definir las acciones y vistas disponibles

cuando se selecciona esta perspectiva, lo que sucederá cada vez que se cree un proyecto

Android, ya que se asociará a este tipo de proyectos. Será aquí donde indiquemos, si así se

quiere, que nuestra vista del gestor de dispositivos se muestre al utilizar esta perspectiva.

41

Ilustración 18: Perspectiva para proyectos Android

4.1.2.6 Com.digi.android.ui.views

Este es el paquete que más nos interesa, ya que es aquí donde definiremos la vista que

vamos a crear y la dotaremos de la funcionalidad deseada.

Ilustración 19: Jerarquía de clases de DeviceManagerView

42

4.1.2.7 Dispositivos y categorías

Para poder dotar de funcionalidad nuestra vista necesitaremos crear una serie de clases

que definan los dispositivos con los que trabajaremos. En este caso se incluirán en un paquete

dentro de otro proyecto utilizado por la plataforma, haciéndolos así accesibles a otros plug-ins

de la empresa.

En este caso nos limitaremos a comentar únicamente el paquete que nos interesa.

Para poder trabajar con los distintos tipos de dispositivos se han creado varias clases

que los representan, así como una clase abstracta que todos ellos extenderán y donde se

definen los métodos comunes que todos ellos deben implementar. Esta jerarquía de clases nos

permitirá también poder declarar métodos en los que se reciba un parámetro de la clase padre

que a la hora de la verdad será ocupado por una instancia de una de sus clases hijas (principio

de sustitución de Liskov).

Ilustración 20: Jerarquía de clases de los dispositivos

En el caso de la categoría se tratará de un simple contenedor de dispositivos. Más

tarde veremos que en la vista tendremos una categoría por cada tipo de dispositivo. Aquí

podemos comprobar la utilidad de la jerarquía de clases definida ya que se pondrá en uso en

citado principio de Liskov.

43

Ilustración 21: Clase Category

Esta clase tendrá un atributo type que nos permitirá saber qué clase de dispositivos se

almacenan en la categoría y nos ofrecerá métodos para añadir, eliminar y listar dispositivos,

comprobar si un dispositivo concreto se encuentra en la categoría, vaciarla…

La clase abstracta ofrecerá una serie de métodos comunes a todas las clases que la

extienden que serán los que nos permitan manejar los objetos en diferentes lugares

independientemente de la clase a la que pertenezcan.

Ilustración 22: Clase AbstractAndroidDevice

44

Como se puede observar solo habrá un método abstracto en esta clase, que será el

único que tengan que implementar las clases hijas. De hecho, salvo en la clase

NetworkAndroidDevice, no se necesitaran más atributos ni métodos.

Ilustración 23: Clase NetworkAndroidDevice

Aquí podemos ver que los dispositivos de red tienen ciertas características que hacen

necesaria la inclusión de algunos atributos y métodos para definir alguna de sus características

y para permitirnos aprovecha la funcionalidad ya existente para el manejo de dispositivos de

red proporcionada por Digi.

4.1.2.8 Contenedor de dispositivos

Dentro de la vista mostraremos los dispositivos en forma de árbol utilizando una

instancia de la clase TreeViewer de JFace [8]. Esta clase nos proporciona métodos para

manejar y organizar la información de una manera muy sencilla permitiéndonos abstraernos

de toda la lógica que conllevaría hacerlo directamente con SWT. Para poder aprovechar estas

ventajas solo tendremos que facilitarle a este elemento las clases mencionadas anteriormente

AndroidContentProvider y AndroidLabelProvider.

Se ha decido mostrar la información de esta forma porque se cree que la vista en

forma de árbol resultará más cómoda de cara al usuario a la hora de ver la información

disponible y su organización.

45

Ilustración 24: Jerarquía de la clase TreeViewer

46

5 Implementación

En este capítulo mostraremos de manera más concreta aspectos de la implementación de

las clases anteriormente definidas cuyo objetivo es proporcionar la funcionalidad esperada de

los diferentes plug-ins.

5.1 Creación de plug-ins

La creación de Plug-ins en Eclipse se realiza a través de los puntos de extensión, que son

interfaces definidas por la plataforma que cualquiera puede implementar para extender la

funcionalidad del programa.

Para definir un plug-in hay que configurar el MANIFEST.MF. Si lo abrimos con Eclipse

podremos observar varias pestañas en las cuales podremos especificar ciertos valores

necesarios, añadir puntos de extensión a implementar, definir puntos de extensión del plug-in

a través de los cuales otros podrán extender la funcionalidad de nuestro plug-in igual que

nosotros extendemos la funcionalidad de la plataforma, definir las dependencias necesarias…

Ilustración 25: Editor del MANIFEST.MF

En nuestro caso los puntos de extensión que vamos a implementar serán los siguientes

en el caso de los asistentes para la creación de proyectos:

47

Ilustración 26: Puntos de extensión de los asistentes

- newWizards: Sera el que extiendan los asistentes

- natures: Lo extenderá la naturaleza de proyecto que crearemos.

- projectNatureImages: Para especificar una imagen asociada a la naturaleza

- type: Este es un punto de extensión definido no por Eclipse sino por Digi para los

proyectos de ejemplo. Más adelante veremos que para la creación de este tipo de

proyectos nos ayudaremos con las clases creadas previamente por la empresa para

crear proyectos de ejemplo, lo que nos facilitará las cosas.

En el caso de la vista con el gestor de dispositivos el punto de extensión que necesitaremos

será el siguiente:

Ilustración 27: Puntos de extensión de la vista

48

Destacamos también en azul los puntos de extensión de las perspectivas, extendidos por

Digi y que serán utilizados por Eclipse para definir una serie de vistas a mostrar en función del

tipo de proyecto.

5.2 Naturaleza Android

Para crear una naturaleza propia debemos seguir los siguientes pasos:

- Añadir en el archivo MANIFEST.MF las siguientes dependencias.

Ilustración 28: Dependencias necesarias para la naturaleza

- Crear una clase que implemente la interfaz IProjectNature

[Com.digi.android.build.nature].

- Declarar la naturaleza en el archivo plugin.xml y asociarle una imagen.

Ilustración 29: Declaración de la naturaleza Android

49

5.3 Asistente de nuevos proyectos Android

Este asistente será el encargado de guiarnos por el proceso de creación de un proyecto

Android. Para ello extenderemos la clase Wizard de jface que implementa la interfaz IWizard

[Com.digi.android.build.wizards].

Dentro de esta clase implementaremos varios métodos. Los que más nos interesan son los

siguientes:

5.3.1 Constructor del asistente

En el constructor de la clase AndroidProjectWizard especificaremos el tipo de

proyecto, el título de la ventana del asistente y la imagen que aparecerá en la cabecera del

asistente.

Ilustración 30: Constructor de la clase AndroidProjectWizard

5.3.2 Método addPages

En este método añadiremos las páginas que formaran el asistente.

Ilustración 31: Método addPages de la clase AndroidProjectWizard

5.3.3 Método createProject

El método performFinish iniciará una serie de llamadas que desembocaran en la

creación del proyecto a través de distintas clases. En este método simplemente se llamara a

createProject y si todo va bien establecerá el proyecto recién creado como el proyecto activo.

50

El método createProject se encargará de crear el proyecto a través de la clase

ProjectBuilderOperation [Com.digi.android.build.internal].

Ilustración 32: Método createProject de la clase AndroidProjectWizard

5.3.4 Clase ProjectBuilderOperation

En el método createProject de esta clase lo primero que haremos será comprobar si el

proyecto ya existe y preguntarle al usuario si quiere sobrescribirlo haciendo uso de la clase

ProjectOverwriteQuery.

51

Ilustración 33: Comprobación de la existencia previa del proyecto

En caso de que el proyecto no existiese o de que el usuario confirme que quiere

sobrescribirlo eliminaremos el proyecto existente y tras comprobar el tipo de proyecto del que

se trata creamos un objeto de la clase ManagedProjectCreator.

Ilustración 34: Creación del proyecto a través de la clase ManagedProjectCreator

5.3.5 Clase ManagedProjectCreator

Será el método createProject de esta clase el que se encargue de crear el proyecto

creando una instancia de la clase DigiAndroidWizard que permanecerá oculta al usuario.

52

Ilustración 35: Método createProject de la clase ManagedProjectCreator

5.3.6 Clase DigiAndroidWizard

La clase DigiAndroidWizard extenderá del asistente de creación de nuevos proyecto

del ADT. Esta manera de crear el proyecto, aunque no es muy ortodoxa nos permite

abstraernos de las particularidades de este tipo de proyectos (archivos necesarios, estructura

de su contenido, organización de los mismos…) delegando el control y manejo de todas esas

características en la clase padre.

Esta ha sido probablemente la parte más complicada del desarrollo del proyecto ya

que no existen clases públicas que podamos utilizar para crear los proyectos. Para poder

utilizar el asistente del ADT hemos tenido que analizar el código del plug-in [9] hasta dar con la

clase que necesitábamos, y una vez hecho esto, tras analizar el código, al no contar con

métodos mediante los cuales pudiésemos especificar los parámetros necesarios hemos tenido

que utilizar el modo de depuración para encontrar los elementos de la interfaz del asistente

que necesitábamos rellenar.

53

Esta clase tendrá un único constructor que se limitara a llamar al constructor de la

clase padre.

Una vez hecho esto se llamara al método setProject apropiado dependiendo del tipo

de proyecto con el que estemos tratando. En este caso se le pasaran a este método todos los

datos recogidos en nuestro asistente.

Ilustración 36: Parámetros del método setProject para proyectos Android

Lo primero que haremos será recoger las páginas del asistente del ADT del cual

estamos heredando.

Ilustración 37: Páginas del asistente del ADT

Una vez hecho esto recogemos todos los elementos que componen cada una de las

páginas y vamos estableciendo los valores recogidos previamente en nuestras páginas.

Ilustración 38: Nombre y localización del proyecto

54

Ilustración 39: Selección del SDK del proyecto

Ilustración 40: Aplicación, paquete, actividad y versión mínima del SDK

55

Una vez hecho esto llamaremos al método performFinish en el que llamaremos a ese

mismo método de la clase padre y luego le añadiremos al proyecto la naturaleza creada

anteriormente [Naturaleza Android].

Ilustración 41: Método performFinish de la clase DigiAndroidWizard

5.3.7 Páginas del asistente de proyectos Android

Nuestro asistente tendrá dos páginas que crearemos extendiendo la clase WizardPage

[Com.digi.android.build.wizards.pages].

La clase que definirá la primera de estas páginas no tendrá ninguna lógica especial que

destacar salvo una pequeña validación de los campos por lo que no nos detendremos en ella.

Ilustración 42: Clase AndroidNameLocationPage

56

Ilustración 43: Pagina de nombre y localización

En esta primera página le permitiremos al usuario especificar:

- El nombre del proyecto

- La localización en la que se creara el proyecto

- La versión del SDK de Android que se utilizara en el proyecto

La segunda de las páginas tampoco tendrá ninguna lógica especial salvo la validación de los

campos.

En ella se podrá configurar:

- El nombre de la aplicación

- El nombre del paquete en el que se guardaran los archivos que formen el

proyecto.

- El nombre de la actividad principal si es que se quiere crear una.

- La versión mínima del SDK de Android con la que será compatible el proyecto.

57

Ilustración 44: Clase AndroidApplicationPage

Ilustración 45: Pagina de aplicación

58

5.4 Asistente de proyectos Android de ejemplo

Este asistente será muy parecido al anterior [Asistente de nuevos proyectos Android], solo

que en este caso se le permitirá al usuario seleccionar uno o varios proyectos de ejemplo a

modo de plantilla con la que poder dar sus primeros pasos en el desarrollo de aplicaciones

Android en el caso de que no tenga experiencia o de que quiera comprobar la manera en que

se implementa la funcionalidad explicada en el ejemplo seleccionado.

Como hemos comentado anteriormente en este caso extenderemos las clases ya

existentes de Digi para la creación de proyectos de ejemplo lo que nos facilitara las cosas.

Debido al gran parecido con el asistente anterior nos centraremos en las partes que los

distinguen.

En primer lugar cabe destacar que en este caso pueden crearse varios proyectos a la vez.

Esto será algo de lo que se encargaran las clases de Digi de las cuales heredaremos. Nuestra

única labor en este caso será añadir las comprobaciones necesarias en las clases

ProjectBuilderOperation, ManagedPojectCreator y DigiAndroidWizard para diferenciar estos

proyectos de los anteriores.

Salvo estas comprobaciones y los parámetros que se especificarán en el caso de los

proyectos de ejemplos el único cambio significativo será en el método setProject de la clase

DigiAndroidWizard.

Igual que antes, lo primero que haremos será recoger las páginas del asistente padre, que

será el mismo, solo que en este caso, al tratarse de proyectos de ejemplo las páginas que nos

interesan no serán las mismas.

Ilustración 46: Paginas del asistente del ADT para proyectos de ejemplo

Una vez las tengamos seguiremos los mismos pasos que con los proyectos nuevos,

buscar los elementos que nos interesan y establecer los datos recogidos anteriormente en

nuestra página.

Después de hacer esto el proceso será el mismo que con el otro asistente, se crearán

los proyectos y se les añadirá la naturaleza creada [Naturaleza Android].

59

5.4.1 Páginas del asistente de proyectos de ejemplo

En esta primera página del asistente le mostraremos al usuario una serie de proyectos

disponibles y le daremos la posibilidad de filtrarlos en función de la versión de Android con la

que sean compatibles.

Ilustración 47: Pagina de selección de ejemplos

Al marcar la casilla de verificación se le permite al usuario seleccionar entre las

versiones Android disponibles y se filtran los ejemplos mostrados. Además, al pinchar sobre un

ejemplo se le muestra al usuario una breve descripción de la funcionalidad que ejemplifica ese

proyecto.

60

Como ya hemos dicho anteriormente esta página extiende de SamplesPage, una clase

abstracta desarrollada por Digi anteriormente y que nos facilitara la labor. Para poder

aprovechar la funcionalidad que nos ofrece esta clase tendremos que asegurarnos de un par

de cosas.

Lo primero será implementar ciertos métodos abstractos declarados en la clase SamplesPage:

- getSamplePath: Devolverá el directorio en el que se encuentran los proyectos de

ejemplo.

- getWindowTitle: Devolverá el título de la ventana del asistente.

- getDefaultImageDescriptor: Devolverá la imagen que se muestra en la cabecera

del asistente.

- getSupportedPlatforms: Devolverá una lista con las versiones Android disponibles.

Lo segundo será crear unos archivos XML llamados “Project.xml”. Ahora veremos un ejemplo

para comprobar que campos se definen en ese archivo y para qué sirve cada uno de ellos.

Ilustración 48: Estructura de un archivo Project.xml

- Project: Englobara toda la información del proyecto y tendrá dos atributos

o Label: Sera el nombre con el que se mostrara el proyecto en la lista.

o Visible: Especifica si se quiere que el proyecto sea visible o no.

- Description: Una breve descripción del proyecto y la funcionalidad que pretende

ejemplificar (admite HTML por lo que podemos darle formato al texto).

- Type: Especificara el tipo de proyecto del que se trata. En nuestro caso el tipo de

los proyectos será “com.digi.android.build.DigiAndroidSample”.

- Id: Será un nombre que permita identificar a cada proyecto sin posibilidad de

confusión.

- Data_path: En el caso de que el código no se encuentra en la misma carpeta se

especificara la ruta hasta él.

61

- Platforms: Aquí se podrán enumerar las versiones de Android con las que es

compatible el proyecto. Será esta etiqueta la que nos permita filtrar los proyectos.

A partir de estos archivos la clase SamplesPage se encargará de analizar y procesar la

información y rellenar la primera página de nuestro asistente.

Una vez hayamos seleccionado los proyectos deseados podremos pasar a la segunda

página del asistente en la que se nos mostrara un breve resumen de los proyectos de ejemplo

seleccionados en la página anterior y que nos permitirá volver atrás para hacer los cambios

que consideremos oportunos o finalizar el asistente, lo que hará que comience el proceso de

creación de proyectos explicado anteriormente.

Ilustración 49: Página de resumen de los ejemplos seleccionados

62

5.5 Gestor de dispositivos Android (Vista)

Sera una vista de eclipse en la que mostraremos al usuario un listado en forma de árbol

con los dispositivos Android disponibles, ya se trate de dispositivos físicos (conectados por

USB), de dispositivos virtuales o de dispositivos conectados por red.

5.5.1 Creación de una vista

Para crear nuestra vista extenderemos la clase ViewPart que es una clase abstracta que

implementa las vistas de Eclipse. También implementaremos las interfaces ISdkLog (para

registrar los errores producidos mientras se procesa contenido del SDK) y

IDeviceChangeListener (para controlar cuando se conectan o desconectan los dispositivos)

[Com.digi.android.ui.views].

Lo primero que haremos en esta clase, en el constructor, será inicializar uno de sus

atributos, una instancia de la clase AvdManager, que nos servirá para poder manejar los

dispositivos virtuales:

Ilustración 50: Atributos de la clase DeviceManagerView

Al iniciarse Eclipse se llamara automáticamente al método createPartControl que será

el encargado de crear los elementos que compondrán la interfaz gráfica de la vista. En este

método crearemos un objeto de la clase Composite dentro del cual colocaremos todos los

elementos que vamos a necesitar.

5.5.2 Creación de las acciones

Primero crearemos todos los elementos de la clase Action que va a contener la vista.

Estos serán los objetos encargados de realizar las acciones que permitiremos llevar a cabo

sobre los dispositivos.

A modo de ejemplo mostraremos como se ha creado uno de ellos.

63

Ilustración 51: Creación de una acción

5.5.2.1 Crear dispositivo

Esta acción será la encargada de facilitar la creación de los dispositivos virtuales y los

conectados por red.

Ilustración 52: Crear dispositivo

64

En el caso de los dispositivos virtuales nos limitaremos a llamar al gestor de

dispositivos Android del ADT y dejar que sea el quien se encargue de hacer el resto.

Ilustración 53: Crear dispositivo virtual

En el caso de los dispositivos de red nos aprovecharemos de la funcionalidad ya creada

por Digi, ya que ellos disponen de clases que se encargan del manejo de estos dispositivos por

lo que nos limitaremos a ejecutar su código.

Ilustración 54: Crear dispositivo en red

65

5.5.2.2 Eliminar dispositivo

Esta acción será la encargada de facilitar la eliminación de los dispositivos virtuales y

de red.

Lo primero que haremos será comprobar si se trata de un dispositivo virtual o de red

haciendo uso del operador instanceof.

En el primer caso haremos uso del AvdManager creado en el constructor para

gestionar el proceso. A través de él recogeremos el dispositivo seleccionado en la vista, del

cual conocemos su nombre.

Ilustración 55: Gestión del dispositivo a través del AvdManager

Primero comprobaremos que el dispositivo no está en uso.

Ilustración 56: Comprobación de ejecución de dispositivo virtual

Una vez comprobado que el dispositivo no está siendo utilizado le pediremos al

usuario que nos confirme sus intenciones.

66

Ilustración 57: Confirmación para la eliminación del dispositivo virtual

Una vez tengamos confirmación por parte del usuario eliminaremos el dispositivo.

Ilustración 58: Eliminación del dispositivo virtual

Observamos que a la función se le pasa un segundo parámetro que se encargara de

registrar cualquier error que se produzca. También registraremos el resultado de la

eliminación una vez lo hayamos recogido.

En el caso de los dispositivos de red nos aprovecharemos una vez más de la

funcionalidad ofrecida por las clases existentes creadas por Digi.

Ilustración 59: Eliminación de dispositivo de red

67

5.5.2.3 Editar dispositivo

Esta acción será la encargada de facilitar la edición de la configuración de los

dispositivos virtuales y de red.

Si se trata de un dispositivo virtual volveremos a hacer uso del AvdManager para llevar

a cabo la acción, igual que hacíamos para crear dispositivos virtuales (Ilustración 53: Crear

dispositivo virtual).

Ilustración 60: Editar dispositivo virtual

En el caso de tratarse de un dispositivo de red, volveremos a utilizar la funcionalidad

proporcionada por Digi.

Ilustración 61: Editar dispositivo de red

5.5.2.4 Conectar dispositivo

Esta acción será la encargada de facilitar la conexión de los dispositivos virtuales y los

dispositivos de red al ADB.

En el caso de los dispositivos virtuales no mostraremos el código en esta ocasión por

ser muy extenso ya que hay que lanzarlos en el emulador pero el proceso en líneas generales

es el siguiente:

68

- Hacemos uso una vez más de AvdManager para recoger los datos del dispositivo

que deseamos arrancar.

- Creamos una instancia de la clase AvdStartDialog proporcionada por Digi que

facilita la gestión de ciertas configuraciones de los dispositivos virtuales.

- Una vez configurados esos parámetros recogemos en una lista los parámetros

configurados y algunos adicionales.

- Se arranca el dispositivo ejecutando una orden a través del método

Runtime.getRuntime().exec() al que le pasamos como parámetro la cadena

necesaria para lanzar este dispositivo en el emulador, como si lo hiciésemos desde

la línea de órdenes del sistema operativo.

Si se trata de un dispositivo de red el proceso será más sencillo gracias una vez más a las clases

proporcionadas por Digi. Haremos uso de la clase ADBTool.

Ilustración 62: Clase ADBTool

Esta clase ofrece varios métodos de utilidad, algunos de los cuales utilizaremos más adelante,

pero el que nos interesa ahora mismo es connectDevice().

Ilustración 63: Conexión de un dispositivo de red

69

5.5.2.5 Desconectar dispositivo

Esta acción será la encargada de facilitar la desconexión de dispositivos del ADB.

En el caso de los dispositivos virtuales no se encontró ninguna manera sencilla de

cerrar el emulador o de mandar una orden al ADB que hiciera que se cerrase.

Ante esta situación se propuso la posibilidad de identificar la ventana del emulador y

cerrarla mediante una orden de línea de comandos. Una vez encontrada la orden adecuada se

procedió a analizar el nombre de las ventanas del emulador y se extrajo un patrón. El resultado

fue el siguiente:

Ilustración 64: Desconexión de dispositivos virtuales

Para los dispositivos de red fue mucho más sencillo gracias al ADBTool de Digi.

Ilustración 65: Desconexión de dispositivos de red

70

5.5.2.6 Instalar aplicación

Esta acción será la encargada de facilitar la instalación de archivos apk en los

dispositivos.

Ilustración 66: Selección de archivos apk

El método runWithProgress se limitara a ejecutar la operación especificada en un hilo

separado.

Ilustración 67: Método runWithProgress

En encargado de llevar a cabo la operación será el método declareInstallRunnable con

ayuda una vez más de la clase ADBTool.

71

Ilustración 68: Método declareInstallRunnable

5.5.2.7 Tomar captura de pantalla

Esta acción será la encargada de facilitar la tarea de tomar capturas de pantalla de los

dispositivos.

En esta ocasión nos ayudaremos de la herramienta integrada en el ADT para la toma

de capturas de pantalla.

Ilustración 69: Captura de pantalla

72

Cabe destacar la gran ayuda que han supuesto tanto las herramientas proporcionadas

por el ADT como las proporcionadas por Digi, que han facilitado en gran medida la realización

de estas acciones. Sin ellas no habría sido posible llevar a cabo toda la implementación en un

tiempo razonable.

5.5.3 Adición de las acciones en la barra de herramientas

Tras crear las acciones las añadiremos a la barra de herramientas de la vista.

Ilustración 70: Inserción de elementos en las barras de acciones de la vista

El método getActionBars nos devuelve todas las barras de acciones de la vista, que son

tres, el menú, la barra de herramientas y la barra de estado. A nosotros de momento solo nos

interesa la segunda, pero si más adelante se decidiese añadir alguna entrada de menú o alguna

información en la barra de estado este sería el lugar indicado para hacerlo.

Nos serviremos del método fillLocalToolBar para añadir cada una de las acciones a la

barra de herramientas.

Ilustración 71: Inserción de las acciones en la barra de herramientas

El resultado es el siguiente:

Ilustración 72: Barra de herramientas sin dispositivo seleccionado

73

Ilustración 73: Barra de herramientas con dispositivo seleccionado

Ilustración 74: Barra de herramientas con dispositivo conectado

5.5.4 Vista en forma de árbol

Una vez hecho esto crearemos una instancia de la clase TreeViewer que nos permitirá

mostrar los dispositivos y las categorías en forma de árbol, de una forma clara y fácil de

entender de cara al usuario.

Ilustración 75: Creación de la vista de árbol

Una vez tenemos creada la vista configuramos las columnas que van a formarla.

Ilustración 76: Columnas de la vista de árbol

74

Para terminar con la vista (en lo que a aspecto se refiere) indicamos que no queremos

que se muestren los títulos de las columnas ni tampoco líneas separando los distintos

elementos.

Ilustración 77: Estilo de la vista de árbol

5.5.5 Categorías de dispositivos

La clase tendrá los siguientes atributos encargados de organizar los dispositivos con los

que estemos trabajando.

Ilustración 78: Declaración e inicialización de las categorías

Tras crear la vista en forma de árbol añadiremos las categorías en el array que las

contendrá. Esto se hace así porque será este array el que le permita a la vista establecer el

contenido a mostrar a través de las clases creadas con este propósito

[Com.digi.android.ui.internal].

5.5.6 Adición de dispositivos a la vista

Crearemos un método llamado fillList que se encargara de insertar los dispositivos

disponibles en las categorías de dispositivos virtuales y de red. Para ello como viene siendo

habitual haremos uso de las herramientas proporcionadas por Digi y por el ADT. Lo primero

que se hará en este método será vaciar todas las categorías para evitar que algún dispositivo

se aparezca dos veces.

75

Ilustración 79: Adición de los dispositivos de red a su categoría

Ilustración 80: Adición de los dispositivos virtuales a su categoría

Una vez recogidos los dispositivos llamaremos al método refreshList que se encargará

de actualizar la vista haciendo uso una vez más de una herramienta facilitada por Digi.

76

Ilustración 81: Método refreshList

Más adelante veremos cómo gestiona el árbol de dispositivos el contenido (a través de

la clase AndroidContentProvider) y como se rellenan los datos a mostrar (a través de la clase

AndroidLabelProvider).

5.5.7 Conexión y desconexión de dispositivos del ADB

Hasta ahora nos hemos centrado en los dispositivos virtuales y de red ya que los

dispositivos físicos no se pueden crear ni editar.

Ahora veremos como la implementación de la interfaz IDeviceChangeListener nos

permite controlar los dispositivos que se conectan/desconectan del ADB. Esto nos permitirá

modificar el estado de los mismos en el árbol de dispositivos.

Esta interfaz declara 3 métodos gracias a los cuales podremos controlar el estado de

los dispositivos en función del evento que se dispare.

En el caso de deviceChanged y deviceConnected haremos lo mismo, que será recoger a

través del Android Debug Bridge todos los dispositivos conectados y actualizar la información

mostrada en la vista.

En el caso de deviceDisconnected recogeremos el nombre del dispositivo del cual se

nos ha notificado su desconexión y actualizaremos su estado en la vista.

5.5.8 Proveedor de contenido

Como hemos comentado anteriormente haremos uso de la clase

AndroidDevicesContentProvider [Com.digi.android.ui.internal] para facilitar la gestión de los

elementos contenidos en el árbol de la vista.

77

Esta clase que extiende la interfaz ITreeContentProvider proporcionará varios métodos

que nos servirán para controlar los elementos de la vista.

- getElements: Dependiendo del elemento recibido devolverá una cosa u otra. En el

caso de recibir un array de categorías (que será el elemento mediante el cual

estableceremos el contenido del árbol) devolverá ese mismo elemento, si recibe

una categoría devolverá el listado de dispositivos que contiene, y por ultimo si

recibe un AbstractAndroidDevice devolverá null por tratarse de un elemento

terminal del árbol.

- getChildren: devolverá el resultado de llamar a getElements pasándole como

parámetro el elemento recibido.

- hasChildren: Devolverá true si se trata de una categoría y false en caso contrario.

5.5.9 Proveedor de etiquetas

En este caso será la clase AndroidDevicesLabelProvider [Com.digi.android.ui.internal] la

encargada de devolvernos el contenido de cada una de las columnas del árbol en función del

elemento recibido.

Esta función la llevara a cabo a través de dos métodos:

- getColumnImage: Este método recibe dos parámetros, el primero un elemento y el

segundo un índice de columna. A partir de esos datos controlaremos lo que se

mostrara en el árbol. Si se trata de una categoría y la columna es la primera (índice

0) devolveremos la imagen correspondiente al tipo de categoría que hayamos

recibido. Si se trata de un dispositivo y la columna es la primera devolverá la

imagen correspondiente al tipo de dispositivo del que se trate, igual que con las

categorías y si la columna es la tercera (índice 2) devolverá una bola roja o verde

en función de si el dispositivo está conectado o no.

- getColumnText: Este método recibe los mismos dos parámetros que el anterior,

pero lo que devuelve en este caso es un texto en lugar de una imagen. Si se recibe

una categoría y es la primera columna (índice 0) devolverá el nombre de la

categoría, y si es cualquier otro índice devolverá una cadena vacía. Si recibe un

dispositivo y es la primera columna devolverá el nombre del dispositivo, si es la

segunda devolverá el identificador del dispositivo, si es la tercera devolverá

“Connected” o “Disconnected” en función del estado del dispositivo y si se trata de

la cuarta devolverá la versión de Android del dispositivo.

5.5.10 Menú contextual

Para crear el menú contextual seguiremos un procedimiento muy parecido al seguido a

la hora de crear las acciones. De hecho serán los mismos métodos los que se encarguen de

78

llevar a cabo las acciones correspondientes según el caso, lo que nos permite tener una única

implementación que se utiliza en varios sitios, evitando así duplicidades y facilitando el

mantenimiento del código.

Crearemos las entradas del menú de la siguiente manera:

Ilustración 82: Creación de un elemento del menú contextual

Y una vez creados todos los elementos del menú los añadiremos de una manera similar

a como hacíamos con las acciones y la barra de herramientas.

Ilustración 83: Añadir entrada al menú contextual

5.5.11 Apariencia final del gestor de dispositivos

Una vez completado todo el proceso tendremos una vista desde la que podremos

gestionar todos los dispositivos disponibles.

Ilustración 84: Vista del gestor de dispositivos

79

Ilustración 85: Vista del gestor de dispositivos con el menú contextual

5.6 Problemas encontrados

El principal problema con el que nos hemos encontrado ha sido la falta de documentación.

Al hacer uso de Herramientas propias de ADT que no proporcionan una interfaz publica que

poder utilizar el proceso de utilización de las mismas ha resultado más complejo de lo

esperado.

Esta falta de métodos públicos con los que llevar a cabo ciertas acciones es la que nos ha

obligado a hacer las cosas de una manera poco ortodoxa como hemos visto en “Clase

DigiAndroidWizard”.

La manera de superar estas limitaciones ha sido mediante el análisis del código de las

clases de Android que nos hacían falta (AvdManager por ejemplo) y mediante el ensayo y error

en el caso que acabamos de mencionar [Clase DigiAndroidWizard] donde tuvimos que utilizar

el modo de depuración para ir viendo los elementos que se cargaban y su tipo hasta dar con

aquellos en los que debíamos insertar los datos.

80

6 Seguimiento del proyecto

En este capítulo veremos la comparación entre la estimación inicial y el tiempo real que ha

costado completar el proyecto.

Creación del DOP

Tiempo estimado: 5 horas

Tiempo real: 5horas

Planificación

Tiempo estimado: 5 horas

Tiempo real: 5 horas

Formación

Tiempo estimado: 40 horas

Tiempo real: 60 horas

Desarrollo de la memoria

Tiempo estimado: 80 horas

Tiempo real: 60 horas

Defensa del proyecto

Tiempo estimado: 5 horas

Tiempo real: desconocido

Captura de requisitos

Tiempo estimado: 5 horas

Tiempo real: 10 horas

81

Especificación de los requisitos

Tiempo estimado: 10 horas

Tiempo real: 15 horas

Análisis de casos de uso

Tiempo estimado: 10 horas

Tiempo real: 10 horas

Análisis de clases

Tiempo estimado 20 horas

Tiempo real: 35 horas

Desarrollo de diagramas de casos de uso

Tiempo estimado: 20 horas

Tiempo real: 10 horas

Desarrollo de diagramas de clases

Tiempo estimado: 10 horas

Tiempo real: 15 horas

Desarrollo

Tiempo estimado: 80 horas

Tiempo real: 120 horas

Revisión y pruebas

Tiempo estimado: 20 horas

Tiempo real: 20 horas

82

Dirección del proyecto

Tiempo estimado: 135 horas

Tiempo real: 130 horas

Análisis

Tiempo estimado: 45 horas

Tiempo real: 70 horas

Diseño

Tiempo estimado: 30 horas

Tiempo real: 25 horas

Implementación

Tiempo estimado: 100 horas

Tiempo real: 140 horas

TOTAL

Tiempo estimado: 310 horas

Tiempo real: 365 horas

Ilustración 86: Duración real del proyecto

36%

19%

7%

38%

Duración real del proyecto

Dirección del proyecto

Análisis

Diseño

Implementación

83

6.1 Problemas encontrados

En lo que se refiere al tiempo dedicado al proyecto ha habido un desfase importante entre

las horas estimadas y las reales debido principalmente a los problemas a la hora de encontrar

documentación en algunas ocasiones y al tiempo empleado en la implementación, que ha sido

superior al esperado a causa de esa falta de documentación, que ha hecho que algunas de las

funcionalidades tuvieran que implementarse a base de ensayo y error hasta encontrar los

elementos que necesitábamos.

En cuanto a los plazos estimados y la comparación con los reales no se ha comentado nada

ya que debido a causas laborales y personales el proyectante postergó la realización de la

presente memoria hasta el último momento lo que hace que la comparación entre los plazos

estimados y los reales no sea para nada representativa del desarrollo del proyecto.

6.2 Tareas no realizadas

En lo referente al proyecto en sí ha habido un cambio en lo referente a los productos

producidos ya que la vista en la que se quería poder seleccionar los componentes utilizados

por un dispositivo para cargar los drivers necesarios no se ha llegado a desarrollar. La falta de

información y de unos requisitos claros ha hecho que se renunciase no solo a su

implementación sino también a su análisis y diseño.

Lo único que se tenía claro sobre ese plug-in es que debía mostrar al usuario una serie de

componentes para que este seleccionara los que le interesaban y comprobar la información de

los componentes en base a archivos XML con información sobre los mismos. Estos archivos

llegaron a crearse basándose en un archivo de especificaciones físicas de los componentes.

Este documento, que era un borrador, resultó tener errores. Esto, unido al hecho de que el

código encargado de parsear estos archivos estaba siendo desarrollado por otras personas y

aun no estaba terminado hizo que se abandonase su desarrollo.

84

7 Conclusiones

En este capítulo reflejaremos la sensación que nos queda después de la realización del

proyecto y lo que hemos aprendido durante su desarrollo.

7.1 Conclusiones finales sobre el proyecto

La principal conclusión al término de este proyecto es que hay que hacer caso cuando

alguien con más experiencia te da un consejo. Siempre se nos repite que no dejemos las cosas

para el final, que luego cuesta más hacerlas, y nos lo sabemos de memoria, pero ponerlo en

práctica cuesta más, sobre todo en determinadas circunstancias.

Espero haber aprendido de lo sucedido y ser mucho más constante en los próximos

proyectos que se me presenten en el futuro.

En cuanto al proyecto en sí lo más destacable es haber podido aprender de gente que

trabaja de una manera muy profesional, aprender como organizan las cosas, como buscan

documentación, como afrontan los problemas que surgen a lo largo de un desarrollo…

He aprendido también que no hay que rendirse, que por muy complicado que parezca algo

siempre hay alguna forma de conseguir desarrollarlo, es cuestión de tener paciencia y buscar

información hasta encontrar lo que necesitamos

Otra cosa de la que me he dado cuenta es de lo complicado que puede ser integrar código

propio en una estructura previa bastante compleja y como la documentación del código puede

facilitar en gran medida esa labor.

85

8 Glosario

ADB: El ADB o Android Debug Bridge es una herramienta incluida en el SDK de Android que

permite comunicarse con dispositivos Android a través de la línea de comandos.

ADT: El ADT o Android Development Tools es un plug-in para Eclipse creado para facilitar el

desarrollo de aplicaciones Android.

Android: Es un sistema operativo basado en Linux diseñado principalmente para dispositivos

móviles con pantalla táctil.

API: Una API (Application Programming Interface, Interfaz de programación de aplicaciones) es

un conjunto de funciones o métodos que ofrece una biblioteca para ser utilizado por otros

como capa de abstracción.

APK: APK (Android application package file) es el formato de archivo utilizado para distribuir e

instalar aplicaciones Android.

AVD: Un AVD (Android Virtual Device) es un dispositivo virtual que utiliza el sistema operativo

Android y que se ejecuta en un emulador.

GUI: Una GUI (Graphical User Interface) o Interfaz Gráfica de Usuario es el medio mediante el

cual un programa le muestra información al usuario y le permite interactuar con ella de

manera visual a través de imágenes.

IDE: Un IDE (Integrated Development Environment) es un programa compuesto por un

conjunto de herramientas pensadas para facilitar el desarrollo de aplicaciones.

JFace: Se trata de un conjunto de widgets para realizar interfaces graficas construido sobre

SWT. Proporciona una serie de construcciones muy comunes en las GUI’s ahorrándole trabajo

al programador.

Principio de sustitución de Liskov: Cualquier instancia de una clase hija puede ser usada como

si fuese una instancia de la clase padre sin necesidad de conocer las diferencias entre ellas.

SDK: Un SDK (Software Development Kit) es un conjunto de herramientas de desarrollo de

software que le permiten al programador crear aplicaciones para un sistema concreto.

SWT: SWT (Standard Widget Tool) es un conjunto de componentes para construir interfaces

graficas en java desarrollado por el proyecto Eclipse.

Widget: Pequeña aplicación grafica cuya función es proporcionar información visual.

XBee: Es el nombre comercial dado por Digi a una familia de módulos de radio.

86

9 Bibliografía

“Eclipse in action” David Gallardo, Ed Burnette y Robert McGovern (Manning)

“Eclipse: Building Commercial Quality Plug-ins” Eric Clayberg y Dan Rubel (Addison Wesley

Professional)

“SWT/JFace in action” Matthew Scarpino, Stephen Holder, Stanford Ng, Laurent Mihalkovic

(Manning)

“Professional Eclipse 3 for Java Developers” Berthold Daum (Wiley)

87

10 Referencias de interés

[1] Digi: http://www.digi.es/

[2]Eclipse: http://www.eclipse.org/

[3] Puntos de extensión de Eclipse:

http://help.eclipse.org/juno/topic/org.eclipse.platform.doc.isv/reference/extension-

points/index.html

[4] ADT: http://developer.android.com/intl/es/tools/sdk/eclipse-adt.html

[5] ADB: http://developer.android.com/intl/es/tools/help/adb.html

[6] Android: http://www.android.com/

[7] XBee: http://en.wikipedia.org/wiki/XBee

[8] JFace: http://wiki.eclipse.org/JFace

[9] Código fuente de Android y ADT:

https://android.googlesource.com/

https://android.googlesource.com/platform/sdk/+/master/eclipse/plugins/com.androi

d.ide.eclipse.adt/src/com/android/ide/eclipse/adt