GRAPHICS PROGRAMMING ON ANDROID DEVICES

Luisa Fernanda Hernández Ramírez Programa de ingeniería de Sistemas

Fundación Universitaria San Martín, (FUSM) Bogotá, Colombia

lufe.hernandez@gmail.com

Fabián Andrés Giraldo Giraldo Programa de ingeniería de Sistemas

Fundación Universitaria San Martín, (FUSM) Bogotá, Colombia

fabian.giraldo@gmail.com

Abstract— Mobile devices, especially those that handle Android operating system have been well received in recent years and are used to solve problems in real time. Nowadays some applications are being developed to support visual programming within these devices and mobile applications have been developed to accomplish this approach as Catroid and Scratch, since it has been proven through studies that allows graphical programming to gain more interest in software development and has supported applications for computers with Scratch, StarLogo and Alice. For these reasons is presented the design and analysis of an application that lets you to program using blocks from Android devices and allows the generation and execution of code in the Java language on a remote server.

Keywords: agents, mobile computing, block programming, visual programming, translator.

I. INTRODUCCIÓN En el siglo XXI el aumento de las tecnologías ha sido de

manera exponencial [1], cada vez se implementan métodos que permiten lograr actividades cotidianas reduciendo el esfuerzo aplicado y gran cantidad de herramientas con las cuales el hombre logra alcanzar sus objetivos. Con el auge de nuevas técnicas y tecnologías que permiten que se pueda interactuar día a día con la información, surgen los SmartPhones (teléfonos inteligentes) que se catalogan como dispositivos móviles avanzados, que en un futuro, reemplazarán lo que es el concepto del computador portátil, como herramienta de trabajo móvil [2].

Entre los sistemas operativos que manejan los teléfonos inteligentes y las tabletas se destaca uno llamado Android, el cual es de fuente abierta, es decir, permite acceder y modificar el código fuente, ocasionando mayor preferencia para muchos desarrolladores de software, además, se espera que Android se convierta en una de las mayores plataformas móviles en el futuro y que sea usada por otros dispositivos [3].

Una problemática que viene siendo atacada desde hace un tiempo es permitir a los desarrolladores programar desde estos dispositivos, así lo demuestran las aplicaciones Catroid [4] y Scratch [5] que permiten realizar animaciones y juegos por medio de bloques sobre celulares. Pero ¿qué sucede con las personas que desean resolver problemas de programación usando estructuras de control existentes en lenguajes de

programación tradicionales (while, for, if, etc.)?, en marzo de 2012 el equipo de Android innovó con una aplicación en el mercado llamada AIDE (Android Integrated Development Environment) [6] la cual permite crear un programa para Android por medio de comandos de textos y compilarlo directamente desde el mismo dispositivo, evitando la necesidad de emuladores que tomarían más tiempo.

Programar dentro de un dispositivo móvil por medio de comandos de textos puede ser un proceso bastante incomodo por el tamaño de la pantalla, además, se está expuesto a cometer errores sintácticos. Es más práctico desarrollar por medio de los lenguajes visuales, como se demuestra en el estudio realizado en el año 2006 por Wang et al., donde se afirma que el tiempo invertido por los estudiantes para programar por medio de bloques es menor que por comandos de texto, previniendo los errores que normalmente los frustraban y bajaban su interés en temas de desarrollo [7].

La programación basada en bloques es un enfoque que permite la integración de varios bloques para el desarrollo de las aplicaciones en un corto período de tiempo y sin las habilidades de codificación necesarias en la programación textual, generando una mínima cantidad de errores de sintaxis y de compilación [8].

Por estas razones, el objetivo de este artículo es mostrar el proceso de desarrollo y los beneficios de una aplicación para dispositivos Android a la que se le denominó GPLAD (Graphical Programming Language on Android Devices), la cual permite actualmente plantear programas bajo el paradigma de la programación estructurada a través de bloques y posteriormente gestionar la traducción en Java a través de un servidor remoto que se encarga de la generación de código, su ejecución y compilación, enviando esta información al dispositivo Android.

El presente artículo se encuentra estructurado de la siguiente manera: en la sección 2, se abarca el proceso de diseño y desarrollo de la arquitectura de GPLAD; en la sección 3, se expone la fase de construcción con cada una de las etapas y sus respectivos elementos necesarios para lograr el correcto funcionamiento de la aplicación; en la sección 4, se expone un problema y sus resultados, mostrando el paso a paso del procedimiento para lograrlo de manera satisfactoria; en la sección 5, se encuentra lo que se planea a futuro con

978-1-4799-1056-4/13/$31.00 ©2013 IEEE

GPLAD; finalmente en la sección 6, se exponen las conclusiones.

II. FASE DE DESARROLLO DE LA ARQUITECTURA Dentro de la construcción de GPLAD se implementaron

patrones (Factory, Façade, Decorator, Composite y MVC) que facilitaron la construcción de la plataforma de la aplicación.

Dentro del diagrama de componentes que se expone en la Fig. 1, se pueden evidenciar los componentes que fueron necesarios para la elaboración de GPLAD.

Figura 1. Diagrama de componentes de GPLAD

View contiene las clases necesarias para realizar el manejo de la comunicación a través de la aplicación, así como el despliegue de la interfaz de la aplicación, el menú principal y sus derivados.

Dentro de Blocks se encuentran las clases que son necesarias para la construcción de los bloques con cada una de sus propiedades, forma y la construcción del área de trabajo.

Piece tiene en su interior las clases que analizan los bloques construidos dentro del área de trabajo, para así generar la representación intermedia o el XML por medio de los bloques construidos, posee la clase que dibuja los bloques dentro de un Menú.

Agent tiene las clases necesarias para realizar la comunicación entre el dispositivo móvil Android y el computador.

Compilator contiene las clases que se encargan de tomar el XML generado por la aplicación y que es enviado por medio del agente para su respectivo proceso de traducción.

Los componentes de Database son los encargados de crear la persistencia dentro de la aplicación de los bloques que el usuario emplea, estas clases se encargan de obtener las figuras que están dentro del área de trabajo y las almacena en una base de datos SQLite para que siempre existan dentro de la aplicación.

III. FASE DE CONTRUCCIÓN Para poder concluir la construcción de la aplicación

mediante la arquitectura planteada fue necesario cumplir con las siguientes etapas:

A. Determinación del lenguaje específico de dominio Para la creación del Lenguaje Especifico de Dominio

(DSL) se tomó como referencia e inspiración el desarrollo visual de StartLogo TNG [9], el cual soporta el paradigma de programación por bloques, ayudando al usuario a respetar la estructura sintáctica del lenguaje usando figuras permitiendo que los bloques concuerden con otro único bloque.

Para construir el DSL gráfico se tuvieron en cuenta las capacidades, permisos, requerimientos y componentes de la aplicación. Se determinaron como componentes de vista: las pantallas principales, las pestañas del área de trabajo, los tipos y formas de bloques, los elementos gráficos para establecer la comunicación con el servidor, etc. Parte de esto se puede evidenciar en la Fig. 2, donde se ve la pantalla principal de GPLAD, a través de la cual el usuario puede ingresar al área de trabajo donde va a desarrollar por medio de bloques y también puede configurar el servidor por medio de la IP y el puerto.

Figura 2. GPLAD

La forma, el color y las coordenadas de los bloques fueron pensados a partir de figuras geométricas (cuadrado, círculo y triángulo) y se crearon clases que permitieron construir bloques con estas características y configurar su forma con parámetros según la necesidad como se observa en la Fig. 3. Para implementar y aplicar la interfaz de GPLAD como solución de programación estructurada, se seleccionaron funciones básicas (main, if, if/else, while, for, int, String, double, round, etc.); para exponer y desarrollar problemas de primeros cursos de programación y se crearon formas de bloques para cada uno de ellos.

Cada uno de los bloques fue construido según la necesidad de la estructura de programación que se implementaría. Las figuras deben tener coordenadas de orientación basadas en la Fig. 4, y se configuran con unos valores flotantes dentro del código.

Figura 3. Diagrama de clases de conectores en bloques

Figura 4. Orientación de los bloques

Para la construcción de los bloques existen tres categorías que determinan la forma de estos (Round, Sharp o Square) y cada una puede pertenecer a uno de los dos grupos (Connector o Slot).

Figura 5. Tipos de conexiones en bloques

En el lado A de la Fig. 5, se pueden observar las diferentes maneras para generar los espacios de encaje o Slots de cada uno de los bloques, proporcionándole a cada uno un estilo particular que le permita encajar sólo con los que debe. Las categorías Connector que se muestran en el lado B de la Fig. 5, le permiten a cada bloque tener la forma de conexión apropiada para poder encajar con los bloques que tengan el espacio o Slot respectivo.

Estas características son posibles por medio de instrucciones que se le indican a cada una de las categorías, por ejemplo, para crear un slot en un bloque se agrega la coordenada y se indica el tipo de Slot (sharpSlot, roundSlot, squareSlot). Por otro lado, para crear un conector en un bloque se agrega la coordenada y se indica el tipo de conector (Sharp, Round, Square).

De esta manera se crearon cada uno de los bloques de GPLAD, permitiendo generar estructuras básicas de variables, asignaciones, control, operaciones, etc., como se muestra en la Fig. 6. Todos los bloques que se encuentran en la categoría de operadores y los bloques de vectores tienen opciones desplegables para cambiar el operador o tipo de dato. Por ejemplo, el vector puede ser Int o String.

B. Representación intermedia a partir del lenguaje específico de dominio Para la configuración de los bloques expuestos en la

sección anterior se construyó un pseudocódigo de cada uno de ellos para determinar los datos necesarios y así establecer su forma. Cada bloque tiene una representación intermedia XML que es analizada para generar la traducción a Java en el momento en que el usuario lo solicite. Por ejemplo, para el caso del bloque MIENTRAS (ver Fig. 7) se planteó una forma en la figura que permitiera recibir los datos necesarios para el ciclo y generar un XML que respetara dichas reglas.

Figura 6. Bloques de GPLAD

Figura 7. Especificación del bloque "mientras"

Esta representación intermedia es obtenida capturando los bloques creados en el área de trabajo y almacenándolos uno a uno dentro de una colección de bloques, este proceso se hace de manera recursiva.

Se creó un DTD (Document Type Definition), el cual sirve para analizar la estructura que debe contener el XML que genera el aplicativo GPLAD. A partir de este DTD se verifica que la conformación de la representación intermedia esté acorde con él. Cada elemento está constituido por una serie de atributos que se pueden cumplir o tienen que ser requeridos para que se genere correctamente la traducción. Los valores #REQUIRED indican que el valor es requerido para que se realice, el valor #IMPLIED es un valor que puede ser opcional.

Figura 8. DTD de GPLAD

En la Fig. 8, se puede observar la parte del DTD correspondiente al bloque “mientras” de GPLAD. En los recuadros se muestran los elementos y atributos necesarios que debe o puede contener la figura, los cuales fueron expuestos con mayor detalle en la Fig. 7.

GPLAD genera un segundo árbol (dtdtree), el cual revisa y compara que se cumplan cada uno de los parámetros del DTD y el XML intermedio, además valida que se respete el orden que tienen las estructuras dentro del XML generado por GPLAD a fin de evitar problemas al momento de la traducción.

C. Diseño e implementación del traductor de código Para la generación del código, fue necesario definir un

mecanismo de extensión utilizando plugin con esquema de traducción entre lenguaje origen (Bloques) y lenguaje destino (Java).

Se hizo uso de dos tecnologías: MATRA [10], usada para leer la definición del lenguaje la cual se encuentra en un archivo DTD y JDOM [11] para leer el XML generado por GPLAD y el plugin del lenguaje Java con el que se va a trabajar.

El plugin del lenguaje Java es una estructura XML que posee atributos y subelementos; estos subelementos deben coincidir con los elementos del DTD, es por esto, que podrían implementarse plugins en cualquier otro lenguaje. El plugin del lenguaje contiene unas reglas para permitir la traducción de cada una de las estructuras interactuando con las variables que manejen. Este archivo se construye con símbolos como:

% = Define el nombre de la variable # =Indica el subtipo de un bloque @n = se usa para saltos de línea endchar = Cadena al final de los elementos Line = Saltos de líneas

Para continuar con el enfoque del bloque “MIENTRAS”, en la Fig. 9, se puede observar la parte del contenido del plugin del lenguaje Java correspondiente a esta figura, además, se ve la similitud y coherencia entre el DTD, el XML intermedio y el plugin.

Figura 9. Plugin java del bloque Mientras

D. Implementación y cominicación de Agentes Para realizarse el proceso de traducción debe existir

comunicación entre el dispositivo Android y el servidor remoto encargado de esta función, por lo tanto, se implementaron agentes para el envío de la representación intermedia, la generación y compilación del código generado.

JADE (Java Agent Development Framework), es una herramienta de desarrollo de sistemas multi-agente [12] y JADE Android es un paquete de software que permite el desarrollo de aplicaciones orientadas a agente sobre la base de la plataforma JADE para el sistema operativo Android [13].

Se crearon dos agentes, el primero llamado Android se encuentra dentro del dispositivo móvil y al segundo se le llamó Gplad y se encuentra del lado del servidor. Para el proceso de comunicación entre estos agentes, es necesario indicar la IP y el puerto; estos valores los digita el usuario, cumpliendo con el requisito que los dispositivos se encuentren conectados a una misma red.

Como se puede observar en la Fig. 10, al ser la conexión exitosa, se puede ver al agente de Android en el RMA (Remote Monitoring Agent), el cual permite de manera remota la gestión, monitoreo y control de los diferentes estados de los agentes [14].

Figura 10. RMA de GPLAD

Así como las propiedades de la creación del agente remoto son variables que pasan por toda la aplicación, el código también lo es. La creación del código XML generado se almacena en una variable que pasa por el agente para enviarlo como mensaje. Al recibir el mensaje, se verifica el tipo de lenguaje y se procede a enviar el mensaje al compilador para su generación.

Por otro lado, para enviar una respuesta del código traducido en Java y su resultado de compilación es el agente Gplad el encargado de enviar un mensaje ACL (Agent Communication Language) al agente Android, el cuál refresca la interfaz cada vez que un mensaje es recibido.

IV. FASE DE PRUEBAS Para el desarrollo de las pruebas se hizo uso de una tableta

Samsung con sistema operativo Android 4.0 a la cual se le instaló GPLAD, además de un computador portátil Lenovo con sistema operativo Windows 7, el cual de manera provisional contiene el traductor y funciona como medio remoto. Es de manera temporal, puesto que como trabajo futuro se establecerá como servicio web, es decir, para ser desplegada sobre la Web.

A. Planteamiento del Problema El aplicativo debe permitir desarrollar un programa que

genere un vector aleatorio de 10 números y reciba un número N que indique cuantas posiciones a la derecha se debe desplazar el vector y finalmente imprimirlo con el desplazamiento adecuado. Por ejemplo:

Datos de entrada: Vector = {1,20,12,41,35} y N=2 Datos de salida: Vector = {35,41,1,20,12}

B. Desarrollo por medio de bloques Con el objetivo de resolver el problema planteado en

GPLAD, se inició la implementación de los bloques correspondientes dentro del escenario según la lógica establecida para su solución.

Como se puede observar en las Fig. 11 y Fig. 12, se hizo

uso de bloques de control, operadores, variables, asignaciones, impresiones y vectores.

Figura 11. Parte Uno de la solución al problema dentro de GPLAD

Figura 12. Parte dos de la solución al problema dentro de GPLAD

C. Proceso de gestión de generación de código Una vez se implementaron los bloques con los respectivos

nombres, valores y lógica, se configuró la IP y el puerto, de acuerdo con la conexión de internet a la que se encontraban conectados el dispositivo móvil y el computador encargado de la traducción y compilación. Posteriormente se configuró el agente y se indicó el lenguaje en el que se desea obtener el código fuente (Java), obteniendo de manera inmediata dentro del dispositivo móvil su código fuente en Java y resultado de compilación.

Estos resultados también son desplegados en el lado del servidor junto con un archivo XML de la representación intermedia de los bloques generados en el área de trabajo de GPLAD (ver Fig. 13).

Figura 13. XML intermedio generado por GPLAD

Se puede observar en la Fig. 13, la representación XML intermedia de la unión de los bloques implementados en el escenario de GPLAD, esta representación varía según la solución que se plantee a través de las figuras en el área de trabajo.

D. Resultados La implementación y los resultados para desplazar N

posiciones a un vector de 10 números enteros aleatorios fueron satisfactorios. Como se observa en la Fig. 14, el código fue recibido y generado sin ninguna notificación de error, respetando los nombres y valores de las variables asignados en el área de trabajo de GPLAD (ver Fig. 11 y Fig. 12).

Figura 14. Código generado en Java

La variable que indica el número de posiciones a desplazarse se nombró n y se le asignó el valor 3, y como se observa en la Fig. 14, el resultado dentro del dispositivo móvil coincidió con las características del obtenido al ejecutar el código generado dentro de la herramienta IDE Eclipse [15] en un computador. Los valores variaron cada vez que se ejecutó el código puesto que se establecieron valores aleatorios y se probó por medio de variaciones en la variable n, que la solución fuera válida (ver Fig. 15.)

Figura 15. Resultados de las pruebas

BlockC [16] es una aplicación que compila el resultado de los bloques agregados dentro del área de trabajo en tiempo real, mientras que GPLAD una vez gestionada su traducción, genera código en java y lo compila, como se ha demostrado en las secciones anteriores. Los bloques de BlockC a diferencia de GPLAD, muestran código dentro de ellos, lo que podría confundir al usuario que desconoce la sintaxis del lenguaje, además, si se desea extender a otros lenguajes no se permitiría su reutilización.

V. TRABAJOS FUTUROS GPLAD es generadora de código Java, lenguaje sustentado

como uno netamente objetual, por lo cual será posible adaptar esta aplicación para que permita la POO (Programación Orientada a Objetos) en un futuro cercano. Adicionalmente, se está trabajando en complementar la aplicación, de tal manera que soporte matrices y métodos recursivos, además del paradigma de la Programación Orientada a Objetos.

VI. CONCLUSIONES Tras haber realizado la fase de pruebas con gran parte de

los bloques existentes en la aplicación se llegó a resultados válidos, concluyendo que GPLAD permite a los usuarios solucionar problemas de desarrollo por medio de bloques en tiempo real sobre dispositivos móviles Android y desplegándolos a su vez en un servidor remoto. Esto permite afirmar que la aplicación puede servir a los usuarios como

herramienta de trabajo de desarrollo de aplicaciones desde un dispositivo no convencional.

GPLAD permite abolir y evitar errores de tipo sintáctico y semántico de un lenguaje como Java, puesto que la aplicación a través de sus figuras que encajan en únicos bloques facilita que se invierta más tiempo en la lógica para la solución de problemas.

VII. REFERENCES [1] J. Allende, “El impacto del avance de las ciencias sobre la sociedad en

las primeras décadas del siglo XXI”. Facultad de Medicina, Universidad de Chile, 2007.

[2] J. O. Wobbrock, “The future of mobile device research in HCI. CHI workshop proceedings: What is the Next Generation of Human-Computer interaction?”, 2006, pp. 131-134.

[3] Gartner, “Gartner Says Worldwide Mobile Phone Sales Grew 35 Percent in Third Quarter 2010; Smartphone Sales Increased 96 Percent”, disponible en: <http://www.gartner.com/newsroom/id/1466313>, acceso 10 de Marzo de 2013.

[4] Catroid, disponible en: <http://catroid.org/catroid/index/1>, acceso 10 de Febrero de 2013.

[5] Scratch, “Acerca de Scratch”, disponible en: <http://info.scratch.mit.edu/es/About_Scratch>, acceso 10 de Febrero de 2013.

[6] C. Perez, “AIDE, entorno para programar aplicaciones Android en el propio smartphone”, disponible en: <https://play.google.com/store/apps/details?id=com.aide.ui>, acceso 10 de Febrero de 2012.

[7] K. Wang, C. Mccaffrey, D. Wendel and E. Klopfer, “3D Game Desing with Programming Blocks in StarLogo TNG”, in ICLS: Proceedings of the International Conference on Learning Sciences. International Society of the Learning Sciences, 2006, p.1008-1009.

[8] H. Mohamad, A. Patel, R. Latih, Q. Qassim, and L. Na. “Block-based Programming Approach: Challenges and Benefits”, ICEEI. TewConference: International Conference on Electrical Engineering and Informatics, 2011.

[9] Mit, “StarLogo TNG”, disponible en <http://education.mit.edu/projects/starlogo-tng>, acceso 6 de Septiembre de 2012.

[10] Matra, “An XML DTD Parser Utility”, disponible en: <http://matra.sourceforge.net/>, acceso 26 de Febrero de 2013.

[11] Jdom, “Mission”, disponible en: <http://www.jdom.org/mission/index.html>, acceso 30 de Marzo de 2013.

[12] Jade, “Java Agent Development Framework”, disponible en: <http://jade.tilab.com/>, acceso 25 de Agosto de 2012.

[13] Android Freewarelovers, “Jade Android”, disponible en <http://www.freewarelovers.com/android/app/jade-android>, acceso 25 de Agosto de 2012.

[14] P. Morales, “Sistemas Multiagente”, MaSE. España, Universidad de Vigo. Escuela Superior de Ingenieria Informatica, 2003.

[15] Eclipse, disponible en: <http://www.eclipse.org/>, acceso Marzo 22 de 2013.

[16] Federici, S., & Minimal, A. (2011). Drag-and-Drop Implementation of the C Programming Language. Proceedings of the 2011 conference on Information technology education, 191-196.