Que bueno fue poder haber asistido a la reunion del Grupo de Usuarios de Java de Costa Rica hoy en la Ulatina... aparte de que fuera una excelente oportunidad para conocer a otros desarrolladores en otras areas, fue excelente poder ver la exposicion de Ben Galbraith y de Dion Almaer.
Estos dos son de los mejores expositores que he visto en mi vida. Una claridad... tanto en los slides usados como en los ejemplos como en la interaccion entre ambos, el conocimiento que tienen... sin palabras!!! En cuanto al contenido de la presentacion bastante claro, empezando por una EXCELENTE introduccion a la necesidad de crear mejores experiencias de interactividad al usuario y como una interfaz no solo bonita, sino que cumpla con el objetivo del usuario puede marcar la diferencia (mostraron bastantes ejemplos). Ademas, fue impresionante ver el desarrollo que ha tenido AJAX y lo que esta pronto por salir... pude ver cosas que pense nunca poder ver en un browser sin correr una maquina virtual como el Flash Player o Java Virtual Machine. Igual... no cambio a Flex... aunque lo que vi fue bastante impresionante y esto ayuda a que todo se ponga mejor y haya mas competencias para brindar mejores experiencias a los usuarios.
Felicidades a Maricel la organizadora del grupo y su grupo de ayudantes... iniciativas de este tipo y otras que ya hay, son las que ocupamos para poder crecer como pais en conocimiento y tecnologia...
Por cierto, en la rifa del final me gane un excelente libro... Yaaayyy!!!
jueves, 23 de octubre de 2008
viernes, 17 de octubre de 2008
Pruebas - Integracion de Aplicaciones
Aunque nuestros desarrolladores de lado del servidor prueben su codigo, y nosotros probemos nuestro codigo (con flex unit, mercury, flexmonkey o lo que queramos usar) el proceso de integracion entre cliente y servidor es necesario probarlo con ambos capas interactuando juntas (no solo por aparte) y de manera continua y automatizada para comprobar cualquier cambio o problema que se pueda encontrar.
Con Flex el problema es que nuestros llamados son asincronimos y no tenemos idea cuando vamos a recibir la informacion de vuelta. Esto hace que nuestros tests usando FlexUnit (la principal unidad de pruebas para flex) pasen efectivamente aunque la respuesta del servidor no sea correcta (esto por la naturaleza sincronica del flexunit) ya que el assert no se ejecuta hasta que se regrese el llamado del servidor y la unica forma de arreglar esto es usando un pequeno hack con un Timer, que la verdad hace el diseno de pruebas complicado, tedioso y dificil de mantener.
En cambio utilizando la unidad de pruebas llamada Fluint tenemos una orientacion completa a llamados asincronimos. La naturaleza de la unidad es esa y falicita las pruebas no solo de llamadas remotas, sino tambien de creacion de componentes, integracion de componentes, etc. Su documentacion aunque no es la mejor es bastante buena y el codigo es abierto. Tiene ademas un Runner de las pruebas que es ejecutable en AIR, y genera reportes en archivos XML intepretables por parte de alguna herramienta que utilicemos para el continuous integration, como Cruise Control o Hudson.
En general Fluint cumple mas alla de mis expectativas ya que su soporte asyncronimo es perfecto para todo lo que ocupamos probar, a diferencia de lo que hacer FlexUnit. Mas adelante quisiera exponer un poco con herramientas de automatizacion de pruebas como Mercury o Flex Monkey que parece ser una excelente opcion open source para esto.
Todo esto como buenas practicas que desarrolladores de Flex deberiamos de tener en nuestro repertorio... Son cosas MUY importantes y que crearan un desarrollo mas fluido y tranquilo.
Aqui un pequeno y muy BASICO ejemplo para probar llamadas remotas:
/**
* Prueba, invocamos al metodo login de nuestro servicio con
* los parametros 'username y 'password'
* y se crea un responder de tipo TestRespoder que provee Fluint para
* poder saber quien recibira que en nuestro llamado
*/
public function testLoginService():void
{
var responder:IResponder = asyncResponder(
new TestResponder( handleResult, handleFault ) , 3000 );
var token:AsyncToken = remote.getOperation('login').send("username",
"password");
token.addResponder(responder);
}
/**
* Handle del result de la llamada. Hacemos el Assert.
*/
private function handleResult( data:Object, passThroughData:Object ):void
{
trace(data);
assertNotNull(data);
}
/**
* Handle del fault de la llamada. Inmediatamente despachamos un
* Fail del test.
*/
private function handleFault( info:Object, passThroughData:Object ):void
{
fail("Received fault from Server: " + info);
}
sábado, 4 de octubre de 2008
Integracion de Aplicaciones con Flex
Recientemente me solicitaron dar un training para desarrolladores de Flex para Java. Mi proposito era primordialmente presentar la herramienta de Flex a nuestros desarrolladores (que son bastantes) y a la vez enfocarme en la necesidad de estandarizar el proceso de la creacion de aplicaciones que utilicen ambas tecnologias.
Mi transfondo tecnico viene de Java y hace cuestion de dos anos le agregue a mi carrera el Flex. Fue una desicion dificil y confusa por la falta de conocimiento de dicha tecnologia, pero al final creo que tome la desicion correcta. Java y Flex es una mezcla excelente para la creacion de aplicaciones y tener un conocimiento en ambas tecnologias me ha podido dar una valor agregado para ofrecer.
Creo que en esto de aplicaciones con Flex y Java hay mucha tela que cortar. He hablado previamente de tecnicas como el remoting, llamadas asincronimas y otras cosas que nos permiten comunicarnos con el servidor para interactuar en nuestra aplicacion, sin embargo el sentido de este post va mas orientado al proceso y trabajo que tiene que haber para unir a estos dos juntos...
Flex como front end provee muchas ventajas que otras herramientas no pueden proveer en un 100%, empezando por que el virtual machine donde corre (Flash Player) esta instalado en mas de un 95% de las computadoras del mundo. Java, un lenguaje maduro, activo, con una comunidad de desarrolladores de mucha experiencia y que va rejuveneciendose poco a poco es una excelente desicion para construir aplicaciones transaccionales. La ventaja con Flex es que no solamente tiene que trabajar con Java, el puede trabajar con .Net, Ruby, PHP, etc... lo cual permite que la escogencia del servidor de aplicacion sea mas flexible.
Pero como dije.. este post no va en lo tecnico, que es mejor?, cual es mas rapido?, etc... este post va mas orientado al proceso de integracion entre Flex y una aplicacion de servidor, escrita en el lenguaje que usted quiera. Parte de mis conocimientos tecnicos hablare mas sobre java.
He podido trabajar en varias aplicaciones de tamano considerable en las que se usa Flex y una aplicacion en el servidor (Java en cada caso y ayude en una con PHP). En todos los casos noto lo mismo:
La integracion es la etapa mas dificil de todo.
Una incorrecta integracion hace que todo el desarrollo sea mucho mas lento. Podemos desarrollar nuestra aplicacion Flex en un dia y la aplicacion en el servidor en un dia tambien... y la integracion de algo sencillo puede tomar 2 dias mas...
Aqui una lista de razones por las que pienso esto pasa:
Otros pensamientos relacionados:
Espero poder ahondar en otros temas relacionados a esto en un futuro...
Mi transfondo tecnico viene de Java y hace cuestion de dos anos le agregue a mi carrera el Flex. Fue una desicion dificil y confusa por la falta de conocimiento de dicha tecnologia, pero al final creo que tome la desicion correcta. Java y Flex es una mezcla excelente para la creacion de aplicaciones y tener un conocimiento en ambas tecnologias me ha podido dar una valor agregado para ofrecer.
Creo que en esto de aplicaciones con Flex y Java hay mucha tela que cortar. He hablado previamente de tecnicas como el remoting, llamadas asincronimas y otras cosas que nos permiten comunicarnos con el servidor para interactuar en nuestra aplicacion, sin embargo el sentido de este post va mas orientado al proceso y trabajo que tiene que haber para unir a estos dos juntos...
Flex como front end provee muchas ventajas que otras herramientas no pueden proveer en un 100%, empezando por que el virtual machine donde corre (Flash Player) esta instalado en mas de un 95% de las computadoras del mundo. Java, un lenguaje maduro, activo, con una comunidad de desarrolladores de mucha experiencia y que va rejuveneciendose poco a poco es una excelente desicion para construir aplicaciones transaccionales. La ventaja con Flex es que no solamente tiene que trabajar con Java, el puede trabajar con .Net, Ruby, PHP, etc... lo cual permite que la escogencia del servidor de aplicacion sea mas flexible.
Pero como dije.. este post no va en lo tecnico, que es mejor?, cual es mas rapido?, etc... este post va mas orientado al proceso de integracion entre Flex y una aplicacion de servidor, escrita en el lenguaje que usted quiera. Parte de mis conocimientos tecnicos hablare mas sobre java.
He podido trabajar en varias aplicaciones de tamano considerable en las que se usa Flex y una aplicacion en el servidor (Java en cada caso y ayude en una con PHP). En todos los casos noto lo mismo:
La integracion es la etapa mas dificil de todo.
Una incorrecta integracion hace que todo el desarrollo sea mucho mas lento. Podemos desarrollar nuestra aplicacion Flex en un dia y la aplicacion en el servidor en un dia tambien... y la integracion de algo sencillo puede tomar 2 dias mas...
Aqui una lista de razones por las que pienso esto pasa:
- Falta de comunicacion entre los equipos de desarrollo. No se mantienen reuniones entre los equipos donde se definan que servicios, metodos, parametros y tipos de retorno se van a maneja o cambios que se hayan realizado. Esto hace que sea todo una caja negra, que se trate de integrar algo y se pasen parametros equivocados, que se llamen a metodos incorrectos, que se esperen valores distintos.
- Relacionado con lo anterior... no existe documentacion de los servicios expuestos por la aplicacion para ser accesados desde el front end. Si existiera una documentacion detallando descripcion, nombre del metodo, parametros, tipo de retorno, etc. que pueda ser accesado por todos los desarrolladores, en un solo lugar (wiki, etc.) facilitaria muchisimo la comunicacion y el desarrollo no se veria tan parado al hacer la integracion.
- No existen por lo general pruebas de integracion. Podemos crear JUnits para probar nuestros metodos en Java, podemos crear Flex Units para probar metodos en Flex, pero por lo general no existe un mecanismo para probar la integracion. Por que es necesario probar esto? Bueno.. aunque nuestros JUnits salgan correctamente, debemos recordar que en el medio (entre Flex y nuestro back end) hay una capa de comunicacion en lo que pueden pasar muchisimas cosas, desde tipos de datos no reconocidos, nombres incorrectos de metodos hasta problemas con el servidor, que debemos ser capaces de probar. Mi propuesta inicial es hacer Flex Units con soporte para operaciones asincronimas que sean ejecutadas desde la maquina del developer del Back End y se encarguen de llamar los metodos remotos. Si algo falla en esos tests units a la hora de interactuar con los servicios o metodos provistos por nuestro back end, podran ser revisados y corregidos por parte de nuestros desarrolladores. Los programadores en Flex mientras tanto, pueden continuar con otras tareas sin tener que esperar a que cada vez que algo falle, sean arreglados.
Otros pensamientos relacionados:
- Quien lleva la batuta a la hora de escoger que metodos o servicios se van a exponer en una aplicacion al front end? Sera tarea solo del back end o tarea del front end? Estoy convencido que es una tarea de ambos equipos y que la comunicacion tiene que ser clave y en doble via. Front End provee una perspectiva de lo que necesita ser ingresado por el usuario para funcionar, pero back end provee una vision completa de todo lo que ocurre en un sistema y no solo en una pantalla. Nada peor que una aplicacion disenada enteramente por pantallas.. de ahi mi consejo de establecer estos servicios y metodo de forma conjunta.
- Aunque de pereza y duplique el trabajo, es NECESARIO el uso de DTO's o Value Objects para comunicar informacion del back end al front end, sobre todo si se usa Remoting. Esto es necesario para evitar problemas con sesiones, enumeraciones y otras cosas que no esten aceptadas por Flex y que vayan a ser recibidas incorrectamete ademas nos permite obtener abstracciones mas exactas a lo que necesitemos.
Espero poder ahondar en otros temas relacionados a esto en un futuro...
sábado, 20 de septiembre de 2008
Flex Tag Cloud Component Version 0.1 - English Below...
Trabajando en un proyecto personal en AIR, encontre la necesidad de usar un componente de tipo Tag Cloud Lo primero que hice fue buscar por un componente hecho en Google, pero no pude encontrar nada asi que decididi empezar a disenar el mio. El resultado esta arriba.
El componente es rellenado con un Array de Tags. Un Tag es un objeto con tres propiedades: tagId,description y count; el primero un identificador unico y numerico del tag en caso que se necesite, el segundo la descripcion o texto del tag y el ultimo la cantidad de repeticiones de un tag, que indicaran el tamano del tag en el componente. Cuando se presiona un tag se despacha un evento tipo TagCloudEvent con la informacion del tag.
Aun no esta completo, se necesita trabajar en estilos y poner el codigo disponible en alguna forma, por ahora se puede bajar un SWC con el componente y el ejemplo.
Ejemplo
Componente
While working a personal project in AIR I ran into the need of using a simple sort of "Tag Cloud" component. I decided to "googled" out for a component already created but I wasn't able to find anything so decided to sit and create my own component.. it's not perfect and still needs a lot of work (specially with styles) but is functional...
The Component is filled with an array of Tag objects. A Tag object contains a numerical Id, a description and a count with the amount of appearances of the tag which is used to decide the size of it in the cloud. When a Tag is clicked a TagCloudEvent is dispatched with the information of the tag so that you can use that information to search or do what ever you need...
As I said there's still a lot of work needed to be done and will release it's code later, for now you can download the swc component and the example of how to use it.
Example
Component
miércoles, 30 de julio de 2008
Flex 4
UPDATE: Junio 1 2009, aqui pueden bajar el Flash Builder (antiguo Flex Builder) version que viene con un nuevo release del beta del Flex 4. Si busca sobre Catalyst aquí.
Saludos
Flex 4 (nombre de codigo Gumbo) se alista para entrar el proximo ano y ya se empiezan a visualizar ciertas cosas nuevas en el framework.
Lo que mas interesante me ha parecido es el manejo que piensan dar a los componentes. Me parece que ahora piensan dar mas "composicion" que "herencia" entre los componentes (esto viendolo ahorita) lo cual permitira hacer cosas mas elegantemente y donde se podran ver involucrados disenadores de manera mas sencilla. Pueden comprobarlo a traves de este video.
Su estructura en el manejo de estados tambien cambio me parece para hacerlo mas sencillo, se creo un nuevo namespace MXML 2009 lo cual en teoria permitiria el manejo de cosas nuevas y otras de la version 3 al mismo tiempo, tambien tiene compatibilidad nativa con nuevas funcionalidades del Flash 10 (en desarrollo aun), un nuevo formato para manejo de imagenes, etc, etc
Parece que esta actualizacion de Flex 3 a Flex 4 va a tener mucho mas cambios que del 2 al 3 lo cual implicara en los desarrolladores un esfuerzo mayor para empezar a aprender y dominar los cambios para estar listos para hacer uso de la funcionalidad que traiga.
En lo personal creo que Flex 3 estara por bastante tiempo mas, pero vale la pena ir enfilandose a los nuevos cambios para estar preparado para cuando sea necesario utilizarlo.
Mas informacion:
Sitio oficial
Cambios en los estados
Cambios en componentes
Saludos
Flex 4 (nombre de codigo Gumbo) se alista para entrar el proximo ano y ya se empiezan a visualizar ciertas cosas nuevas en el framework.
Lo que mas interesante me ha parecido es el manejo que piensan dar a los componentes. Me parece que ahora piensan dar mas "composicion" que "herencia" entre los componentes (esto viendolo ahorita) lo cual permitira hacer cosas mas elegantemente y donde se podran ver involucrados disenadores de manera mas sencilla. Pueden comprobarlo a traves de este video.
Su estructura en el manejo de estados tambien cambio me parece para hacerlo mas sencillo, se creo un nuevo namespace MXML 2009 lo cual en teoria permitiria el manejo de cosas nuevas y otras de la version 3 al mismo tiempo, tambien tiene compatibilidad nativa con nuevas funcionalidades del Flash 10 (en desarrollo aun), un nuevo formato para manejo de imagenes, etc, etc
Parece que esta actualizacion de Flex 3 a Flex 4 va a tener mucho mas cambios que del 2 al 3 lo cual implicara en los desarrolladores un esfuerzo mayor para empezar a aprender y dominar los cambios para estar listos para hacer uso de la funcionalidad que traiga.
En lo personal creo que Flex 3 estara por bastante tiempo mas, pero vale la pena ir enfilandose a los nuevos cambios para estar preparado para cuando sea necesario utilizarlo.
Mas informacion:
Sitio oficial
Cambios en los estados
Cambios en componentes
sábado, 28 de junio de 2008
Reflection en Actionscript - Parte 2 - A
Esta es la segunda parte del tutorial sobre reflection. Este esta mas orientado a aplicaciones de la vida real que le podemos dar a reflection. Voy a dividir la parte en dos por lo largo que toman la explicacion de los ejemplos.
Ejemplo 1:
Serializador
Problema:
Se ocupa serializar los objetos de una aplicacion en XML para ser enviados al servidor con sus respectivos valores, nombre de los campos y tipos de los mismos.
No se desean modificar las clases ya construidas.
Solucion:
Para empezar nuestro ejemplo vamos a tomar las siguientes clases de Actionscript. Son tres clases simples describiendo tres abstracciones distintas y sin relacion. Estas clases seran las que tendremos que serializar en un XML. Como no se quieren alterar las clases, se crea una clase utilitaria que se encargara de realizar esta serializacion.
A continuacion la descripcion de las clases:
Lo dificil de esta solucion (sin usar reflection) es que se tendria que crear un serializador para cada una de clases (ya que entre ellas no tienen relacion) para poder acceder a cada una de las variables o metodos que se tenga en cada clase (ya que todo esto es desconocido).
Pero con reflection las cosas cambias ya que en tiempo de ejecucion puedo averiguar los metodos, variables y accesors que tiene una clase. Con esto hacemos un metodo que reciba de parametro un objeto y utilizando describeType nos devuelve un XML con la descripcion completa de la clase y lo mejor es que podemos aplicar la solucion a cualquier clase que se quiera sin tener que hacer nada nuevo.
Masomenos algo asi es lo que nos devuelve la funcion describeType:
<type name="Perro" base="Object" isdynamic="false" isfinal="false" isstatic="false">
Este es el resultado de nuestra funcion pasando de parametro instancias de las clases Carro, Perro y Persona (en ese orden):
Ejemplo 1:
Serializador
Problema:
Se ocupa serializar los objetos de una aplicacion en XML para ser enviados al servidor con sus respectivos valores, nombre de los campos y tipos de los mismos.
No se desean modificar las clases ya construidas.
Solucion:
Para empezar nuestro ejemplo vamos a tomar las siguientes clases de Actionscript. Son tres clases simples describiendo tres abstracciones distintas y sin relacion. Estas clases seran las que tendremos que serializar en un XML. Como no se quieren alterar las clases, se crea una clase utilitaria que se encargara de realizar esta serializacion.
A continuacion la descripcion de las clases:
package serializador.classes
{
public class Perro
{
public var nombre:String;
public var raza:String;
public var peso:Number;
public var color:String;
public function ladrar():void
{
trace("guaw guaw!");
}
}
}
package serializador.classes
{
public class Carro
{
public var marca:String;
public var fabricante:String;
public var anho:Number;
public var motor:Number;
}
}
package serializador.classes
{
public class Persona
{
public var nombre:String;
public var apellidos:String;
public var edad:Number;
public var sexo:String;
public var altura:Number;
}
}
Lo dificil de esta solucion (sin usar reflection) es que se tendria que crear un serializador para cada una de clases (ya que entre ellas no tienen relacion) para poder acceder a cada una de las variables o metodos que se tenga en cada clase (ya que todo esto es desconocido).
Pero con reflection las cosas cambias ya que en tiempo de ejecucion puedo averiguar los metodos, variables y accesors que tiene una clase. Con esto hacemos un metodo que reciba de parametro un objeto y utilizando describeType nos devuelve un XML con la descripcion completa de la clase y lo mejor es que podemos aplicar la solucion a cualquier clase que se quiera sin tener que hacer nada nuevo.
Masomenos algo asi es lo que nos devuelve la funcion describeType:
<type name="Perro" base="Object" isdynamic="false" isfinal="false" isstatic="false">
<extendsclass type="Object">Esta es la funcion que hacemos:
<variable name="peso" type="Number">
<method name="ladrar" declaredby="Perro" returntype="void">
<variable name="color" type="String">
<variable name="raza" type="String">
<variable name="nombre" type="String">
</variable>
public static function serialize( item:Object ):XML
{
var descripcion:XML = describeType(item); // invoamos a funcion para describir la funcion. Nos retorna un XML
var root:XML = new XML("<Object type=\""+ descripcion.@name +"\"/>"); //Creamos un nuevo XML que devolveremos posteriormente.
for each (var variable:XML in descripcion.variable){//del XML navegamos por todos los elementos dentro del nodo de Variables
// Creamos un nuevo nodo, su nombre es el de la variable (cargada del XML), el tipo se carga igualmente de la descripcion que encontramos
// en el XML que genera describeType y el valor lo hacemos usando Introspeccion en el objeto pasado por parametro invocando la
// variable por medio de objeto[ variable ]
var node:String = "<property name=\"" + variable.@name + "\" type=\""+ variable.@type + "\">" + item[variable.@name] + "</property>";
root.appendChild(node);//agrega al nuevo XML
}
return root;//retorna nuevo XML con nuestra serializacion
}
Este es el resultado de nuestra funcion pasando de parametro instancias de las clases Carro, Perro y Persona (en ese orden):
<Object type="serializador.classes::Carro">Como dije anteriormente la ventaja de esta solucion es que podemos usar cuantos objetos queramos de distintas clases sin tener que alterar nada en nuestra funcion de serializar.
<property name="fabricante" type="String">Nissan</property>
<property name="marca" type="String">Maxima</property>
<property name="anho" type="Number">2003</property>
<property name="motor" type="Number">1300</property>
</Object>
<Object type="serializador.classes::Perro">
<property name="color" type="String">Cafe</property>
<property name="peso" type="Number">25</property>
<property name="raza" type="String">Bulldog</property>
<property name="nombre" type="String">Bruno</property>
</Object>
<Object type="serializador.classes::Persona">
<property name="altura" type="Number">1.6</property>
<property name="edad" type="Number">38</property>
<property name="apellidos" type="String">Muller</property>
<property name="sexo" type="String">Masculino</property>
<property name="nombre" type="String">Steven</property>
</Object>
lunes, 23 de junio de 2008
Reflection en Actionscript - Parte 1
Comienzo una serie de dos temas acerca de reflection en Actionscript y Flex.
Cuando hablo de Reflection no me refiero al efecto visual que se genera cuando una imagen o parte de la misma es reflejada en otra area.
El reflection al que me refiero es a la facultad de un programa para que en tiempo de ejecucion pueda examinar su estructura y la de su ambiente y poder modificar lo que hace dependiendo de lo que encuentre. Es una tecnica presente en lenguajes de programacion recientes.
En Java por ejemplo, la funcionalidad de reflection se encuentra dentro del paquete java.lang.reflection, de donde se encuentran toda una serie de clases y metodos para poder examinar la estructura clases y tomar desiciones basados en esa informacion. En Actionscript esta funcionalidad esta basicamente incluida en cuatro funciones que veremos mas adelante.
Debo admitir que el uso de reflection en nuestras aplicaciones no es algo de todos los dias, sin embargo las veces que es utilizada se presenta como una solucion muy elegante para ciertos problemas.
Un poco de mi experiencia personal con reflection:
Mi primer contacto con reflection fue hace como unos 5 a~nos. Ingresaba a laborar en una pequen~a empresa en Miami. No habian muchos empleados aunque si muchos clientes y sobre todo un sistema muy robusto y muy bien disenado que cumplia con todas las necesidades y mas de la empresa. El programador lider era un excelente arquitecto. Tenian un sistema que se conectaba a 6 distintos proveedores - con conectividad e interaccion distinta en cada uno - a traves de un framework inventado en la empresa, que con el uso de interfaces y de reflection lograba en tiempo de ejecucion descargar y cargar las librerias de conectividad e interaccion para los distintos proveedores y realizar la funcionalidad necesaria. Todo era configurado desde un XML y si se necesitaba agregar un nuevo proveedor, se creaba la nueva libreria (.jar en ese caso) y se agregaba en el XML. Reflection hacia toda la magia de la carga de las clases y de encajarlo todo dentro de la aplicacion sin tener que compilarla en ningun momento.
Luego pase a aplicar reflection dentro de aplicaciones Web y de escritorio. Cada vez era mas sencillo utilizar el reflection en las aplicaciones y agregar funcionalidad en tiempo de ejecucion sin tener que compilar mi aplicacion nuevamente. Con la ayuda de un gran libro logre ir aprovechando mejor la herramienta, hasta que migrando de Java a Flex, pude descubrir la funcionalidad que brinda Actionscript y logre anadirla en algunas aplicaciones.
Manos a la obra:
Actionscript provee en el paquete flash.utils una serie de funciones para manejar reflection:
describeType: Recibe un objeto como parametro y devuelve un XML con la descripcion de la clase de la cual es el objeto.
Supongamos que tenemos la siguiente clase:
Aplicamos describe type:
Salida:
Una vez que tengamos toda la informacion de la clase variables, accessors, metodos, super clase, etc; podremos ser capaces de acceder a la informacion o invocar los metodos que necesitemos.
getDefinitionByName: Recibe un String como parametro con el nombre completo de una clase y devuelve (si existe) un objeto del tipo clase asignada por parametro que puede ser casteada posteriormente como un Class.
Utilizando la misma clase Perro del ejemplo anterior:
Se crea una clase del tipo pasado en el String de parametro. Pueden ser clases del framework de Flex o de API de Actionscript o customizadas, como este caso. Solo se ocupa que se contenga la ruta completa (incluyendo el paquete)
El unico problema que tiene esto es que:
getQualifiedClassName: Recibe un objeto como parametro y devuelve un string con el nombre completo de la clase del cual es tipo el objeto.
Salida:
Objeto Creado de tipo: Perro
getQualifiedSuperclassName: Recibe un objeto como parametro y devuelve un string con el nombre completo de la super clase del cual es tipo el objeto.
Es parecido al ejemplo anterior.
Esto es todo por ahora, en el siguiente post presentare dos aplicaciones del mundo real que se le puede dar al reflection desde actionscript, uno un sencillo serializador de clases a XML y el otro una aplicacion que carga desde un XML distintos proveedores en tiempo de ejecucion y que permite anadir nuevos proveedores sin tener que compilar la aplicacion principal.
Cuando hablo de Reflection no me refiero al efecto visual que se genera cuando una imagen o parte de la misma es reflejada en otra area.
El reflection al que me refiero es a la facultad de un programa para que en tiempo de ejecucion pueda examinar su estructura y la de su ambiente y poder modificar lo que hace dependiendo de lo que encuentre. Es una tecnica presente en lenguajes de programacion recientes.
En Java por ejemplo, la funcionalidad de reflection se encuentra dentro del paquete java.lang.reflection, de donde se encuentran toda una serie de clases y metodos para poder examinar la estructura clases y tomar desiciones basados en esa informacion. En Actionscript esta funcionalidad esta basicamente incluida en cuatro funciones que veremos mas adelante.
Debo admitir que el uso de reflection en nuestras aplicaciones no es algo de todos los dias, sin embargo las veces que es utilizada se presenta como una solucion muy elegante para ciertos problemas.
Un poco de mi experiencia personal con reflection:
Mi primer contacto con reflection fue hace como unos 5 a~nos. Ingresaba a laborar en una pequen~a empresa en Miami. No habian muchos empleados aunque si muchos clientes y sobre todo un sistema muy robusto y muy bien disenado que cumplia con todas las necesidades y mas de la empresa. El programador lider era un excelente arquitecto. Tenian un sistema que se conectaba a 6 distintos proveedores - con conectividad e interaccion distinta en cada uno - a traves de un framework inventado en la empresa, que con el uso de interfaces y de reflection lograba en tiempo de ejecucion descargar y cargar las librerias de conectividad e interaccion para los distintos proveedores y realizar la funcionalidad necesaria. Todo era configurado desde un XML y si se necesitaba agregar un nuevo proveedor, se creaba la nueva libreria (.jar en ese caso) y se agregaba en el XML. Reflection hacia toda la magia de la carga de las clases y de encajarlo todo dentro de la aplicacion sin tener que compilarla en ningun momento.
Luego pase a aplicar reflection dentro de aplicaciones Web y de escritorio. Cada vez era mas sencillo utilizar el reflection en las aplicaciones y agregar funcionalidad en tiempo de ejecucion sin tener que compilar mi aplicacion nuevamente. Con la ayuda de un gran libro logre ir aprovechando mejor la herramienta, hasta que migrando de Java a Flex, pude descubrir la funcionalidad que brinda Actionscript y logre anadirla en algunas aplicaciones.
Manos a la obra:
Actionscript provee en el paquete flash.utils una serie de funciones para manejar reflection:
describeType: Recibe un objeto como parametro y devuelve un XML con la descripcion de la clase de la cual es el objeto.
Supongamos que tenemos la siguiente clase:
1: package 2: {3: public class Perro
4: { 5: 6: public var nombre:String;
7: public var raza:String;
8: public var peso:Number;
9: public var color:String;
10: 11: public function ladrar():void
12: {13: trace("GUAW GUAW");
14: } 15: 16: } 17: }Aplicamos describe type:
1: var bulldog:Perro = new Perro();
2: describeType(bulldog)Salida:
1: 2: <type name="Perro" base="Object" isdynamic="false" isfinal="false" isstatic="false">
3: <extendsclass type="Object">
4: <variable name="peso" type="Number">
5: <method name="ladrar" declaredby="Perro" returntype="void">
6: <variable name="color" type="String">
7: <variable name="raza" type="String">
8: <variable name="nombre" type="String">
9: </variable>
Una vez que tengamos toda la informacion de la clase variables, accessors, metodos, super clase, etc; podremos ser capaces de acceder a la informacion o invocar los metodos que necesitemos.
getDefinitionByName: Recibe un String como parametro con el nombre completo de una clase y devuelve (si existe) un objeto del tipo clase asignada por parametro que puede ser casteada posteriormente como un Class.
Utilizando la misma clase Perro del ejemplo anterior:
1: var clazz:Class = getDefinitionByName("Perro") as Class; //Puede ser getDefinitionByName("paquete.de.la.clase.Perro")
2: var miPerro:Object = new clazz();
Se crea una clase del tipo pasado en el String de parametro. Pueden ser clases del framework de Flex o de API de Actionscript o customizadas, como este caso. Solo se ocupa que se contenga la ruta completa (incluyendo el paquete)
El unico problema que tiene esto es que:
- El compilador, para reducir el tamano de los swfs no incluye en el swf final los archivos de clases que no son utilizadas en algun momento desde nuestra aplicacion. Esto quiere decir que si en ningun otro lado de la aplicacion se crea una nueva instancia de la clase Perro, esta no sera incluida dentro del SWF final y el uso de reflection generara error algo como "ReferenceError: Error #1065: Variable
is not defined. ". Esto le quita un poco la funcionalidad al reflection ya que te limita a clases que esten instanciadas dentro de la aplicacion. Sin embargo vamos a ver en el siguiente post como podemos crear aplicaciones utilizando reflection a las que podremos anadir funcionalidad en tiempo de ejecucion y sin tener que compilar la aplicacion principal.
getQualifiedClassName: Recibe un objeto como parametro y devuelve un string con el nombre completo de la clase del cual es tipo el objeto.
1: var clazz:Class = getDefinitionByName("Perro") as Class; //Puede ser getDefinitionByName("paquete.de.la.clase.Perro")
2: var miPerro:Object = new clazz();
3: 4: trace( "Objeto Creado de tipo: " + getQualifiedClassName(object) );
Salida:
Objeto Creado de tipo: Perro
getQualifiedSuperclassName: Recibe un objeto como parametro y devuelve un string con el nombre completo de la super clase del cual es tipo el objeto.
Es parecido al ejemplo anterior.
Esto es todo por ahora, en el siguiente post presentare dos aplicaciones del mundo real que se le puede dar al reflection desde actionscript, uno un sencillo serializador de clases a XML y el otro una aplicacion que carga desde un XML distintos proveedores en tiempo de ejecucion y que permite anadir nuevos proveedores sin tener que compilar la aplicacion principal.
Suscribirse a:
Entradas (Atom)
