viernes, 23 de noviembre de 2007

Flex Básico

Si busca una manera rápida para entrarle al Flex, le adjunto algunos puntos básicos para poder iniciar sin temor en la herramienta.
  1. Flex cuenta con un Ambiente de Desarrollo muy avanzado, llamado Flex Builder el cual está basado en el IDE Eclipse Un IDE ideado por IBM y que posteriormente puso a disposición de la comunidad en general. Esto ha permitido un desarrollo acelerado de la herramienta, teniendo a disposición múltiples plug-ins para distintas tareas. Este IDE es principalmente utilizado por programadores en JAVA, sin embargo puede ser adaptado para otros lenguajes. En lo personal me gusta más este IDE para Java que otros que he intentado, por ejemplo Netbeans. Adobe logró coger la estructura principal del eclipse y aplicarla a las necesidades que tenían para el desarrollo en Flex, una herramienta intuitiva para desarrollo de interfaces gráficas, compilación desde el mismo IDE, auto-complete del código, etc...
  2. Si no cuenta con dinero para el Flex Builder (que por cierto le bajaron su precio) o es de esos programadores que les gusta la línea de comando, Adobe le permite bajar gratuitamente el compilador de Flex, donde desde la linea de comandos (mxmlc) puede compilar sus archivos creados en notepad sin ningún problema (aparte de la creación de su codigo desde notepad por supuesto =p ). Solo para recordar, la clase principal debe estar en paquete sin nombre algo asi package {...
  3. El código fuente del Flex Framework esta disponible y abierto para ser bajado, leído o si es muy bicho, pues modificado. Aparte de permitir la extensión de los componentes del framework y la herencia por sustitución o por extensión.
  4. Existen dos maneras de desarrollar en Flex, por medio de Actionscript puro (con archivos .as) y por medio del MXML (archivos .mxml). El primero por medio de clases y paquetes con funciones. El segundo es un lenguaje de etiquetas (si...como el XML) el cuál es usado principalmente para la creación gráfica de las interfaces. Si ocupa hacer una interfaz gráfica lo recomendado es hacerlo por aquí. Si ocupa extender componentes o controles ya disponibles en el framework o crear componentes compuestos (los cuales son grupos de componentes dentro de otros, pueden ser dentro de un contenedor por ejemplo) lo ideal es hacerlo por MXML. Si ya ocupa crear un componente muy detallado y muy específico, lo recomendado es hacerlo en Actionscript. Por cierto, los archivos MXML, son convertidos posteriormente en Actionscript para ser compilado posteriormente en un .SWF (se dice suif)
  5. Dentro del MXML se puede tener código de Actionscript (dentro las etiquetas script) aunque esto no es recíproco.
  6. Prácticamente todos los objetos creados en Actionscript se pueden introducir al MXML por medio de etiquetas (markups) o desde el codigo AS3.
  7. Existen ya una serie de componentes gráficos muy interesantes y avanzados con los cuales se pueden hacer las aplicaciones, esto quiere decir que no hay que inventar la rueda... Recalco: son componentes bastante avanzados, no tan rígidos como los de Swing en Java por ejemplo.
  8. Se puede hacer uso de CSS, para tus componentes, incluso Adobe puso a disposición un Style Explorer de los componentes donde puedes escoger un componente y cambiarle sus atributos para posteriormente copiar el respectivo código CSS. Esto es bastante útil cuando se quieren tener "themes" o temas en tu aplicación o hacer diseños más avanzados.
  9. Existen múltiples contenedores para los controles. El principal es el Application. Sin embargo dentro de ese se pueden agregar contenedores para distribuir mejor los controles. Existen dentro de los contenedores distintos "layouts" o formas en la que se distribuyen los componentes, ejemplo, verticalmente: componentes uno encima de otro, horizontalmente: si... ya saben como, esta tambien el absoluto: donde se define con X y Y donde se quiere poner cada componente.
Esto sería por ahora... espero poder poner algunos puntos más posteriormente....
Termino con una frase que leí ayer y que me parece una certeza: "Lo que Natura non da, Salamanca non presta", refiriendose a la Universidad de Salamanca, una de las primeras universidades en el mundo... aquí mi interpretación: "se tiene o no se tiene (inteligencia, talento, lo que sea que sea necesario) para cumplir con una tarea... nadie puede poner eso en uno"

sábado, 10 de noviembre de 2007

Notas acerca de Cairngorm

Debo de admitir que después de muchos años, cuando ingrese al mundo de Flex, me pareció como un nuevo inicio para quitar vicios de mi programación en Java.
Uno de esos era la dependencia a ciertos frameworks como struts, spring, hibernate, etc. No es que los frameworks sean malos de hecho casi todo lo que hacemos, lo hacemos basados en un framework, pero algunas veces cuando se plantea un problema por resolver muchas veces se piensa directamente en como resolverlo para y con X o Y framework, en lugar de buscar resolver el problema de la mejor manera aunque no haga uso de un framework...
Cuando empecé a adentrarme en Flex, empecé a encontrarme con la palabra Cairngorm muy frecuentemente y como estaba siendo utilizado por bastantes desarrolladores de Flex. El Cairngorm según Adobe es una micro arquitectura y al mismo tiempo un framework. Es un conjunto de patrones de diseño que han sido recolectados a través de varios años.
Por bastante tiempo estuve en negación, no quise estudiar ni adentrarme en Cairngorm, hasta que después de varios meses, en un proyecto sencillo, pero que necesitaba otro tipo de solución a la que estaba empleando normalmente, decidí probarlo.
La verdad me arrepiento de no haberlo usado antes, muchas de las cosas que hice antes, se hubiesen podido resolver de una mejor manera haciendo uso del framework... ayudando a resolver muchos problemas de arquitectura, forzándote a usar algunos de los patrones de diseño.
En realidad es bastante complicado y no es algo que se aprende de la noche a la mañana, se necesita mucha experiencia para agarrarle el ritmo, pero cuando empiezas a entender el funcionamiento aún más de lo que entiendes la sintaxis o forma de implementación, cambiará la manera en que se pueden resolver ciertas RIAs, se buscará arquitecturas donde se busque reducir el acoplamiento, delegar en otras clases, programación a la Interface, uso de Singletons(de por si la aplicación es un cliente, una sola persona la usara...), etc, etc..
A continuación algunos conceptos básicos que mi primer experiencia con Cairngorm ha brindado, estoy seguro que no son todos y talvez no los entienda 100%, pero espero aprender muchos más y que le sirva a alguno que quiera iniciar con esto.

Va más o menos así: Componente --> Patron (es) q implementa --> Descripción

Eventos --> Observer --> Extienden la clase CairngormEvent y son utilizados para notificar a un controlador cuando hay una interacción de un usuario en la que se deba ejecutar algún proceso o comando
Commands --> Command Pattern --> Implementan la interfase Command, forzando a tener un método que se llama Execute, que recibe un evento de parámetro. Aquí es donde se realizaría la acción, sea comunicarse con un server o cualquier cosa que se quiera realizar, la lógica del negocio.
ModelLocator --> Singleton --> Mantiene una copia de toda la información que se maneja del dominio de la aplicación y la pone disponible a las demás "vistas" por medio de binding u otros métodos de setteo. No tiene gran lógica, solo una colección de los datos que se utilizan a través de la aplicación.
FrontController --> FrontController, Singleton --> Se instancia al inicio de la aplicacion y su tarea es registrar los distintos eventos que puedan suceder y los comandos o acciones que se quieran ejecutar en respuesta a esos eventos, desde un solo lugar. Es el que controla los hilos del juego...
Delegates --> Business Delegate --> Se encarga de realizar la comunicación y manejar las respuestas con un servidor (en caso que se ocupe realizar)
Service Locator --> Singleton --> Permite accesar a los distintos servicio de interacción con servidores que se tengan, sean servicios HTTP, acceso a WebServices, Remote Objects, etc... de una manera centralizada y sin tener que declararlos muchas veces, pues están declarados en un solo lugar.

Cairngorm no será la solución para todos los problemas, pero definitivamente hace que uno cambie la manera de pensar en como resolverlos. Igual que con todos los frameworks, "Úsese con cuidado y moderacion", no sea que se piense en como resolver el problema con X Framework, pero ni si quiera se entienda como resolverlo...
Para un verdadero entendimiento de la arquitectura y funcionamiento del Cairngorm, no dejen de visitar este diagrama. De verdad aclara el entendimiento.

PS: De verdad.. visiten el diagrama para que puedan entenderlo bien!

viernes, 9 de noviembre de 2007

Algunos conceptos basicos del ActionScript 3

El ActionScript3 es un lenguaje muy potente. De todas las versiones de actionscript, esta es la que me parece más de verdad (sin querer ofender a nadie...) Talvez por venir del lado de Java uno espera encontrarse con algo más maduro y la verdad eso ha pasado con el AS3. Pretendo ir mostrando algunas cosillas que me han ido llamando la atención en este camino.... Aquí hay una muy buena comparación entre el Actionscript 3 y Java si quiere profundizar más.

Algunos conceptos básicos:
En AS3, no existe la herencia múltiple (como en java), solo se permite heredar de una clase directamente. Sin embargo se permite la implementación de múltiples interfaces a la vez.

Las interfaces si pueden heredar de multiples interfaces a la vez.

Cada clase debe estar dentro de un paquete masomenos algo así:

package mi.paquete{

public class miClase{

}

}


No existen metodos o clases abstractas, como se conocen en java. Se pueden tener metodos sin cuerpo dentro de las clases, sin embargo no se obliga a las subclases su implementacion, solamente se podría documentar que el método se debe implementar o hacer uso de las interfaces, que si obligan a implementacion del método.


Ciclos

AS3 cuenta con los mismos ciclos que la mayoría de lenguajes. Sin embargo añade en esta version un ciclo que es muy útil y es el for each...
Se utiliza cuando se tienen una colección de objetos dentro de un Array o ArrayCollection y te permite navegar por la lista completa haciendo él la asignación automáticamente.
Ej:
Suponiendo una coleccion de objetos llamada "objetos" - todos de tipo MiObjeto

var obj:MiObjeto;
for each(obj in objetos){
trace (obj.nombre);
}

la variable obj va tomando un valor de acuerdo a como se va avanzando en la coleccion.
Esto tambien es bueno, ya que muchos programadores tienen la mala costumbre de crear nuevos objetos dentro del ciclo algo como:

for (var i:int=0; i < objetos.lenght ;i++){
var obj:MiObjeto = objetos.get(i);
trace (obj.nombre);
}

Esto lo que hace es ir añadiendo nuevos objetos a memoria y una vez que estos dejan de ser "accesibles" por el resto de la aplicacion, quedan como candidatos para ser recolectados por el Garbage Collector del virtual machine. Talvez se piense que no hay problema si son 10, 20 objetos disponibles para ser recogidos... pero cuando son 100, 1000, 2000 o mas? El performance de la aplicación puede bajar en caso que al GC se le ocurra correr.

Tipos

AS3 es un lenguaje estricto(con tipos definidos) y a la vez dinamico (que se puede alterar ciertas clases añadiendo nuevas variables y tipos en el camino).

Hay tres tipos distintos de Tipos: Null, void y Object.
Null y void tienen un simple valor: null o undefined.
Object puede contener todas los tipos de clases que se definan, pues es la super clase de todas las cases...

Sin embargo es una buena práctica ser lo más apegados a la definición de tipos(modo estricto), por dos razones principales:
1. El performance de la aplicación es mejor, ya que somos específicos con el compilador para decirle que hacer y no tener él que inventar que hacer.
2. Hay menos posibilidades de equivocarse, se permite al compilador ayudarte a comprobar si se esta otorgando a las clases la información que se quiere y no llamando a metodos o atributos que no existen.

Para hacer esa definicion se hace:
var variable:tipo = valor;

El tipo debe contener: nombres de clases u interfaces o el simbolo *, que indica que es una variable sin tipo osea q puede recibir cualquier tipo de informacion que se quiera, sin que se genere un error.

Para verificar si un objeto es de un tipo especifico, se puede realizar de la siguiente manera:

if(objeto is MiObjeto){
trace(objecto.nombre);
}else if(objeto is MiObjeto2){
trace("Es de tipo 2"+objeto);
}

El proceso de casting esta muy ligado con el polimorfismo y la herencia. Es un proceso que nos permite convertir un objeto de un tipo especifico a otro tipo.
Supongase que se tiene un clase que se llama Vehículo, de ahí descienden carro y moto.
Podemos hacer un UpCasting para pasar un objeto de tipo Moto como un objeto de tipo Vehículo. Osea de una subclase a una superclase.
Esto se haria masomenos asi:

var moto:Moto = new Moto();
var vehiculo:Vehiculo = moto as Vehiculo;
o
var vehiculo:Vehiculo = Vehiculo(moto);

El método para pasar de una super clase a una subclase (downcasting), es parecido:
var honda:Vehiculo = new Moto();
var moto:Moto = honda as Moto;
o
var moto:Moto = Moto(honda);

Sin embargo con el downcasting, existe el riesgo que se quiera hacer a una clase que no es subclase... por ejemplo castear de vehiculo a un objeto de tipo perro, que no tienen relación. Por eso es importante usar "is" como metodo de comprobacion, ej:
if(honda is Moto){
var moto:Moto = honda as Moto;
}

Namespaces

Como en XML, definen un area de acción que permite tener varias miembros con un mismo nombre, sin que existan conflictos entre otras clases, por ejemplo que se herede de componentes ya hechos y que no exista conflictos entre las nuevas definiciones y las echas en el componente previamente o para definir mismas funciones pero para distintos ambitos.

Se declaran asi:
Dentro de un paquete:
package mis.clases{
public namespace uno;
public namespace dos;
}

Luego desde una clase se importan:

import mis.clases.*;

y se utilizan desde la clase:

package mis.clases{
public class MiClase{
uno static function holaMundo():void{
trace('Hola Mundo desde namespace uno');
}
dos static function holaMundo():void{
trace('Hola Mundo desde namespace uno');
}
}
}

Y para accesar las funciones de MiClase, desde el cliente se usa la palabra "use"
Ejm:
...
use uno;
use dos;
...
MiClase.uno::holaMundo(); //Imprime: Hola Mundo desde namespace uno
MiClase.dos::holaMundo(); //Imprime: Hola Mundo desde namespace dos