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");
}
}
}

viernes, 14 de diciembre de 2007

Interaccion de Flex con datos externos

Empiezo este tema hablando lo negativo... Flex no tiene acceso directo a bases de datos.

Y la respuesta inicial de muchos:

Como???? Entonces de que me va a servir a mi o a mis clientes, si lo más importante de sus aplicaciones es la información, que generalmente se guarda en una Base de Datos??? Mejor me quedo con mi lenguaje web que me permite conectarme con la base de datos desde la misma página que esta cargando el usuario (por que para muchos esa es la mejor manera de hacerlo...)
Si Flex no tiene acceso directo a base de datos, como entonces puedo acceder a mi informacion?

Funcionalidad Flex

Flex fue hecho para funcionar como una interfaz de interacción de un usuario con un determinado sistema. Razón suficiente para preocuparse en brindarle al programador los recursos necesarios para realizar una experiencia totalmente distinta a la de sitios con el tradicional HTML.

Ahora, lógicamente que para interactuar con un sistema, se debe de tratar con datos. La datos es lo más importante en un sistema y de que sirve interactuar con alguien si no le responde a uno nada...? Se hace necesario el uso de un Backend que se encargue de manipular la informacion y transmitirla a la aplicación en Flex.

Ocupo programar en algún lenguaje especial para que funcion esto?

El acceso a datos desde Flex es totalmente independiente del lenguaje en que se programe en el backend. Puede hacerse en Java, Cold Fusion, PHP, Ruby, .NEt, lo que usted se imagine ya que provee varias maneras distintas de accesar la información.

Métodos Básicos

HTTPService: Permite acceder a la un archivo "hosteado" en un servidor. Se puede acceder a información en el mismo servidor o en otro. Esto permite realizar peticiones tipo REST a un servidor, ya que permite el envio de Parametros en el request, pero además permite la manipulación del resultado que esa página produzca... todo por medio de llamadas asincrónimas. Permite no solo la invocación a HTML plano, sino tambien a archivos generados dinámicamente en PHP, JSP, ASP, etc, devolviendo estos el resultado en la forma en que quieran y que el programador pueda interpretar más facilmente. Lo general es devolver el resultado en formato XML. El Actionscript 3 provee una forma muuuuuuy sencilla de manipular el XML (E4X), pero eso se merece otro post aparte

Ejemplo:

<mx:httpservice id="httpLogin" destination="http://127.0.0.1/login.php" result="resultHandler(event)" fault="faultHandler(event)">

</mx:httpservice>

Esto es:
id ==> Nombre con que se manejara el servicio en el MXML y en el Actionscript
destination ==> Direccion del recurso que se quiere accesar. Puede ser incluso un archivo XML directamente
result ==> nombre de la función en actionscript que se encargara de manipular la información que devolver el script login.php (en este ejemplo)
fault ==> nombre de la función en actionscript que se encargara en caso de que el llamado falle, de hacer lo que el programador desee (mostrar mensaje o lo que sea)

Todavía no hemos invocado a la pagina, solo tenemos la definicion del servicio... Esta definicion se puede hacer tambien por actionscript.

Continuamos con el ejemplo:

<mx:script>
<!--[CDATA[
//Funcion que invocara el servicio
public function invocarLogin():void {
//Uso de Token
var call:AsyncToken = MyService.send();
//Hasta aqui se hace la invocacion a la página
call.marker = "login";
}
//Manejo de resultado
private function resultHandler(event:ResultEvent):void {
var call:object = event.token
if (call.marker == "login") {
//manipular informacion a través de: event.result;
trace(event.result) //imprime el resultado enviao por la pagina
}
}
//Manejo en caso de falla
private function faultHandler(event:FaultEvent):void {
Alert.show(event.fault);
}
]]-->
</mx:script>

<mx:remoteobject id="ro_tasklist" destination="TasklistService" result="onROResult(event)" fault="onROFault(event)" showbusycursor="true">
</mx:remoteobject>
Precaución: Al igual que con Ajax y con otras aplicaciones que se ejecutan en el cliente, el acceso a recursos que se encuentren en un servidor distinto al en que se descarga la aplicación flex, esta prohibido. Las reglas para acceso a recursos de un proveedor externo están restringidos por motivos de seguridad. Sin embargo una manera de evitar este problema, es utilizando un "proxy". Por ejemplo (un poco cavernicola...) tengo mi aplicacion flex en miserver.com que lee los feeds de un RSS localizado en CNN.com, puedo crear un archivo en mi servidor (el proxy) php, jsp, asp, o lo que quiera que se encargue de leer el contenido en CNN.com y se lo devuelva a mi flex...

RemoteObject: Mi favorito....este es definitivamentelo que hizo que me enamorara del Flex. Es totalmente RPC (remote procedure calls). Funciona en palabras simples asi:
Se tiene un backend creado en X lenguaje, en servidor se tiene una configuración especial para ese lenguaje y el Flex a través de esa configuración puede acceder a los métodos de las clases definidas en la configuración, pasando objetos como parametros y recibiendo objetos como resultados (literalmente objetos, nada de XML ni eso). Esto a través del protocolo AMF, que lo que haces serializar los objetos y mandarlos sea al servidor o al cliente para su respectiva deserialiazación y manipulación. El AMF serializa estos objetos en formato binario, osea es mucho más rápido (mucho más y sino lo cree, corra este ejemplo de James Ward: http://www.jamesward.org/blazebench/) y los manda encapsulados y comprimidos en un metodo POST por http (no teniendo problemas con proxies ni firewalls). No tienen que ser solamente un objeto a la vez, puede enviar colecciones de objetos (Arrays, listas, etc)
Algo bueno es que acaba de ser abierto por Adobe, lo que permitirá que otras personas intenten mejorarlo o darle nuevas aplicaciones...
RemoteObject es asincronimo tambien y hay que manejar tambien el Resultado o la Falla como en el HTTP Service.
Inicialmente funcionaban solamente con Java y ColdFusion (adobe provee librerias para configurar los servicios) sin embargo ya existen las librerias necesarias para configurar en otros lenguajes, ejemplo PHP --> amfphp, Ruby --> rubyamf, WEBORB, AMF.NET --> .NET entre otros.
Ejemplo:

Suponga que tenga una aplicación que tiene un metodo para crear usuarios llamado creaUsuario y que recibe un parametro de tipo Usuario (una clase) con nombre, username y password.

En actionscript, define su clase llamada Usuario también, con las propiedades nombre, username y password, esta clase es un mapeo de la clase Usuario en el server.
Algo asi:

package com.sitio.clases
{
//RemoteClass especifica a que clase en el server va a asemejarse esta. Apunta al mismo folder donde se encuentra la clase pero en el server.
[RemoteClass (alias="com.sitio.clases.Usuario")]
public class Usuario
{
public var nombre:String;
public var username:String;
public var password:String;
}
}

En el MXML (o en Actionscript tambien) se definira el RemoteObject

<mx:remoteobject id="ro_usuario" destination="ServicioEnServidor" result="resultHandler(event)" fault="faultHandler(event)" showbusycursor="true">
</mx:remoteobject>

Esto es:
id ==> Nombre con que se manejara el servicio en el MXML y en el Actionscript
destination ==> Nombre del Servicio o Clase que se configuro en el servidor para ser accesado por el Flex
result ==> nombre de la función en actionscript que se encargara de manipular la información que devolvera el método
fault ==> nombre de la función en actionscript que se encargara en caso de que el llamado falle, de hacer lo que el programador desee (mostrar mensaje o lo que sea)
showBusyCursor ==> Muestra un cursor con un relojito, mientras se hace el request...mas estetico que otra cosa

Todavía no hemos invocado al metodo, solo tenemos la definicion del remote object... Esta definicion se puede hacer tambien por actionscript.
Además en su aplicacion tiene un boton, que cuando sera presionado invocara a una funcion que preprara el usuario e invocara el metodo en el server:

<mx:button label="Add Item" id="submit" click="enviarForm()"/>

El Script:
<mx:script>
<!--[CDATA[
//Funcion que invocara el servicio, ejecutada cuando se apreta boton
public function enviarForm():void {
//Creacion de un objeto en AS3 de tipo usuario, que sera transmitido al server
var usuario:User = new Usuario();
usuario.nombre = "Mi Nombre";
usuario.username = "username";
usuario.password = "password";
//Uso de Token
var call:AsyncToken = ro_usuario.creaUsuario(usuario);
//Hasta aqui se hace la invocacion al metodo, pasandose de parametro el usuario creado
call.marker = "crearusuario";
}
//Manejo de resultado
private function resultHandler(event:ResultEvent):void {
var call:object = event.token
if (call.marker == "crearusuario") {
//manipular informacion a través de: event.result;
trace(event.result) //imprime el resultado del metodo
}
}
//Manejo en caso de falla
private function faultHandler(event:FaultEvent):void {
Alert.show(event.fault);
}
]]-->
</mx:script>

De verdad.. si está pensando en iniciar una aplicación en Flex con acceso a datos en el servidor, considere seriamente esta opción pues es mucho más facil que las demás...

WEBService: Permite acceder a información por medio de SOAP. Utiliza la especificación WSDL 1.1. Este método en realidad no lo he usado. Sin embargo está disponible y funciona igualmente con llamadas asincrónimas, haciendo que el programador maneje las funciones de resultado y de falla igual como el HTTP Service. Existen ya varias aplicaciones que utilizan de este medio, por ejemplo Yahoo ofrece varios de sus servicios para desarrolladores en Flex por medio de Web Services, como en los mapas o el clima: http://developer.yahoo.com/flash/astra-webapis/ (ellos "wrappean" los llamados a los servicios desde sus librerías)

Esto por ahora en cuanto a interaccion con datos...
Saludos