Patron Proxy en Flash

Recientemente me encontraba trabajando con Shared Objects (SO) en Flex para persistir ciertas propiedades en el cliente y empece a ver mas frecuentemente el uso de este codigo:

var settings:SharedObject = SharedObject().getLocal("/settings");

try
{
  settings.data["property"] = value;
  settings.flush();
}catch(e:Error)
{
...
}

Inmediatamente decidi mover esto dentro de una clase donde tenia un SharedObject y desde donde simplemente invocaba un metodo y le pasaba 2 parametros, uno con el key y otro con el value para el key, terminando con algo asi:

public function put(key:String, value:*):void
{
 try
 {
  _sharedObject.data[key] = value;
  _sharedObject.flush();    
 }
 catch(e:Error)
 {
  log.error("Error while persisting setting. " + e); 
 }
}

Ya mi codigo empezo a verse con mucho menos lineas de codigo y tenia una clase reutilizable para interactuar con SO:

Definia esto al inicio de mi clase indicando cual shared object queria usar
var settings:SharedObjectWrapper = new SharedObjectWrapper(SharedObject().getLocal("/settings"));

Invocaba a mi clase asi:
settings.put("property", value);

Sin embargo, queria hacer algo todavia mas sencillo, mas que por funcionalidad por majaderia :) y me acorde de la clase Proxy que trae el Flash API.

Que es?

La clase Proxy que viene en el paquete flash.utils, es una clase "abstracta"(aunque no es verdad pues AS3 no permite esas clases), que quiere decir que sus metodos que usemos deben ser definidos a la hora de extender la clase y ademas no puede ser instanciada. Esta clase viene a reemplazar a Object.__resolve y Object.addPropert en AS2.

El Proxy nos permite agregar comportamiento a otras clases por medio de la definicion de ciertos metodos. Estos metodos se encargan de "escuchar" los llamados a las propiedades y servicios (funciones) en un objeto y responder a esos llamados para redireccionarlos dentro de la clase (como veremos mas abajo)

Algunos de los metodos principales definidos en la clase Proxy son:

callProperty(name:*, ... rest):*

Escucha el llamado de una funcion, los parametros son:
name -> nombre de la funcion
rest -> un Array de parametros

y retorna un valor de cualquier tipo

getProperty(name:*):*

Escucha el llamado a una propiedad de un objeto
name -> nombre de la propiedad
y retorna un valor de cualquier tipo

setProperty(name:*, value:*):void

Escucha el llamado a una propiedad de un objeto a la que se le quiera asignar un valor
name -> nombre de la propiedad
value -> valor a setear, de cualquier tipo

Que quiere decir?

Que extendiendo esta clase y algunos de los metodos definidos podemos hacer que nuestras clases que ya existan puedan tener un comportamiento adicional al que ya tenian, sobre todo si son clases hechas por otras personas o que no podamos modficar.
Vamos a ver un ejemplo, digamos que ocupamos tener un objeto dentro de nuestra clase en el cual guardaremos propiedades como un Hash. Esto lo podemos hacer facilmente haciendo esto:

var hash:Object = new Object();

hash['prop'] = value;

trace(hash.prop);

Sin embargo nuestros requerimientos nos indican que debemos logguear un mensaje indicando que propiedad esta seindo invocada y a que hora. Ahora el ejemplo talvez no tenga mucho sentido, pero sigan leyendo...

Si hicieramos esto con el codigo anterior tendriamos que poner codigo adelante de nuestros llamados (o detras) con la informacion logueada. Tambien podriamos hacer una clase que se encargue de encerrar esa logica de logguear y asignar data en un metodo, o podemos usar el Proxy:

//Primero importemos el namespace flash_proxy que es necesario para hacer override de los metodos de la clase Proxy
import flash.utils.Proxy;
import flash.utils.flash_proxy;

use namespace flash_proxy;

public class class MyProxy extends Proxy {
     
  private var data:Object = new Object();// Este objeto contendra nuestra informacion

  //Retorna undefined si la propiedad no existe
  override flash_proxy function getProperty(name:*):*
  {
    trace("Invocando propiedad: " + name);
    return data[name];
  }
  
  override flash_proxy function setProperty(name:*, value:*):void
  {
    trace("Agregando propiedad: " + name + " con valor " + value);
    data[name] = value;
  }

  override flash_proxy function callProperty(name:*, ... rest):*
  { 
    //Aqui podemos llamar a otros metodos en esta clase o de otro objeto
    //que tengamos referencia dentro de la misma
    if(name == "iterate")
    {
       trace("Contenido del objeto: ");
       for each(var val:* in data) {
          trace(val);
       }    
    }
  }
}

El metodo getProperty es invocado cada vez que alguna instancia de la clase MyProxy le sea invocada una propiedad, algo asi:

var proxy:MyProxy = new MyProxy();

trace(proxy.color);//Getproperty es invocado

El metodo setProperty es invocado cada vez que se setea una propiedad de la instancia:

proxy.color = "verde";//SetProperty es invocado

Y finalmente el metodo callProperty es invocado cuando hacemos esto:

proxy.iterate;

Como pueden ver no se tiene que llamar a proxy.getProperty("color") o proxy.setProperty("color", "verde") o proxy.callProperty("iterate"), sino directamente a las propiedades o nombres de metodos que queremos tener. y el FP se encarga de invocar esos metodos en tiempo de ejecucion. El se encarga de hacer la logica necesaria y la magia la ejecuta el flash player que reconoce cual metodo invocar (getProperty, setProperty, callProperty o el que sea).

Esto es super util como mencione arriba para agregar comportamiento a clases que ya existen, pensando en un AOP mucho mucho mas sencillo pero igualmente efectivo.

Pues finalmente lo que hice con mi SharedObject fue poner un comportamiento parecido al de arriba y entonces logre tratar mi interaccion con el shared object que inicialmente necesitaba al menos 5 lineas, que despues baje a la invocacion de solo un metodo a poder hacer algo como esto:

settings.property = value; //dentro de este llamado esta el try/catch y el flush del SO.

Teoria:

Esto que acabamos de ver es el patron de dise~no Proxy, que como lo indica su nombre es una objeto que toma el lugar de otro. Este patron es usado a traves del Flash Api y Flex Framework en multiples lugares como el Loader donde tenemos acceso a propiedades (width, height) aunque no tengamos acceso al contenido al mismo instante. Tambien el RemoteObject en Flex hace uso de este patron cuando invocamos operaciones directamente del remote Object, por ejemplo: ro_user.loginUser(username,password); en este caso se llama remote proxy, pero es basicamente la misma idea solo que accedemos a datos remotos o externos.

La usabilidad de este patron es bastante amplia y muchas veces es muy despreciado, pero he de admitir que es una solucion muy elegante y sencilla para muchos problemas, ademas que el Flash API nos provee las herramientas necesarias para hacer este tipo de cosas de una manera muy sencilla.

Pseudo Threads en Actionscript

Como mencione en un post anterior el Flash Player aunque internamente tiene un sistema de Threads o hilos que permite ejecutar multiples tareas al mismo tiempo, no provee a nosotros los desarrolladores la funcionalidad para utilizar threads nativamente. Esto hace por supuesto que aplicaciones nuestras donde se procesen muchos datos o con funciones o procesamiento muy pesado haga que nuestras aplicacion se congele o se pegue...
Como desarrolladores no tenemos otra forma de hacer que esto funcion sino es emulando la funcionalidad de los threads. Digo emulando porque no hay forma de hacerlo nativamente y se hace dividiendo el proceso pesado en multiples pedazos.
Acerca de esto se ha escrito en multiples lugares con contenido muy completo y excelentes soluciones a distintos niveles de complejidad.
Las librerias anteriores y muchas otras lo que hacen es partir el proceso grande en multiples pedazos que seran ejecutados en momentos distintos. Esto disminuye la carga de trabajo y hace que el proceso no se ejecute de un solo sin permitir al FP refrescarse y por lo tanto pegarse.
Sin embargo de las librerias anteriores, mi favorita es la de Grant Skinner, se llama "Chunker" pues parte los procesos en pedazos. Sin embargo basado en esa clase, decidi hacer unas modificaciones que aqui presento:

package com.grayscale.util.threads
{
import flash.display.Shape;
import flash.events.Event;
import flash.events.EventDispatcher;
import flash.utils.getTimer;

/** 
 * Evento despachado cuando se concluye el proceso.
 */
[Event (type="flash.events.Event", name="complete")]

/**
 * Esta clase es una implementacion simple de un pseudo thread en AS3. 
 * 
Esta basada en la clase de Grant Skinner aunque con algunas modificaciones.
 *  http://www.gskinner.com/libraries/Chunker.zip
 */
public class SimpleThread extends EventDispatcher
{
 //Nos permite tener acceso al evento ENTER_FRAME que sera el que lleve el  
 //paso de cada cuando se ejecutaran nuestros procesos.
 private var shape:Shape = new Shape();
 //Estado del hilo
 private var _paused:Boolean = false;
 //Cada cuanto se ejecutara
 private var _execTime:uint;
 //Funcion a ejecutar
 private var _func:Function;
 //Argumentos a nuestra funcion. Es un array de elementos que pasariamos a nuestra funcion
 private var _args:Array;
 
 /**
  * Constructor.
  * 
  * @param execTime Cada cuanto se ejecutara nuestra funcion
  * @param func funcion a ejecutar
  * @param args parametro opcional con los valores a pasarse en la funcion
  */
 public function SimpleThread(execTime:int, func:Function, args:Array=null)
 {
  _execTime = execTime;
  _func = func;
  _args = args;
  
  pause = false;   
 }
 
 /**
  * Para el thread o lo arranca
  */
 public function set pause(value:Boolean):void
 {
  _paused = value;
  if(_paused) shape.removeEventListener(Event.ENTER_FRAME, run);
  else shape.addEventListener(Event.ENTER_FRAME, run);
 }
 
 
 /**
  * Metodo que ejecuta nuestra funcion
  */
 private function run(event:Event):void
 {
  var initialTime:int = getTimer();//registra el tiempo donde  inicia este iteracion
  while(!_paused && (getTimer() < _execTime+initialTime ))//revisa si no hemos excedido la cantidad de tiempo del inicio
  {
   //llama nuestra funcion y esta tiene que regresar un valor booleano. Si este es falso detiene el thread sino continua.    
   var res:Boolean = _func.apply(this, _args) as Boolean 
   if(!res)//ya se termina de ejecutar nuestra funcion, pausamos el thread y despachamos evento avisando que se concluyo
   {
    dispatchEvent(new Event(Event.COMPLETE));
    pause = true;
   }
  }
 }
}
}

El unico requisito para esta clase, es que la funcion que queremos partir debe devolver un valor booleano: true si todavia hay data que procesar, false si ya termino de procesar la informacion.
A continuacion presento dos ejemplos, ambos cargan el mismo archivo(analytics de este blog); uno lo hace sin los pseudo-threads y otro con el pseudo-thread. Podran ver la diferencia como uno se pega y el otro no. Es un archivo grande (4mb) asi que tengan paciencia. Apenas se carga se activa el boton de "Start"
Notas: 1. Debe aparecer un spinner cuando se aprieta el boton de "start". 2. los controles de la pantalla deben ser accesbles mientras se procesan los datos.

Sin Thread.




Con Thread.



Al partir nuestra funcionalidad en multiples ejecuciones y no solo en una, ocupamos una forma de llegar a saber donde terminamos de procesar y desde donde debemos empezar. Para esto puedo sugerir el uso del patron Iterator. Este patron permite a una coleccion encapsular la manera en que se recorre la coleccion y guardar dentro de si misma cual fue el ultimo elemento procesado, sin tener que tener mantener un indice de la coleccion por fuera. El iterador se encarga de todo. Esto es bueno ya que al partir nuestro proceso ocupamos mantener una referencia al dato que estamos procesando sin tener que crear otras variables.
Aqui presento las siguientes clases para tener nuestro iterator.

Interfaz Base:

package com.grayscale.util.iterator
{
/**
 * Esta interfaz define los metodos basicos que debera contener un iterador en nuestra coleccion
 * @author Ivan Ramirez - ivan.ramirez@gmail.com
 */
public interface IIterator
{
 /**
  * Devuelve "true" si tenemos mas valores que recorrer dentro de nuestra coleccion
  */
 function hasNext():Boolean;
 /**
  * Devuelve el proximo valor en nuestro iterador
  * @returns el siguiente objeto en la coleccion.
  */
 function next():*;
 /**
  * Nos permite reiniciar el recorrido de nuestra coleccion
  */
 function reset():void;  
}
}

Implementacion basica:

package com.grayscale.util.iterator
{
/**
 * Implementacion basica de nuestro iterator para el manejo de arrays. Podemos implementar esta interfaz
 * en otras clases para hacer iteradores con Strings o de XML, etc.
 * @author Ivan Ramirez - ivan.ramirez@gmail.com
 */
public class ArrayIterator implements IIterator
{
 //Coleccion base
 private var collection:Array = new Array();
 private var index:int; 
 
 public function ArrayIterator(values:Array)
 {
  collection = values
 }

 public function hasNext():Boolean
 {
  return index < collection.length;
 }
 
 public function next():*
 {
  return collection[index++];
 }
 
 public function reset():void
 {
  index = 0;
 }
 
}
}

La ventaja de tener una interfaz definiendo el iterador, es que podemos crear nuestras propias implementaciones del iterador de acuerdo a nuestras necesidades.
Ya con nuestro iterador cargado con la coleccion de datos que tenemos que procesar, procedemos a utilizar nuestro thread.

El codigo de las aplicaciones de este ejemplo esta aqui.

Como actualiza la pantalla el Flash Player...

El Flash Player(FP) es la maquina virtual que nos permite ejecutar nuestras aplicaciones hechas en Flash, Flex o Actionscript Puro (incluso ejecuta codigo en otros lenguajes cuyo bytecode es "traducido" a un lenguaje que el player entienda, pero eso es para otro post)
Una de los principales usos que se hacen del FP es la parte grafica que ha provisto por muchisimo tiempo excelentes herramientas para desarrolladores y dise~nadores para crear contenido totalmente fuera de lo normal. De hecho podriamos pensar que lo que ha hecho grande y famoso a la plataforma flash es la capacidad de crear aplicaciones que brindan al usuario excelentes experiencias.
Pero... esas excelentes ideas y deseos de buenas experiencias pueden verse truncados si nuestras aplicaciones no estan haciendo uso correcto del FP, sobre todo en la forma en que este maneja la actualizacion de la pantalla.

Ejecucion:

* Definicion: Frame Rate: es la cantidad maxima de veces que por segundo el FP revisara si hay cambios en nuestra aplicacion que se tengan que dibujar en la pantalla. Esto no significa que si tenemos un framerate de 24 fps(frames per second) es que el FP vaya a revisar si hay cambios, 24 veces en un segundo. Esto quiere decir solamente que si todo sale bien, si nada del codigo que uno como desarrollador escribio demora mucho tiempo, el intentara revisar esa cantidad de veces, pero a veces no sera posible.

- Nuestra aplicacion es cargada dentro del FP y es agregada al stage.
- FP ejecuta el codigo inicial de nuestro Frame.
- FP ejecuta algun event listener que sea despachado.
- FP ejecuta el proceso de rendereo (o actualizacion de la pantalla), que basicamente revisa si el codigo ejecutado previamente realizo algun cambio en la parte grafica que deba ser dibujado en la pantalla. Cuando se hace ese chequeo se despacha el evento Event.ENTER_FRAME.
- Si hay cambios, actualiza la pantalla.
- FP espera hasta que se vuelva a ejecutar el chequeo. Si algun event listener es ejecutado (eventos del mouse o del teclado, etc) los ejecuta.
- Chequea si hay cambios, si los hay actualiza la pantalla.
- Repitir.

Conclusiones importantes:

- Este ciclo de chequeo se repite infinitamente durante la ejecucion de nuestra aplicacion, sea que tengamos 1 o tengamos miles de Frames, el FP solo le importa saber si hay cambios que se tengan que reflejar en la pantalla y el gustosamente se encargara de chequearlo. Cambios pueden ser: dibujar algo (graphics.drawLine,etc), mover el X o Y o el width o height de nuestros componentes o los componentes dentro de nuestra aplicacion, cambiar el color de algo, etc.
- Los cambios que hagamos dentro de una funcion a nuestros componentes visuales no se reflejaran inmediatamente en pantalla (aunque a veces parezca que si), sino hasta que nuestro codigo termine de ejecutarse y el cambio proceso de rendereo se ejecute. Por ejemplo si tenemos algo como: comp.width = 100; comp.height = 200; dentro de un metodo, esto NO quiere decir que FP vayaa ejecutar nuestro codigo asi:
1. Cambie el width.
2. Dibuje la pantalla con el nuevo width.
3. Cambie height.
4. Redibuje la pantalla con nuevo height
El FP ejecutara el redibujado de la pantalla hasta que nuestro codigo se termine de ejecutar.
- Aunque nuestras aplicaciones no tengan muchos frames (2 en el caso de Flex) o solo 1 el evento ENTER_FRAME se va a despachar multiples veces porque el FP va a revisar si hay en cambios en la pntalla que deba actualizar. De ahi que el evento ENTER_FRAME sea utilizado multiples veces para ejecutar animaciones o procesos que deben ejecutarse infinitamente dentro de un mismo frame. Essto quiere decir que si tenemos un proceso que debe ejecutarse infinitamente, no debemos meterlo dentro de un ciclo infinito, digamos while(true), sino dentro de este event listener.
- El ciclo de rendereo, es realizado automaticamente por el FP.
- Si se esta ejecutando codigo de la aplicacion, el proceso de rendereo de la pantalla no se va a ejecutar y viceversa. Estos dos son exclusivos, no se puede chequear mientras se ejecuta codigo (funciones o event handlers) y no se puede ejecutar ningun metodo o event handler si se esta haciendo el chequeo. Por ejemplo, si nuestro frame rate es de 10 fps quiere decir que el FP va a revisar en teoria cada 100ms (1000 ms = 1 segundo, 1000 / 10 = 100 :) ) si hay que hacer una actualizacion. Pero como mencione arriba el framerate no necesariamente se va a ejecutar al mismo tiempo siempre. Si tenemos una rutina que recorre un Array con 1000 objetos por dentro y a cada objeto se le ejecuta algun metodo, una validacion y se le setea algunos valores, puede ser que esa funcion dure mas de los 100ms que esperaria el FP para revisar si hay cambios. Esto quiere decir que si la funcion demora 900ms, el FP no revisara si habra cambios hasta el siguiente segundo, no cuando se cumplan 200ms desde el primer chequeo.
- Si tenemos rutinas de codigo muy grandes, muy pesadas nuestra pantalla podria llegar a "congelarse" o verse "chunky", como pegada. Esto es porque como se expuso arriba la actualizacion de la pantalla no se va a realizar hasta que se termine de ejecutar nuestor codigo. Entre mas duren nuestras rutinas mas va a durar en refrescarse nuestra pantalla y peor puede ser la experiencia del usuario.
- Hay un tiempo maximo de ejecucion de codigo que por default es de 15segs. Si por ejemplo tenemos una clase y hacemos un ciclo while(true) en el constructor, podemos esperar 15 segs y ver como nuestra aplicacion va a mostrarnos un error. Esto es porque el tiempo maximo de ejecucion de una funcion fue excedida.

Formas de Optimizacion:

- Si tenemos rutinas muy grandes y que demoran mucho tiempo, lo mejor seria dividir esas rutina en varias para ejecutarse en distintos tiempos, algo como lo que se puede hacer con Threads en otros lenguajes. Recordemos que aunque el FP maneja Threads internamente, nosotros como desarrolladores no tenemos acceso a ellos y solamente podemos emularlos.
- Si utilizamos Flex, hagamos uso de los componentes creados en el framework que en su mayoria estan optimizados para este ciclo de actualizacion de pantalla. Si vamos a hacer nuestros propios componentes, sigamos las reglas y hagamos un override de los metodos sugeridos por Adobe (esto para FLEX 3) como commitProperites y updateDisplayList entre otros. Ambos metodos mencionados antes tienen su razon de ser una funcion especifica para hacer que se ejecuten las cosas de una mejor manera.
- Si no utilizamos Flex, podemos hacer uso del evento Event.RENDER. Este metodo es despachado por el FP exactamente antes de dibujar los cambios en la pantalla. Podemos recibir este evento haciendo un addEventListener normal, pero ademas de eso tenemos que llamar a stage.invalidate(). Esto forzara al evento a ser despachado. Ahora en que nos ayuda este evento? Pues al ser despachado justamente antes de ser actualizada nuestra pantalla, podemos revisar en nuestro listener, si nuestra clase tiene algun cambio en la pantalla. Si lo tiene, llama a la funcion que dibuje o haga los cambios que se quieran hacer en pantalla. Si no hay cambios simplemente no hacemos nada. Eso nos permite forzar al FP redibujar lo que cambio SOLAMENTE cuando haya cambios que de verdad alteren nuestra pantalla y forzar a que la actualizacion de la pantalla se haga solamente hasta que se tenga que hacer. Podemos hacer mas uso de esto, si ponemos setters en nuestros componentes que se encargue de registra que hay cambios en nuestro objeto en un flag booleano. En lugar de llamar dentro del setter al metodo que se encarga de dibujar nuestros graficos o mover nuestros componentes cada vez que se cambia una variable. El event handler del metodo renderer, consultara si nuestro flag esta activado y si lo esta ahi llamara a nuestro metodo. Asi en lugar de llamar el metodo que dibuja nuestra pantalla cada vez que se cambia una variable, este se ejecutara una sola vez y exactamente antes de que se ejecute el redibujado de la pantalla. Esto es muy parecido al proceso de optimizacion que tienen los componentes en Flex.

Otros recursos:
El excelente libro de Colin Moock, Essential Actionscript 3.0, especialmente el capitulo 23
Racetrack: Excelente analisis de como funciona el proceso de rendereo en el Flash Player.

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

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

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