Capítulo 3: Herramientas Utilizadas

Transcripción

1 Capítulo 3: Herramientas Utilizadas

2 3 HERRAMIENTAS UTILIZADAS 3.1 Entorno de Desarrollo de Android En este apartado se expone el procedimiento a seguir para empezar a desarrollar y a entender las aplicaciones para Android Construcción del Entorno de Desarrollo Las especificaciones aquí descritas se basan en el sistema operativo Windows, y en el entorno de desarrollo Eclipse Juno. Aunque no es motivo de esta memoria, el SDK de Android también puede correr en otros sistemas operativos como Mac OS X o Linux. Paso 1. Descarga e instalación de Java. En primer lugar descargaremos la última versión del JDK (Java Development Kit) desde la web de Oracle, que es un software que provee herramientas de desarrollo para la creación de programas en Java. En el momento de escribir esta memoria la versión más reciente disponible es la 7 update11, que debemos descargar para nuestra versión concreta de sistema operativo. Paso 2. Descarga e instalación de Eclipse. será la SR1. A continuación descargaremos la última versión de Eclipse Juno, que en nuestro caso Eclipse es un programa informático compuesto por un conjunto de herramientas de programación de código abierto multiplataforma para desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecido", opuesto a las aplicaciones "Cliente liviano" basadas en navegadores. Esta plataforma, típicamente ha sido usada para desarrollar entornos de desarrollo integrados (del inglés IDE), como el IDE de Java llamado Java Development Toolkit (JDT) y el compilador (ECJ) que se entrega como parte de Eclipse (y que son usados también para desarrollar el mismo Eclipse). Sin embargo, también se puede usar para otros tipos de aplicaciones cliente, como BitTorrent o Azureus. Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundación Eclipse, una HU-1

3 organización independiente sin ánimo de lucro que fomenta una comunidad de código abierto y un conjunto de productos complementarios, capacidades y servicios. Eclipse dispone de un Editor de texto con resaltado de sintaxis. La compilación es en tiempo real. Tiene pruebas unitarias con JUnit, control de versiones con CVS, integración con Ant, asistentes (wizards) para creación de proyectos, clases, tests, etc., y refactorización. Asimismo, a través de "plugins" libremente disponibles es posible añadir control de versiones con Subversion.[4] e integración con Hibernate. Paso 3. Descargar el SDK de Android. Es un kit de desarrollo de software o SDK (siglas en inglés de software development kit) es generalmente un conjunto de herramientas de desarrollo de software que le permite al programador crear aplicaciones para un sistema concreto, por ejemplo ciertos paquetes de software, frameworks, plataformas de hardware, computadoras, videoconsolas, sistemas operativos, etc. Es algo tan sencillo como una interfaz de programación de aplicaciones o API (del inglés application programing interface) creada para permitir el uso de cierto lenguaje de programación, o puede, también, incluir hardware sofisticado para comunicarse con un determinado sistema embebido. Las herramientas más comunes incluyen soporte para la detección de errores de programación como un entorno de desarrollo integrado o IDE (del inglés Integrated Development Environment) y otras utilidades. Los SDK frecuentemente incluyen, también, códigos de ejemplo y notas técnicas de soporte u otra documentación de soporte para ayudar a clarificar ciertos puntos del material de referencia primario. Con las últimas versiones, Google proporciona un paquete que contiene Eclipse, el SDK y varios de los componentes necesarios ya instalados (el paquete se llama ADT Bundle for Windows ). Paso 4. Descargar el plugin Android para Eclipse. Google pone a disposición de los desarrolladores un plugin para Eclipse llamado Android Development Tools (ADT) que facilita en gran medida el desarrollo de aplicaciones para la plataforma. Se puede obtener descargándolo mediante las opciones de actualización de Eclipse. HU-2

4 Paso 5. Configurar el plugin ADT. Una vez instalado el plugin, tendremos que configurarlo indicando la ruta en la que hemos instalado el SDK de Android. Para ello, iremos a la ventana de configuración de Eclipse (Window / Preferences ), y en la sección de Android indicaremos la ruta en la que se ha instalado. Paso 6. Instalar las Platform Tools y los Platforms necesarios. Además del SDK de Android comentado en el paso 2, que contiene las herramientas básicas para desarrollar en Android, también deberemos instalar las llamadas Platflorm Tools, que contiene herramientas específicas de la última versión de la plataforma, y una o varias plataformas (SDK Platforms) de Android, que no son más que las librerías necesarias para desarrollar sobre cada una de las versiones concretas de Android. Así, si queremos desarrollar por ejemplo para Android 2.2 tendremos que descargar su plataforma correspondiente. Con esta serie de pasos explicados, y si lo hemos seguido correctamente, habremos generado el entorno de desarrollo de Android de la mano de Eclipse, cuya pantalla principal mostramos en la Figura 3.1. Figura 3.1 HU-3

5 3.1.2 Estructura de un proyecto Android Android: En la Figura 3.2 vemos los elementos creados inicialmente para un nuevo proyecto Figura 3.2 En los siguientes apartados describiremos los elementos principales de esta estructura. Carpeta /src/ Esta carpeta, cuya estructura representamos en la Figura 3.3, contendrá todo el código fuente de la aplicación, código de la interfaz gráfica, clases auxiliares, etc. Inicialmente, Eclipse creará por nosotros el código básico de la pantalla (Activity) principal de la aplicación, que recordemos que en nuestro caso se llamará MainActivity, y siempre bajo la estructura del paquete java definido. Figura 3.3 Carpeta /res/ Contiene todos los ficheros de recursos necesarios para el proyecto: imágenes, vídeos, cadenas de texto, etc. Los diferentes tipos de recursos se distribuyen entre las siguientes subcarpetas: HU-4

6 Carpeta Descripción Contiene las imágenes [y otros elementos gráficos] usados en por la aplicación. Para definir diferentes recursos dependiendo de la resolución y densidad de la pantalla del dispositivo se suele dividir en varias subcarpetas: /res/drawable/ /drawable ldpi (densidad baja) /drawable mdpi (densidad media) /drawable hdpi (densidad alta) /drawable xhdpi (densidad muy alta) Contiene los ficheros de definición XML de las diferentes pantallas de la interfaz gráfica. Para definir distintos layouts dependiendo de la orientación /res/layout/ del dispositivo se puede dividir en dos subcarpetas: /layout (vertical) /layout land (horizontal) /res/anim/ /res/animator/ /res/color/ /res/menu/ /res/xml/ /res/raw/ Contienen la definición de las animaciones utilizadas por la aplicación. Contiene ficheros XML de definición de colores según estado. Contiene la definición XML de los menús de la aplicación. Contiene otros ficheros XML de datos utilizados por la aplicación. Contiene recursos adicionales, normalmente en formato distinto a XML, que no se incluyan en el resto de carpetas de recursos. Contiene otros ficheros XML de recursos de la aplicación, como por ejemplo /res/values/ cadenas de texto (strings.xml), estilos (styles.xml), colores (colors.xml), arrays de valores (arrays.xml), etc. No todas estas carpetas tienen por qué aparecer en cada proyecto Android, tan sólo aparecerán las que se necesiten. HU-5

7 Como ejemplo, para un proyecto nuevo Android, se crean por defecto los recursos mostrados en la Figura 3.4. Figura 3.4 Carpeta /gen/ Contiene una serie de elementos de código generados automáticamente al compilar el proyecto. Cada vez que generamos nuestro proyecto, la maquinaria de compilación de Android genera por nosotros una serie de ficheros fuente java dirigidos al control de los recursos de la aplicación. Es importante, dado que estos ficheros se generan automáticamente tras cada compilación del proyecto es importante que no se modifiquen manualmente bajo ninguna circunstancia. Podemos ver la representación de esta carpeta en la Figura 3.5. Figura 3.5 HU-6

8 A destacar sobre todo el fichero que aparece desplegado en la imagen anterior, llamado R.java, donde se define la clase R. Esta clase R contendrá en todo momento una serie de constantes con los ID de todos los recursos de la aplicación incluidos en la carpeta /res/, de forma que podamos acceder fácilmente a estos recursos desde nuestro código a través de este dato. Así, por ejemplo, la constante R.drawable.ic_launcher contendrá el ID de la imagen ic_launcher.png contenida en la carpeta /res/drawable/. Carpeta /assets/ Contiene todos los demás ficheros auxiliares necesarios para la aplicación (y que se incluirán en su propio paquete), como por ejemplo ficheros de configuración, de datos, etc. La diferencia entre los recursos incluidos en la carpeta /res/raw/ y los incluidos en la carpeta /assets/ es que para los primeros se generará un ID en la clase R y se deberá acceder a ellos con los diferentes métodos de acceso a recursos. Para los segundos sin embargo no se generarán ID y se podrá acceder a ellos por su ruta como a cualquier otro fichero del sistema. Usaremos uno u otro según las necesidades de nuestra aplicación. Carpeta /bin/ Ésta es otra de ésas carpetas que en principio no tendremos porqué modificar. Contiene los elementos compilados de la aplicación y otros ficheros auxiliares. Cabe destacar el fichero con extensión.apk, que es el ejecutable de la aplicación que se instalará en el dispositivo. Vemos dichos componentes en la Figura 3.6. Figura 3.6 HU-7

9 Carpeta /libs/ Contendrá las librerías auxiliares, normalmente en formato.jar que utilizaremos en nuestra aplicación Android. La Figura 3.7 muestra dicha configuración. Figura 3.7 Fichero AndroidManifest.xml Contiene la definición en XML de los aspectos principales de la aplicación, como por ejemplo su identificación (nombre, versión, icono, ), sus componentes (pantallas, mensajes, ), las librerías auxiliares utilizadas, o los permisos necesarios para su ejecución. Una pantalla representativa de este archivo lo podemos ver en la Figura 3.8. Figura 3.8 HU-8

10 3.1.3 Componentes de una Aplicación Android En este apartado definiremos una serie de conceptos básicos, necesarios para comenzar el desarrollo de aplicaciones en Android. Activity Las actividades (activities) representan el componente principal de la interfaz gráfica de una aplicación Android. Se puede pensar en una actividad como el elemento análogo a una ventana o pantalla en cualquier otro lenguaje visual. View Las vistas (view) son los componentes básicos con los que se construye la interfaz gráfica de la aplicación, análogo, por ejemplo a los controles de Java o.net. De inicio, Android pone a nuestra disposición una gran cantidad de controles básicos, como cuadros de texto, botones, listas desplegables o imágenes, aunque también existe la posibilidad de extender la funcionalidad de estos controles básicos o crear nuestros propios controles personalizados. Service Los servicios (service) son componentes sin interfaz gráfica que se ejecutan en segundo plano. En concepto, son similares a los servicios presentes en cualquier otro sistema operativo. Los servicios pueden realizar cualquier tipo de acciones, por ejemplo actualizar datos, lanzar notificaciones, o incluso mostrar elementos visuales (p.ej. actividades) si se necesita en algún momento la interacción con del usuario. Content Provider Un proveedor de contenidos (content provider) es el mecanismo que se ha definido en Android para compartir datos entre aplicaciones. Mediante estos componentes es posible compartir determinados datos de nuestra aplicación sin mostrar detalles sobre su almacenamiento interno, su estructura, o su implementación. De la misma forma, nuestra HU-9

11 aplicación podrá acceder a los datos de otra a través de los content provider que se hayan definido. Broadcast Receiver Un broadcast receiver es un componente destinado a detectar y reaccionar ante determinados mensajes o eventos globales generados por el sistema (por ejemplo: Batería baja, SMS recibido, Tarjeta SD insertada, ) o por otras aplicaciones (cualquier aplicación puede generar mensajes (intents, en terminología Android) broadcast, es decir, no dirigidos a una aplicación concreta sino a cualquiera que quiera escucharlo). Widget Los widgets son elementos visuales, normalmente interactivos, que pueden mostrarse en la pantalla principal (home screen) del dispositivo Android y recibir actualizaciones periódicas. Permiten mostrar información de la aplicación al usuario directamente sobre la pantalla principal. Intent Un intent es el elemento básico de comunicación entre los distintos componentes Android que hemos descrito anteriormente. Se pueden entender como los mensajes o peticiones que son enviados entre los distintos componentes de una aplicación o entre distintas aplicaciones. Mediante un intent se puede mostrar una actividad desde cualquier otra, iniciar un servicio, enviar un mensaje broadcast, iniciar otra aplicación, etc. Por supuesto, no en todas las aplicaciones aparecen todos estos elementos, pero todos deben ser considerados a la hora de de desarrollar una aplicación en Android, para lograr la funcionalidad que queramos conseguir. 3.2 Emuladores para Android Una vez montado el Entorno de Programación, sabiendo la estructura de una aplicación Android y conociendo sus componentes, el siguiente paso será por fin desarrollar la aplicación. Dependiendo de la documentación a la que hayamos tenido acceso y de nuestra habilidad como programadores, seremos capaces de desarrollar aplicaciones de mayor o menor complejidad. HU-10

12 No obstante, después de cada variación que hagamos a nuestra aplicación, el paso imprescindible será probar su funcionamiento. Para evitar volcar nuestro desarrollo en un dispositivo móvil cada vez que hacemos un cambio, existe una herramienta de gran utilidad llamada emulador, que recrea las condiciones del dispositivo móvil en concreto, permitiendo con cierta facilidad ejecutar nuestra aplicación sin necesidad de mayores pérdidas de tiempo Android Virtual Device (AVD) Al descargar e instalar el Android SDK en nuestro ordenador, por defecto se habrá descargado el Emulador perteneciente a dicho paquete (AVD), con lo cual, vamos a obviar en este punto el proceso de instalación, pues sería repetir el proceso de instalación del SDK. Los pasos a seguir para la utilización del AVD serían los siguientes: 1) Configuración del perfil de ejecución 2) Emulación de la aplicación Configuración del perfil de ejecución Accederíamos en la barra de herramientas al icono de Android Device Manager y nos saldría una pantalla como la presentada en la Figura 3.9. Figura 3.9 HU-11

13 Ahí tendríamos que elegir New para configurar un nuevo Dispositivo Virtual. El cuadro de diálogo mostrado en esta ocasión sería el mostrado en la Figura Figura 3.10 En este cuadro completaríamos los siguientes campos: AVD Name: Nombre del Dispositivo Virtual Device: Dispositivo comercial que se quiere emular Target: Versión de Android que se quiere utilizar para la emulación Emulation Options: Marcar Snapshot, para que en sucesivas emulaciones la velocidad de apertura del emulador sea más rápida. Bastará pulsar OK para que tengamos el emulador configurado. HU-12

14 Emulación de la aplicación Bastará con pulsar el botón derecho sobre el nombre del proyecto, elegir la opción Run As /Android Application del menú desplegable, tal como podemos observar en la Figura Figura 3.11 Esto nos llevará hasta una ventana, Figura 3.12, donde tendremos que elegir el AVD que hemos configurado anteriormente para la emulación de nuestro proyecto. Figura 3.12 HU-13

15 Una vez elegido el AVD adecuado, ya podremos ejecutar el programa, para ver el resultado de nuestra programación, pinchando el icono correspondiente a nuestra aplicación de la serie reflejada en la pantalla de menú de nuestro AVD. Figura 3.13 Figura 3.13 A modo de comentario podemos decir, que el AVD proporciona una comodidad a la hora de probar modificaciones en la aplicación, que evita el engorro de hacer pruebas sobre un dispositivo móvil físico. No obstante, dependiendo de la potencia del ordenador donde hagamos la emulación, la velocidad de ejecución puede llegar a ser demasiado lenta hasta el punto de convertir a AVD en un emulador prácticamente inoperativo o no apto para realizar pruebas constantes, debido al considerable tiempo que requiere la inicialización y la extremada lentitud en la ejecución de la aplicación, factores claves a la hora de comprobar el comportamiento del programa en tiempo real. HU-14

16 3.2.2 BlueStacks Es una alternativa más que aceptable al AVD, ya que se puede instalar en el mismo cualquier Aplicación. Se puede descargar directamente de Internet, ya que es de libre distribución, y además la instalación es bastante sencilla siguiendo los siguientes pasos: 1. Descargar BlueStacks desde Internet. Elegiremos guardar el instalador en el ordenador. 2. Ir a donde se haya descargado y ejecutarlo. Confirmar que queremos hacerlo si sale un aviso. 3. Hacer clic en la casilla I Accept the Terms in the License Agreement de la ventana de bienvenida del asistente de instalación. Luego avanzamos con Next. 4. Mantener habilitadas las casillas de la segunda ventana y pulsar Install. 5. Hacer clic en Finish cuando termine la instalación. Se abrirá la ventana principal de BlueStacks, que tiene un aspecto parecido al de la Figura Figura 3.14 HU-15

17 Si sencilla ha sido la instalación del programa, más sencilla es la instalación de la aplicación, bastará con ejecutar el archivo. apk, generado de la compilación del código fuente de nuestra aplicación mediante Eclipse. Pincharemos el icono de dicho archivo y automáticamente se instalará en BlueStacks. Una vez instalada, podremos ejecutar la aplicación, y comprobaremos para nuestra sorpresa que la velocidad de ejecución es bastante mayor que la obtenida con el AVD y muy parecida a la de un dispositivo móvil real. En la realización de este proyecto se ha utilizado tanto uno como otro emulador, si bien es verdad, que conforme se ha ido aumentando en complejidad, durante las pruebas de funcionamiento, el más utilizado, por acercarse más al modo de trabajo de un dispositivo móvil, ha sido el emulador BlueStacks. 3.3 Editor de Archivos XML Aparte de las herramientas para generación de la aplicación y realización de pruebas de funcionamiento, nos quedaría por mencionar una tercera herramienta, que ha sido también importante en el desarrollo de este Proyecto, es el Editor de Archivos XML. Esta herramienta se vuelve imprescindible en tanto en cuanto, el programa desarrollado para este Proyecto es un gestor de información, es decir, lee información (que va cambiando en tiempo real) de una fuente, la administra, y la muestra con un determinado formato en nuestro dispositivo móvil. La fuente de información de la que se alimenta nuestra aplicación, la constituyen distintos archivos XML y PNG, que conforme cambian las circunstancias, variarán y serán leídos de algún modo por nuestra aplicación. Aquí es donde cobra importancia un editor de archivos XML, puesto que los archivos de este tipo tienen que cumplir unas reglas, de manera que deben que estar bien formados y estar correctamente validados, proceso de supervisión del que se encarga un editor de archivos XML, como es el XPontus. HU-16

18 3.3.1 XPontus XML Editor XPontus XML Editor es un editor de texto de código abierto y multiplataforma para el lenguaje de programación XML que es extensible mediante plugins y tiene soporte para XPath 1.0 y 2.0. Su principal uso es validar DTDs, esquemas XML individuales o por lotes y Relax NG, así como para realizar transformaciones XSL a los formatos: HTML, XML, PDF y SVG. Además cuenta con las siguientes características como editor de texto: completado e indentación de código, resaltado de sintaxis, explorador de la estructura de un documento, etcétera. Conseguirlo e instalarlo es igual de fácil que utilizarlo, puesto que es un programa de libre distribución que se puede descargar de su sitio web, sin mayor problema, e instalarlo desde su icono de instalación aceptando, como suele ser normal los términos de uso. Una vez instalado, la apariencia de la pantalla principal es la que se muestra en la Figura Figura 4.15 HU-17

19 Sobre esta pantalla, en la ventna principal, podemos directamente desarrollar el código XML que queramos utilizar, o pegar directamente el código desarrollado en otro editor de texto. Conforme vamos creando el código, en la subdivisión de la izquierda se irá conformando el árbol de la estructura de nuestro archivo, lo que nos sirve como orientación, sobre todo en archivos de gran extensión. Cuando damos por concluido nuestro trabajo, la gran utilidad del XPontus reside en que podremos comprobar si nuestro código está bien formado (sigue las reglas básicas de XML establecidas para el diseño de documentos) y validado (Cuando creamos documentos XML válidos aumentamos su funcionalidad y utilidad) Para comprobar si el código está bien formado, pulsaremos en la barra de herramientas el tic verde. De la misma manera, para validar el código pulsaremos el tic rojo de la misma barra de herramientas. En la subventana inferior, obtendremos la información de si el código está bien formado y validado mediante sendos mensajes. Si esto es así, el archivo xml está listo para ser utilizado. HU-18