domingo, 14 de diciembre de 2008

Flash Catalyst

Update - Junio 1 2009
Para bajar el beta de Catalyst pueden hacerlo desde aquí. Mas info aquí
Se encuentra en versiones para windows y mac.

A pocas semanas de una presentacion mas oficial de Flash Catalyst (previamente conocido como Thermo) tuve la oportunidad de asistir a una presentacion sobre el tema en el Grupo de Usuarios de Adobe en Atlanta. Fue una excelente oportunidad para ver la herramienta, hacer preguntas y ver la respuesta de los disenadores y programadores acerca de la herramienta, quienes a final de cuenta son quienes van a utilizarla.
Para quienes aun no saben que es, Flash Catalyst es una herramienta ideada por Adobe para el diseno de aplicaciones RIA, donde se le ofrece a los disenadores la oportunidad de verse involucrados en el desarrollo de la aplicacion de una manera mas sencilla y directa. Actualmente un disenador puede entregarle a los programadores una guia de estilos, imagenes cortadas, skins, etc y es responsabilidad del desarrollador en Flex la de poner esos elementos dentro de la aplicacion, sabiendo de antemano que por regla de dedo para la mayoria de desarrolladores si una imagen quedo en el pixel 253 y el disenador la queria en el 250, es lo mismo; sin embargo los disenadores sufren al ver tales alteraciones a su diseno y se viene la lucha por que quede todo igual como se muestra en el diseno original.
Este tipo de escenario en Flex, se ve muy repetido y de ahi la necesidad de crear una aplicacion que le permitiria al disenador ingresar al flujo de trabajo de la aplicacion. Catalyst permitiria al disenador importar sus disenos desde un PSD o archivo de Ilustrador o Fireworks o incluso crear ciertos elementos basicos desde su IDE, a partir de ahi podra convertir sus disenos en ciertos componentes de Flex con unos cuantos clicks, por ejemplo... podemos tener una caja de colores y el disenador con un par de clicks, lo puede convertir en un boton de Flex y la herramienta por si misma generaria el codigo MXML necesario para eso, que sera provisto posteriormente al programador. Se podran tambien crear estados (que esto cambiara con el Flex 4 de la manera en que se maneja actualmente), animaciones, etc y todo a unos cuantos cliks de distancia.
Programador y disenador podran hacer cambios a los archivos MXML desde Flex Builder u otra herramienta y se supone que Catalyst sera lo suficientemente inteligente para reconocer esos cambios y procesarlos recreando asi los cambios en los archivos sin tener que hacer todo de nuevo, mejorando muchisimo el flujo e interaccion de diseno-programacion.

Status Actual:
  • Catalyst funciona unicamente con el Suite CS4.
  • Funciona unicamente con Flex 4 (que esta en etapa de prueba igualmente)
  • Funciona actualmente solo en Mac OSX
  • Se encuentra en una fase muy temprana de desarrollo y se espera sacar un release por ahi de finales del 2009.
Ventajas:

En mi opinion Catalyst podra:
  • Mejorar flujo y comunicacion entre disenadores y programadores.
  • Mejorar los procesos de desarrollo en empresas que utilicen ambos grupos.
  • Creacion de Prototipos (esto es lo que mas me gusta). Ya los disenadores e incluso personas de UX podrian crear prototipos funcionales sin necesidad de utilizar un programador o usar muy poco de ellos.
Este servidor tiene una copia de Catalyst con la que estara jugando en los proximos dias, mientras vaya encontrando cosas interesantes las pondre por aqui...
Saludos

viernes, 5 de diciembre de 2008

El Modelo Alfabetico

¿Quieres ser hombre completo,
hombre a prueba de alfabeto?
Se amable, activo, aseado,
bondadoso y bienhablado,
Claro, mas cauto en confianzas,
sordo a chismes. parco en chanzas,
libre en digna dependencia
del deber y la conciencia;
Experto en algo especial,
franco, fiel, firme, formal,
Grato, generoso, humano,
buen hijo, esposo y hermano,
ejemplo a la ingenua infancia;
Justo, jovial sin jactancia;
gentil en serios hechizos,
no en modas, polkas y rizos;
Leal a la Ley, laborioso,
modesto, no malicioso,
natural, noble en tu modo;
con orden y objeto en todo;
Paciente y perseverante
( Primer prenda del triunfante);
Patriota puro y pacifico;
puntual, no en parla prolífico
ni Quijote o Quejumbroso.
Se realmente religioso
sin superstición salvaje,
Sobrio en juicio, en boca, en traje;
Servicial muy tolerante
Útil, veraz, vigilante,
Valiente, no vengativo,
ni un Yoista repulsivo.
se exacto como un reloj
nunca zángano, ni Zafio;
se otro Washington, si hay dos;
y haz que diga tu epitafio:
Honro a Padres, Patria y Dios.

Rafael Pombo

lunes, 3 de noviembre de 2008

Smartfox Server - Servidor Juegos para Flash

Como muchos de los hits de este blog vienen de un blog dedicado a la creacion de juegos en Flash y Flex y como tengo un poco(muy poco) de experiencia en esa area sobre todo tratando con servidores para juegos o para chat, he decidido subir un pequeno codigo que crea una muy simple aplicacion en Flex que se encarga de conectarse a un servidor de juegos que se llama SmartFoxServer que es uno de los varios servidores de juegos para flash. Este esta basado en Java lo cual permite que el servidor corra en Linux, Windows o Mac OS sin ningun problema. La documentacion y ejemplos es bastante buena, aparte de un buen soporte del vendedor.
Este ejemplo funciona con la licencia gratuita del Smartfox Pro, que es para 20 usuarios concurrentes. Es una simple comunicacion de chat(envio de mensajes) entre varios usarios, conectados a un cuarto, aunque puede crecer utilizando variables de usuario, variables de cuarto ambas excelentes para la creacion de MMOs o Juegos masivos donde los usuarios ven como se mueven los otros usuarios en tiempo real... creacion de cuartos dinamicos, etc, etc, etc.
El servidor es muy completo, lo unico es que su escalabilidad no es tan sencilla aunque ahora se brinda una solucion con Terracota, una utilidad que nos permite tener varias maquinas virtuales en varios servidores, como si fuera una sola.

Codigo adjunto, la clase que maneja la interaccion es: SmartfoxInteraction.as, el servidor de SFS debe estar corriendo antes de ejecutar la aplicacion.
Saludos

jueves, 23 de octubre de 2008

Costa Rica Java User Group

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!!!

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:
  • 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.
Otra herramienta que he visto y me parece muy interesante es el uso de Mercury Pro, que viene con el Flex Builder y te permite crear pruebas de aplicaciones a modo de macros o robot, donde se graba una interaccion con una aplicacion y se graba toda la secuencia para probar que siempre de el mismo resultado. Igualmente si Flex Unit no te es funcional, puedes crear tu propia unidad de pruebas, talvez demore mas tiempo pero te dara mayor tranquilidad.

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

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:
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">
<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>
Esta es la funcion que hacemos:


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">
<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>
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.

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:



   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.

martes, 20 de mayo de 2008

Problema Integrando Flex y Flash (eventos del mismo tipo con clases distintas)

En el proyecto en que me encuentro laborando actualmente me salio uno de los errores mas raros que he visto.

Sintomas

1. Tenia un componente hecho en flash (swc) incluido en una clase de Flex.
2. El componente en flash despachaba un evento customizado y la clase en Flex no tenia ningun problema con el evento customizado.
3. Cuando interactuaba con el componente que se cerraba o se abria conforme se necesitara, recibia el siguiente evento:

TypeError: Error #1034: Type Coercion failed: cannot convert fl.events::ComponentEvent@dc0f4c1 to mx.events.FlexEvent.
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at fl.core::UIComponent/set visible()

El error es que se estaba intentando convertir un evento de tipo fl.core.UIComponent a un evento de tipo FlexEvent. Pero... el evento que teniamos conocimiento que despachaba el componente era de una clase distinta. Ademas revisando el codigo del componente cuando veiamos el error, no se estaba despachando ningun tipo de evento desde el componente.

Despues de revisar muchas veces el codigo, nos dimos cuenta que el problema se daba cuando al componente se le hacia visible=false.
Entonces se nos encendio el bombillo y nos pusimos a revisar la documentacion del ComponentEvent y del FlexEvent .

Problema

Al componente Flash hacer visible=false, se despachaba el evento ComponentEvent.HIDE cuyo tipo es "hide" y si se hacia visible=true despachaba un evento ComponentEvent.SHOW de tipo "show". Coincidentemente la clase FlexEvent tiene los tipos de eventos SHOW de tipo "show" y HIDE de tipo "hide". Como pueden observar tienen el mismo nombre. Pero al mismo tiempo nuestro contenedor en Flex tenia listeners para SHOW y HIDE pero de FlexEvent y al tener el mismo tipo o nombre, esos listeners en el Flex iban a ser invocados. Lo que sucede es que los listeners esperaban eventos de tipo FlexEvent y no de ComponentEvent.

Solucion

Agregue listeners directamente al componente para los eventos ComponentEvent.HIDE y ComponentEvent.SHOW e inmediatamente pare su propagacion (event.stopPropagation) para que no llegaran hasta el Flex, osea el contenedor del componente.

Moraleja

Para aplicaciones que vayan a usar componentes Flash en Flex:

1. Se debe programar a la defensiva.. es decir buscar prevenir cualquier situacion en la que algo del Flash API nos pueda dar conflicto con algo del Flex Framework sea un evento, una clase, etc.
2. Cuando se hagan eventos customizados debemos tratar de diferenciar los tipos de ellos lo mas posible, talvez anadiendo el nombre del paquete donde se encuentran.

En fin.. espero que de alguna forma pueda servirle a alguien..

sábado, 26 de abril de 2008

A Leer!!

Si hay algo que he aprendido estos anos de trabajar en programacion, es la necesidad de estar actualizado. Nada es mas importante para un programador que mantenerse al dia con lo ultimo y si se puede un paso adelante que los demas! Talvez no puedas hacerlo todo pero te dara un mejor panorama para pensar en mejores soluciones.
Ahora con el internet es muy sencillo ingresar a Google y buscar cualquier cosa y asi solucionar el problema X que tengas en un determinado momento. Sin embargo concuerdo con otros, en que es necesario leer un libro que talvez no te pueda resolver un simple problema, pero te va a dar las bases, te ayudara a profundizar y te permitara conocer mas la teoria.
Gracias a Dios mi esposa en este aspecto de comprar libros, siempre me ha apoyado al inviertir en libros y si, digo invertir porque es literalmente eso, invertir en la carrera profesional de uno para tener mejores opciones y mayor calidad de trabajo.
En lo personal leer desde una computadora me cansa mucho asi que lo que prefiero es tener el libro y poder llevarlo donde quiera.. rallarlo.. marcarlo.. subrayarlo.. ponerle notas. Eso me sirve - en lo personal - mas que tener un simple PDF y marcarlo ahi.
Por ahora presento un resumen de lo ultimos libros que he comprado y he estado leyendo, talvez alguno le pueda ser de provecho:



Joel on Software:
Uno de mis favoritos... nunca me habia divertido tanto leyendo un libro de tecnologia. Joel es un famoso programador y bloguero que en este libro toca muchos temas picantes en general sobre el mundo de la programacion y su conexion con lo corporativo. Formas de documentar, formas de hacer pruebas, como hacer mejor software (no importando el lenguaje), como ser mejor profesional, etc.. en un formato agradable y divertido y con un autor que SABE LO QUE DICE.
Un libro que me gustaria tener el dinero para comprarlo a todos mis companeros de trabajo.


Rich Internet Applications with Adobe Flex & Java (Secrets of the Masters)

Este libro lo consegui el ano pasado en la conferencia de AJAX en NY. Es hecho por 3 de los programadores de Java/Flex con los que recibi un curso de Flex y que al mismo tiempo respeto. Un enfoque distinto entrando mas hacia el Flex desde el lado empresarial que del lado de diseno. Este libro es caro pero es de los mejores que he comprado. La verdad si pudiera recomendar un libro para programadores de Java entrando a Flex no dudaria en decir que este seria lo mejor que podrian conseguir. En lo personal fue el que me termino de empujar en este mundo.



Advanced ActionScript 3 with Design Patterns

Este libro es pequeno. Solo con eso te sube la moral para seguir leyendolo. Los primeros capitulos no son tan interesantes pero luego se convierte en un libro que TIENE que ser leido por cualquier programador que quiera tomar el AS3 en serio. El mes anterior lo lei casi 3 veces. Es impresionate. Cada vez que se lee se pueden aprender cosas nuevas. El material es para programadores avanzados especialmente si vienes de lenguajes Orientados a Objetos.




Essential ActionScript 3.0
Excelente libro para el que quiera ingresar al mundo de ActionScript 3.0. Es bastante grande y al inicio puede ser un poco decepcionante ver tantas paginas pero poco a poco se le va sacando el jugo a tan excelente libro. Tiene muchos secretos y detalles que no se encuentran en cualquier lugar.

martes, 15 de abril de 2008

Diagramas de Secuencia Faciles

Algunas veces cuando desarrollamos aplicaciones que utilizan otros componentes o interactuan con otros servicios sean externos o internos, el diagrama de secuencia se convierte muy util para poder detallar y explicar el flujo y proceso que se debera seguir.
Talvez no todos tengamos el conocimiento detallado de como hacerlo ni el tiempo ni las herramientas para hacerlo, pero encontre este sitio practico y util para crear de una manera sencilla y practica estos diagramas de secuencia de forma gratuita. Pruebenlo.. esta muy practico y util y muchas veces podra salvarle a uno muchas horas tratando de explicar algo a uno mismo o a otra persona.... http://www.websequencediagrams.com/

martes, 11 de marzo de 2008

Data Binding

Update (2009-03-28): Una entrada mas reciente con un ejemplo

El data binding es una de las caracteristicas mas agradables que provee Flex.

Que es en realidad?

Es un mecanismo que permite que componentes y/o objetos escuchen a los cambios que ocurran en otra variable, objeto o funcion X.

Que permite?

Bueno, permite actualizar informacion en un objeto que escucha (y mostrar esa actualizacion si es necesario) en el momento en que una variable, objeto o funcion que es escuchada cambia su estado (osea alguna propiedad).

Como funciona?

La forma mas elemental ocupa de lo que se llaman Metadata, que es una sentencia especial reconocida por el compilador, que lo que hace es avisarle como debe tratar una cierta sentencia que sigue despues del tag. En el caso de binding se utiliza [Bindable] antes de una variable que se quiera 'bindear'. Los componentes en MXML bindean muchas de sus propiedades principales por default. Una vez que indicamos que una variable va ser bindeada, osea que otros objetos pueden llegar a escuchar cambios que se realicen en ella, procedemos a definir sus escuchas (que pueden ser cero, uno o muchos) Para reflejar esos cambios en MXML, se utiliza '{ variable_bindeada } '. En actionscript puro (no MXML) se usa otro tipo de forma como por ejemplo la clase BindingUtils que provee el framework de Flex.

Que es lo que pasa en realidad?

En realidad lo que es el binding en flex, es el patron Observer simplificado por el uso de Metadata [Bindable] y de { } o BindingUtils
El observer pattern indica una relacion entre dos objetos, en la cual uno notifica al otro u otros acerca de un cambio en su estado y los actualiza automaticamente.
Entonces explicando la teoria, el observador es la variable u objeto que definimos como Bindable

Ejemplos:

Base:

<Application>
<mx:TextInput id="texto1" x="50" y="20"/>
<mx:Label id="etiqueta1" x="50" y="40"/>
</Application>

MXML:
1. Reemplazo del Label:

<mx:Label id="etiqueta1" x="50" y="40" text="{texto1.text}"/>

2. Etiqueta mx:Binding

<mx:Binding source="ObjetoFuente.propiedadEscuchar" destination="ObjetoDestino.propiedad_actualizar" />

en este caso

<mx:Binding source="texto1.text" destination="etiqueta1.text" />

Actionscript:

 BindingUtils.bindProperty(ObjetoDestino, "propiedad_actualizar", ObjetoFuente, "propiedad_escuchar");

Ejm:
BindingUtils.bindProperty(etiqueta1, "text", texto1, "text");


Notas:

Aunque el codigo se vea tan sencillo, detras de todo esto de binding ocurren una gran cantidad de cosas que nosotros no vemos. El uso de binding genera muchisimos archivos y clases mas de lo que vemos y pueden ser vistas si compilamos la aplicacion con la opcion --keep-generated-actionscript que mantiene todos los archivos generados por el compilador que son abreviados por metadatas por ejemplo. Esto se genera debido a que se crean listeners y handlers de esos listeners para cada propiedad bindeada.

jueves, 6 de marzo de 2008

Seminario de Flex y Campamento... y lo mejor... GRATIS!!!

Alguna vez han sentido que han llegado a la cuspide de su carrera profesional? Ha llegado al tope de su conocimiento?? Si es asi... usted esta en problemas! Si usted piensa que ya ha alcanzado todo solo por tener un titulo colgado en una pared o por tener un buen trabajo.. pienselo dos veces... siempre hay algo mejor afuera para usted! Y no lo digo por la simple ambicion de tener mas.. lo digo por el hecho de querer ser mejor en toda area y no un simple conformista. Cual es su valor profesional en el mercado laboral? Es solo su titulo? Es solo un lenguaje lo que le da valor a usted? Entre mas cosas pueda anadirle a su curriculum pero mas importante a su cerebro y a su capacidad, mas oportunidades tendra de seguir avanzando profesionalmente.
Es por eso, que tal como habia dicho en un post anterior, la empresa donde trabajo actualmente esta preparando un evento de Flex para el publico en general.
En realidad son dos distintos, pero dentro de uno mismo :D

Lo primero, un seminario de 5 noches seguidas que empezara el 10 de marzo y terminara el 14 de Marzo. Todas las noches de 7 pm a 9 pm, en el auditorio de la Ulatina (que amablemente esta prestando sus instalaciones) y mencione que era GRATIS???? Gratis? Si.. gratis pero no como cuando te ofrecen una muestra gratis de un producto.. es GRATIS-GRATIS... El segundo es el 15 de Marzo, de 10 am a 3 pm. Gratis tambien.
El seminario seran 5 charlas teoricas y algo de practica con los fundamentos necesarios para aprender Flex...a distribuirse mas o menos asi:


Lunes:
Que es Flex?
Martes:
Componentes de Flex y ActionScript
Miercoles:
Manipulacion de Informacion
Jueves:
Eventos y Drag-n-Drop
Viernes:
Tópicos avanzados

Para Inscribirse aqui
Mas informacion aqui

El Camp Flex, es el evento principal a mi gusto.. en este esperamos que se llene el auditorio. Hicimos la solicitud a Adobe y muy amablemente estaran enviando un 'Evangelista' de ellos mismos para venir y dar una charla a todo el que quiera llegar... Mike Downey nos estara acompanando... Mike es uno de los principales propulsores de AIR, de Adobe. Una herramienta que permitira a los programadores de Flex o de Ajax crear aplicaciones para escritorio con todas las de la ley... solamente asistan al evento y podran ver TODO lo que podran hacer con esto. De verdad es algo increible!!! Tambien segun se me ha dicho nos presentara un demo de Thermo de 12 minutos... Que es Thermo?? Es a mi gusto una de las mejores herramientas que tendra adobe en unos meses que permitira la integracion del disenador grafico y del programador en flex en muy pocos minutos de una manera ASOMBROSA...!! Venga!! Compruebelo usted mismo.

Asi que ya no tiene excusa, si quiere crecer como profesional, si quiere tener mas valor en el mercado laboral, si quiere conocer mas, si quiere hacer algo mas productivo que ver tele y comer en el sillon despues del trabajo, algo mas productivo que despertarse a las 11 de la manana el sabado, acompanenos esta semana que viene, recuerde del 10 de Marzo al 14 de 7 a 9 pm. El 15 de marzo el evento con Mike Downey, de 10 am a 3pm....
Por cierto, mencione que todo es gratis???

Para Inscribirse aqui
Mas informacion aqui

sábado, 23 de febrero de 2008

Programacion Modular en Flex

Update: 2009-03-30: Hay un nuevo post con mas informacion sobre modulos

Hay un viejo dicho en el mundo informatico que dice "Divide y venceras". Entre mas podamos dividir los problemas mas facil sera resolverlos... entre mas podamos dividir la carne mas facil sera comerla... entre mas podamos dividir el trabajo mas rapido sale...bueno!!! Hay veces que ni diviendo el trabajo sale mas rapido.. a veces demora mas tiempo... pero bueno entienden la idea

Cuando tenia tiempo para jugar hace como 15 anhos, mis juguetes favoritos eran los Legos. Me fascinaba como podia ir usando distintas piezas para crear nuevos disenhos que en mi imaginacion eran copias autenticas y reales de algo que existia en la vida real. Todo lo que ocupaba eran las distintas piezas para crear un carro, una casa o un ascensor (si yo se! quien hace un asensor con Legos pero bueno...). El producto final estaba formado con distintas piezas y cada pieza tenia forma distinta y yo solo tenia que utilizarlas de la mejor manera.

Bueno, a partir de Flex 2, se anhadio una funcionalidad parecida, los modulos. Los modulos son aplicaciones Flex aparte que son cargadas en tiempo de ejecucion por parte de la aplicacion cuando s. Esto hace que se puedan brindar las siguientes ventajas (entre otras):
  • Se puede dividir el tamano de la aplicacion en multiples pedazos que seran cargados unicamente cuando se necesiten.
  • Se puede dividir el trabajo entre distintas personas de forma mas definida.
  • La separacion de funcionalidad es bastante mas clara a la hora de utilizar modulos.

Existen 3 formas o modelos distintos para crear modulos:



1. Se crea un proyecto para la aplicacion principal y dentro de ese proyecto se anhaden los distintos modulos.
2. Se crea un proyecto para la aplicacion principal y se crea un proyecto aparte donde se mantendran los demas modulos.
3. Se crea un proyecto para la aplicacion principal y se crea un proyecto aparte por cada uno de los modulos.

Y cual es la diferencia entre ellos???

Bueno... baso mi respuesta en lo que esta ocurriendo en mi trabajo con un proyecto bastante grande. Este proyecto es un hibrido entre unas aplicaciones Flash y unas en Flex. En realidad toda la persistencia de datos la basamos en Flex con Remote Objects (usando obligatoriamente por supuesto el Cairngorm...) La parte visual y bonita esta hecha en Flash, exportados como componentes .swc (algunos de tamanos considerables) y nos comunicamos entre Flash y Flex por medio de eventos... Suena un poco raro.. pero creanme que esto funciona muy bien. El caso es que dentro de la aplicacion se definieron varios modulos y cada uno puede usar componentes de Flash distintos o algunas veces se repiten.

La idea de utilizar modulos se da debido a que queriamos rebajar el tiempo de carga que tuviera la aplicacion. Si cargamos todos los componentes Flash de un solo en la aplicacion la misma tendria un tamano inmenso y por lo tanto los usuarios preferirian ir a otros lugares. En cambio si cargamos las librerias y los modulos solamente cuando el usuario los ocupe, esto nos ahorraria mucho tiempo de espera en el lado del usuario.

Si hubiesemos seguido el modelo 1 ocurriria lo siguiente:
Cargamos todas las librerias en el proyecto, ponemos los distintos modulos y la aplicacion principal todo junto. En realidad no hubieramos dividido nada. Logicamente talvez exista una division debido a los modulos pero fisicamente en tamanho hubiera quedado igual una aplicacion inmensa ya que la aplicacion cargaria todas las librerias desde el inicio.

Si hubiesemos seguido el modelo 2 ocurriria lo siguiente:
Cargamos todas las librerias de flash en el proyecto con los modulos. La aplicacion principal se ahorraria de cargar todas esas librerias al inicio, sin embargo todos los modulos referenciarian a todas las librerias aunque no las vayan a utilizar. Osea continua siendo lo mismo.

Y como escogimos el modelo 3 ocurre lo siguiente:
La aplicacion principal tendra las librerias que se necesiten usar. Cada modulo como esta en un proyecto aparte hara referencia solamente a las librerias que ocupe cargar. Cada modulo tendra conocimiento solamente de la informacion que necesita saber. Esto hace que cada modulo quede de un tamanho mas pequeno y que sus cargas se hagan de manera mas rapida.

Bueno ya mucha hablada... Como se usan los modulos?

Bueno se tiene la aplicacion principal o shell y se tienen los distintos modulos.
Los modulos se empiezan a desarrollar como Aplicaciones Flex. Se crea una nueva aplicacion, se desarrolla, se prueba y se procede manualmente a hacer un cambio en el archivo MXML principal (ya que hasta el momento sino me equivoco Flex Builder no tiene una forma de como desarrollar un modulo desde el inicio)
Se tiene algo asi:
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" >
<codigo comun y corriente.../>
<botones/>
<labels/>
<cromitos/>
<maripositas/>
<etc/>
</mx:Application>

Y se pasa a algo asi:
<mx:Module xmlns:mx="http://www.adobe.com/2006/mxml" >
<codigo comun y corriente.../>
<botones/>
<labels/>
<cromitos/>
<maripositas/>
<etc/>
</mx:Module>

Se compila y se genera un archivo .swf. Este se copia al folder donde estara el ejecutable del shell o aplicacion principal y en el shell se anhade un tag de ModuleLoader, algo asi:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" >
<mx:ModuleLoader url="nombre_modulo_generado.swf"/>
<codigo comun y corriente.../>
<botones/>
<labels/>
<cromitos/>
<maripositas/>
<etc/>
</mx:Application>
Eso es todo.

Que ocurre en el realidad?

Bueno el modulo es compilado como un SWF. Eso es todo lo que ocurre... es un swf pero no uno que se pueda ejecutar si se da doble click.. tiene que ser llamado desde otra aplicacion en un module loader. El module loader se encarga de cargar el modulo en la aplicacion.

Como me puedo comunicar entre la aplicacion principal (shell) y un modulo??

Bueno, los modulos pueden implementar interfaces lo que permitiria definir una interfaz y de acuerdo a los servicios que esa interfaz exponga el shell podra llamar a esos metodos y el modulo los ejecuta.
<mx:Module xmlns:mx="http://www.adobe.com/2006/mxml" implements="INTERFAZ">
codigo...
</mx:Module>

La otra opcion y que es la que yo prefiero... es a traves de eventos. Por que? Porque nos permiten bajar el acoplamiento entre modulo y shell.... Por que? Ya son muchas preguntas no...:) ? El utilizar eventos hace que el modulo despache o reciba eventos e igualmente que el shell reciba o despache eventos... eso lo hacen sin importarle si va a haber alguien que va a recibir o despachar ese evento, ellos sencillamente tienen la "buena voluntad" de querer comunicarse si alguien asi lo quiere. De esta forma se eliminan interfaces que se tengan que implementar o conocer mas de la cuenta los modulos, por ejemplo suponga que tiene 3 modulos distintos que se van a cargar en una misma aplicacion... cada uno implementa una interfaz distinta... saque cuentas todo lo que usted tiene que saber para poder comunicarse con el modulo. Usando eventos usted nada mas oye por un evento o despacha un evento.
Mas informacion sobre esto en este EXCELENTE LUGAR

Asi que si vas a iniciar una nueva aplicacion en Flex y vas a tener problemas de tamano talvez puedas considerar la idea de utilizar modulos para proveer a los usuarios una mejor experiencia.

Algunas notas:
  • Se pueden hacer Modulos desde Actionscript, sin embargo es mas sencillo hacerlo desde el MXML.
  • Se pueden cargar distintos modulos en tiempo de ejecucion, cambiando la propiedad url en el moduleloader e invocando el metodo loadModule() en el moduleloader.
  • Los modulos pueden ser descargados igualmente en tiempo de ejecucion con el metodo unloadModule() del module loader.
  • Existe algo conocido como un ModuleManager que se encarga de la carga de multiples modulos, es algo muy util ya que lo hace de una manera centralizada.

miércoles, 6 de febrero de 2008

Y no le gustaria algo mas...?

Quiere un mejor trabajo? Quiere tener mas posibilidades de conseguir uno? Quiere agregar mas a su curriculum? Quiere crear las aplicaciones mas completas para internet? Si es asi y estoy casi que seguro que si, siga leyendo hasta el final...

No soy quien para decirlo ni usted para escucharlo... pero 95% de las computadoras del mundo tienen el Flash Player instalado. Despues del boom que ha tenido AJAX, del cual mucha gente habla y habla de el y no sabe lo que es, las personas han cambiado completamente su perspectiva en cuanto a las aplicaciones web.

Ya se que quiere irse, pero siga leyendo mas abajo todavia...

Se ha empezado dar una orientacion a crear aplicaciones mas 'ricas' o completas donde el lado del cliente no sea un simple formulario vacio, esperando ser llenado o un banner color anaranjado gigantesco diciendo bienvenido, sino una interaccion mas rica y agradable por parte del cliente en cuanto a lo que es la interfaz grafica. Empezamos a ver aplicaciones como GMail (wow!!! se actualiza sin refrescar la pagina completamente), Google Maps (wow!! le puedo hacer zoom y si no estoy en dial-up unos segundos despues ver la imagen mas detallada) entre otras.

Un parrafo mas y llegamos a lo que a usted le sirve...

Estas aplicaciones estan creando un nuevo grupo de programadores, no son solamente disenhadores graficos los que se estan metiendo a hacer aplicaciones web bonitas, son programadores con muchos anhos de experiencia, que vienen de transfondos con lenguajes fuertes de programacion como Java o .Net. Son aplicaciones completas, donde se programa de verdad, se hace uso de patrones, de buenas practicas, etc. Sea Flex, sea Silverlight o la herramienta que usted quiera, la demanda por programadores de este tipo esta creciendo a nivel mundial y es necesario que se empiece a capacitar y preparar gente para que cuando esta ola de trabajo llegue a Costa Rica la demanda de recursos pueda ser satisfecha.

Es por esto que en la empresa donde trabajo han tenido la genial idea de dar algunas capacitaciones abiertas al publico en general sobre temas como Actionscript 3, Flex o Flash. Nosotros estamos incluidos entre esas empresas que estan buscando personal capacitado para cumplir con tareas orientadas a aplicaciones web ricas, como esta... Incluso se planea un evento importante con gente de Adobe para tener un dia campamento de inicio en la materia. Les aseguro que va a valer la pena y que sera pronto. Les aseguro que una vez que esten dentro de esto, no van a querer salirse...

Si usted es uno de los que dijo que si a las preguntas de arriba, pues mantengase informado por aqui o deje un comentario con su email para mantenerlo al tanto del asunto. Muchos no tienen nada de que hacer despues del trabajo mas que ir a sentarse y ver tele... Salga de la rutina, estimule su cerebro, agreguele mas conocimiento y aumente su curriculum. En unos meses vera como se le abriran mas puertas para mejores empleos...sino es que se le abren antes por aqui...

miércoles, 23 de enero de 2008

Eventos en Flex

Los eventos en AS3 son a mi parecer la clave que permite crear RIAs interactivas, agradables y completas.
Un evento es generado la mayor cantidad de veces por la interaccion del usuario (tambien conocido como gestos) con el sistema (un boton, un campo de texto, cualquier interaccion que se haga por mouse o teclado). Algunos eventos son generados por el sistema automaticamente.
Los eventos son maneras eficaces para realizar aplicaciones con un acoplamiento bajo, esto debido a que la comunicacion se da a traves de ellos, un componente dispara un evento y solo se preocupa por eso. Si algun otro componente o contenedor ocupa de ese componente recibira el evento y procedera a realizar la funcionalidad que requiera con ese evento y la informacion que el contenga, sin conocer absolutamente nada del componente ni siquiera saber quien lo envio.
Otra cosa muy interesante de los eventos es que uno puede crear sus propios eventos customizados, descendiendo de la clase Event. Aqui un ejemplo:

package{
import flash.events.Event;

public class miEvento extends Event{
public static const AGREGAR_PERSONA:String = "AgregarPersona";

public var nombre:String;
public var apellidos:String;
public var action:String;

public function miEvento(action:String,nombre:String,apellidos:String,bubbles:Boolean=false,cancelable:Boolean=false){
super(action,bubbles, cancelable);
this.action = action;
this.nombre = nombre;
this.apellidos = apellidos;
}

override public function clone():Event{
return new EventoEvent(action, nombre, apellidos, evento);
}
}
}

En este ejemplo simple y chapucero, se pasan dos variables, nombre y apellidos que seran seteadas por el disparador del evento y que podran ser recolectadas por cualquier componente O o contenedor que este interesado en recibirlo. Nota, se pueden incluir clases para encapsular la informacion o incluso clases de cualquier tipo que se hayan creado.

Existen 3 fases de propagacion, durante los eventos:

1. Capturing: De arriba a abajo.
Un componente dispara un evento y Flex se encargara de buscar desde el contenedor mas afuera de ese objeto (generalmente el application) hasta el contenedor directo del componente mismo. Cada vez que va cambiando de componente, la variable currentTarget del event va cambiando. Cabe aclarar que los eventos tienen dos propiedades importantes: target y currentTarget.
El target en los eventos de AS3 se refiere al que emitio o disparo el evento y el currentTarget se refiere al nodo u objeto que se esta chequeando por EventListeners. No se, talvez a los de Adobe no les dio mas para ponerle otros nombres pues es algo confuso... Con estas dos propiedades podemos averiguar quien hizo quien y quien va a encargarse de...
Ejemplo:
Tenemos esto:
Application -->
Canvas -->
Button

El Capturing buscaria por event listeners en este orden: Application, Canvas.
Si existieran mas capas arriba del button, pues se revisaria en cada una de estas si tenian event handlers en cada una de ellos. El default del capturing es false.

2. Targeting:

Es el mas sencillo, solo se revisa por event listeners dentro del componente que dispara el evento, como cuando se define en el boton la propiedad click="funcion()". Esto ademas indica que el target y currentTarget son los mismos.

3. Bubbling: De abajo para arriba.
Es el contrario al Capturing
Ejemplo:
Tenemos esto:
Application -->
Canvas -->
Button

El Bubbling buscaria por event listeners en este orden: Canvas, Application.
Flex buscara event listeners hasta que se le permita. Puede ser que llegue hasta al application o puede ser que se le pare en el contenedor siguiente al componente que despacha el evento, en este caso el Canvas. El default del bubbling es false.

Tanto para capturing como para bubbling, es posible el parar la propagacion desde un listener que se quiera, con stopPropagation() y stopImmediatePropagation().

Lo mejor en la propagacion es ver cual es la que mejor sirve para su aplicacion para optimizar tiempos. Por ejemplo si solo ocupa targeting, deje bubbling y capturing en false. Si ocupa capturar un evento solamente desde el contendor del componente, pues user bubbling. Si lo ocupa hacer desde mas afuera, pues hagalo con capturing. Si ocupa capturar el evento por alguien mas que el target y no usen bubbling o targetting no se va a poder capturar los eventos lanzados a no ser que agregue el listener al contenedor, pero no siempre se puede hacer.

Esto es algo muy basico, pero necesario y que hay que estar revisando casi todos los dias para comprenderlo mejor. Cuando se dominen los eventos en Flex, estoy seguro que tendra un 80% de lo escencial dominado.

miércoles, 16 de enero de 2008

Patron de Comando en Actionscript

Patron de Comando:

Es un patron de comportamiento, que nos permite eliminar el acoplamiento entre objetos.
Ejm:

Objeto A ocupa invocar un servicio del Objeto B. Generalmente se hace a traves de la invocacion directa del servicio ObjetoB.method();
Eso genera un acoplamiento alto, debido a que de esa forma, Objeto A ocupa saber los metodos del Objeto B y si los mismos se llegaran a cambiar alteraria (nombre, firma, etc) la compilacion del Objeto A daria error y habria que modificarlo ahi o en cualquier otro objeto que invoque ese servicio.
Para evitar esto, se procede a crear una clase intermedia (el command), que sera la que conocera todo acerca de la clase B y la cual sera invocada por la Clase A, para ejecutar la tarea.
El Command no se preocupa por la respuesta que se genera o a quien debera retornarla, solo ejecutarla.
Esto se hace a traves de la definicion de una Interfaz con el metodo execute (o ejecutarAccion o ejecutar o como se quiera, pero que todos los comandos implementen ese metodo)

Ejemplos:

Sin Command:

ObjetoA -- invoca metodo --> ObjetoB

Con Command:

ObjetoA -- invoca execute --> Command -- invokes metodo --> ObjetoB

La ejecucion de la accion es desconocida por el que la inicio y eso permite que no exista acoplamiento entre componentes ni objetos y que al mismo tiempo las modificaciones que se hagan mas adelante, no generen errores en clases o componentes que ya estaban listos.
Esto es basicamente lo que sucede con Cairngorm y los comandos que se implementan dentro del framework.

Ejemplo de Codigo (la sintaxis no esta chequeada contra el compilador ni con Cairngorm):

Interface Command

package com.ejemplos.patrones.ejemplo{
public interface ICommand{
public function ejecutar():void; //No devuelve ningun tipo de valor
}
}

Clase CommandoLlamarClaseB

package com.ejemplos.patrones.ejemplo{
public class CommandoLlamarClaseB implements ICommand{

public function ejecutar:void{
var claseB:ClassB = new ClassB();
claseB.llamadoEnClaseB();
}

}
}


Clase A

package com.ejemplos.patrones.ejemplo{
public class ClassB{
public function llamarClaseB():void{
var comando:ICommand = new CommandoLlamarClaseB();
comando.ejecutar();
}
}
}

Clase B

package com.ejemplos.patrones.ejemplo{
public class ClassB{
public function llamadoEnClaseB():void{
trace("Desde Clase B");
}
}
}