Inicio

Diciembre 12, 2006

Novedades de AS3 (IV): Gestión de eventos

Otra de las novedades en AS3 está en el nuevo modelo de eventos. En este post no vamos a realizar una discusión muy profunda sobre el modelo de eventos ni sobre la forma de implementar la Cadena de Responsabilidad en los objetos con representación gráfica.

Simplemente, vamos a ver cómo se pueden emitir eventos, y cómo se deben escuchar los mismo.

La arquitectura es muy sencilla. Cualquier subclase de flash.events.EventDispatcher puede emitir eventos, eventos que realmente son instancias de flash.events.Event o de alguna de sus posibles subclases, y que serán escuchados por funciones o métodos de clases que hayan sido previamente registradas como listeners del evento en cuestión.

Como siempre, lo más sencillo es un ejemplo. En primer lugar, voy a construir una clase, que extenderá a flash.events.EventDispatcher, y que por tanto, tendrá la capacidad de emitir eventos. Escribiré también una función en la línea de tiempo principal de un swf, que registraré para que escuche el evento emitido por la clase anteriormente citada.


package
{
	import flash.events.*
	
	public class EventNation extends EventDispatcher
	{
		public static const EVENT_NAME: String = "particularEvent";
		
		function EventNation( )
		{
			trace( "EventNation.constructor" );
		}
		
		public function fireEvent( )
		{
			trace( "previo a dispatchEvent" );
			dispatchEvent( new Event( EVENT_NAME ) );
		}
	}
	
}

El método fireEvent es el encargado de la construcción del evento y de su lanzamiento. Para ello, se crea una instancia de flash.events.Event, pasando en el constructor de la misma el nombre del evento.

En la línea de tiempo principal, hay que declarar una función y registrarla como listener del evento.

import flash.events.*

var myVar: EventNation = new EventNation( );


function eventHandler( event: Event )
{
trace( "evento recibido " + event.toString( ) );
trace( "tipo dle evento " + event.type );
}

myVar.addEventListener( EventNation.EVENT_NAME, eventHandler );

Y finalmente, lanzar el evento:


myVar.fireEvent( );

Sencillo. El problema viene cuando en el evento emitido se quiere encapsular también algún parámetro más, específico del evento. En esos casos, la solución pasa por subclasificar Event, añadiendo a la subclase cualquier implementación específica (parámetros, cálculos, lo que sea).

Como ya vimos en un post anterior, en un paquete se puede declarar más de una clase, así pues, por intentar mantener la cohesión máxima, voy a declarar el nuevo evento en el mismo paquete en el que está la clase que lo va a emitir.

	class CustomEvent extends Event
	{
		public var param: String;
		
		function CustomEvent( msg: String )
		{
			super( msg );
			trace( "MyEvent.constructor" );
			
			param = "CustomEvent";
		}
		
		public override function toString( ): String
		{
			return "CustomEvent extends param: " + param + " -- " + super.toString( );
		}
	}

Y por tanto, a la hora de lanzar el evento, el método fireEvent de la clase EventNation será:

public function fireEvent( )
{
	trace( "previo a dispatchEvent" );
	dispatchEvent( new CustomEvent( EVENT_NAME ) );//Para pasar parámetros
	//dispatchEvent( new Event( EVENT_NAME ) );
}

El código completo del package:


package
{
import flash.events.*

public class EventNation_2 extends EventDispatcher
{
public static var EVENT_NAME: String = "particularEvent";

function EventNation_2( )
{
trace( "Myclass.constructor" );
}

public function fireEvent( )
{
trace( "previo a dispatchEvent" );
dispatchEvent( new CustomEvent( EVENT_NAME ) );//Para pasar parámetros
//dispatchEvent( new Event( EVENT_NAME ) );
}
}

class CustomEvent extends Event
{
public var param: String;

function CustomEvent( msg: String )
{
super( msg );
trace( "MyEvent.constructor" );

param = "CustomEvent";
}

public override function toString( ): String
{
return "CustomEvent extends param: " + param + " -- " + super.toString( );
}
}
}

Y en la línea de tiempo principal se podrá obtener el valor del parámetro extra:


import flash.events.*

var myVar: EventNation_2 = new EventNation_2( );


function eventHandler( event: Event )
{
trace( "evento recibido " + event.toString( ) );
trace( "tipo dle evento " + event.type );
trace( "parametro custom " + event.param );
}

myVar.addEventListener( EventNation.EVENT_NAME, eventHandler );
myVar.fireEvent( );

De esta forma, se solucionan los problemas en la implementación del modelo de eventos de AS2. Ya no son necesarias las delegaciones, menos aún las mezclas de delegación y hack para poder emitir eventos con parámetros. La forma de manejar el problema es muy sencilla y clara, poco propensa a errores. Como debe ser.

Mayo 12, 2006

The mythical man-moth

Libro de lectura obligatoria, cierto, pero no voy a hablar de él en concreto, sino que voy a permitirme recomendar la lectura de una divertidísima anécdota de Marc Hedlund que tiene bastante relación con el tema del libro.

Muy divertida, de verdad.

Mayo 05, 2006

Posters de patrones de diseño

Hace tiempo ya reseñamos el poster de patrones de diseño de la gente de Head First. Ahora, via The Farm, nos hemos encontrado con estos otros posters. Por ahora, son doce patrones.

Mayo 03, 2006

No es mejor programador el que mejor se aprende el manual

Hay cierta tendencia en algunas comunidades de desarrolladores a considerar que el programador más brillante es aquel que mejor conoce la api de su lenguaje de elección. Se muestra respeto, incluso cierta veneración, por aquél que es capaz de recitar de carrerilla la cadena de herencia de un componente de interfaz de usuario, siendo ese respeto y admiración directamente proporcionales a la profundidad de esa cadena de herencia.

Pero tener buena memoria no tiene porqué significar lo mismo que ser competente. En realidad el aprendizaje compulsivo de una api puede ser un recurso para esconder ciertas carencias.

No digo con esto, evidentemente, que no haya que tener cierto conocimiento de qué se puede y quéno se puede hacer con la api del lenguaje. Pero ese conocimiento debe estar orientado sobre todo a evitar el reinventar la rueda, el implementar cosas que ya están implementadas.

Programar es una actividad creativa. Requiere de una creatividad distinta a la que necesita un diseñador cuando está frente a un documento de Freehand recién creado, pero no por ello deja de precisar de altas dosis de imaginación, abstracción, intuición, aprovechamiento de las propias experiencias, capacidad de improvisación y de cambiar y adaptar sobre la marcha la idea inicial.

¿Qué es preferible, por tanto, trabajar en la fijación en la memoria de una lista de funciones que va a cambiar, que va a ser modificada, ampliada por un extremo y reducida por el otro en la próxima revisión del lenguaje, o intentar mejorar la intuición, la capacidad de abstracción, el lado creativo en definitiva?. Porque, si hay algo seguro en este mundo, es que la api va a cambiar. Las librerías de la primera versión pública de Java (Java 1.02) eran alrededor de 200 clases. Hoy, sólo en J2SE hay unas 3500. ¿Qué inversión es más rentable a largo plazo, la memorización de esas librerías, o la interiorización de aquello para lo que se pueden utilizar, de forma que se pueda volver a ellas como referencia cuando sea necesario concretar una solución?

Porque el manual siempre va a estar ahí, encima de la mesa, dispuesto a echar una mano cuando se le pida. El problema es que el manual que va a estar ahí mañana no tiene porqué ser el mismo que está hoy. Entre otras cosas porque el lenguaje en el que tenemos que trabajar puede cambiar. ¿O es que a nadie le ha caído nunca un proyecto encima en un lenguaje del que no tenía ni idea?

Además, si sólo se mira al manual, si sólo se saben atacar los problemas del día a día a base de academicismo se cae en el peor de los riesgos que puede asumir un programador: el anquilosamiento, la muerte de la imaginación, la muerte de la capacidad para buscar soluciones alternativas. Cuando todo se basa en seguir los procedimientos, en atenerse a una forma estricta y encorsetada de hacer las cosas, se pierde la capacidad de buscar soluciones alternativas, que antes o después, van a ser necesarias.

Y si algo se necesita, a día de hoy, con la complejidad del software que construimos, es la capacidad de respuesta, de implementar soluciones imaginativas, de pensar sin restricciones, sin corsés. No es fácil, no...

Noviembre 01, 2005

Poster de patrones de diseño

A estas alturas seguro que has oído hablar (como mínimo) de la serie Head First, en concreto de Head First Design Patterns que probablemente sea la mejor introducción para entender los patrones de diseño.

La semana pasada, cuando estaba buscando otras cosas en amazon, me encontré con esto: Head First Design Patterns Poster.

designPatternsPoster.jpg

Como su propio nombre indica, es un poster (bastante grande, por cierto) que contiene los gráficos (extraídos del libro), no los diagramas UML de los patrones, sino los gráficos de los ejemplos del libro, así como el número de la página en la que aparece ese patrón tanto en el Gang of Four como en el Head First Design Patterns.

Resume de forma visual 18 patrones, y ahora mismo luce enfrente de mis ojos clavado en la pared...

(Por cierto, ninguno de los enlaces es patrocinado, y por tanto NO me llevo comisión).

Octubre 18, 2005

Y el patrón era...

Ayer preguntaba por el nombre de un patrón.

El patrón era el Strategy.

Octubre 17, 2005

Un ejemplo del patrón... ¡adivínalo!

EDITADO: El patrón es el Strategy. Por tanto, el título del post debería ser "Un ejemplo el patrón Strategy en actionscript"

El Profesor Dispar ha estado disfrutando de unas merecidas vacaciones tras conquistar el mundo (sí, desde la última vez que tuvimos noticias de él, ha conseguido llevar a buen puerto sus maléficos planes).

Pero el día a día de dominar el mundo le está matando de aburrimiento. El Profesor Dispar echa de menos los viejos tiempos, cuando nadie le comprendía, cuando podía odiar a todos los líderes del mundo porque le ignoraban... Ahora pasa la mayor parte del día haciendo papeleo, y añora los días en los que se podía dar una vuelta por los campamentos de sus tropas y confraternizar con ellos, contar chistes, tomar unas cervecitas...

Así que, en un arranque de genio (malvado, claro), ha decidido que, para matar el aburrimiento, quiere ver un desfile cada día. Mejor dicho, un desfile diferente cada día. Un día le pedirá a su Mariscal que le prepare un desfile con los chicos de la compañía B, otro día querrá que desfilen los soldados cuyo nombre contenga una P... ahhh, los genios del mal...

Continuar leyendo "Un ejemplo del patrón... ¡adivínalo!" »

Agosto 04, 2005

Un ejemplo del patrón memento ( la versión actionscript )

Conquistar el mundo no es fácil. Nada fácil. Yo lo sé, tú lo sabes, incluso el Profesor Dispar lo sabe.

El Profesor se siente preparado para llevar a cabo su malvado plan. Tiene el conocimiento teóricos, tiene los conocimientos prácticos, tiene un plan, tiene hasta unas gafas de sol nuevas, pero ¡hay tantos detalles que pulir antes de lanzarse a la conquista del mundo!.

En episodios anteriores, hemos visto cómo el Profesor ha implementado el patrón prototype ( para crear su ejército de clones -¡anda, acabo de caer!- ), el patrón extensión objects ( para asignarles sus roles ), el patrón command ( para asignarles las órdenes ), y el patrón observer ( para implementar el sistema de comunicaciones ). Parece que el Profesor Dispar ha estado bastante ocupado implementando patrones, pero ha sido suficiente?. NO!! ( muhahahahahahhaha ).

Continuar leyendo "Un ejemplo del patrón memento ( la versión actionscript )" »

Un ejemplo del patrón memento ( la versión java )

Conquistar el mundo no es fácil. Nada fácil. Yo lo sé, tú lo sabes, incluso el Profesor Dispar lo sabe.

El Profesor se siente preparado para llevar a cabo su malvado plan. Tiene el conocimiento teóricos, tiene los conocimientos prácticos, tiene un plan, tiene hasta unas gafas de sol nuevas, pero ¡hay tantos detalles que pulir antes de lanzarse a la conquista del mundo!.

En episodios anteriores, hemos visto cómo el Profesor ha implementado el patrón prototype ( para crear su ejército de clones -¡anda, acabo de caer!- ), el patrón extensión objects ( para asignarles sus roles ), el patrón command ( para asignarles las órdenes ), y el patrón observer ( para implementar el sistema de comunicaciones ). Parece que el Profesor Dispar ha estado bastante ocupado implementando patrones, pero ha sido suficiente?. NO!! ( muhahahahahahhaha ).

Continuar leyendo "Un ejemplo del patrón memento ( la versión java )" »

Junio 02, 2005

Un ejemplo del patrón observer (la versión Java)

Está desencadenado. El primer ataque ha sido lanzado. El profesor Dispar ha dado las órdenes a sus huestes para dominar el mundo. En post anteriores hemos visto como el profesor Dispar ha conseguido clonar cualquier animal ( con gran predilección por ovejas y vacas ) utilizando un patrón prototype, ha conseguido darlas un rol dinámicamente con el patrón extension objects, y ha repartido las órdenes con un patrón command.

Pero como ya sabemos, el profesor Dispar está loco, pero no es idiota. Sabe, que algo puede salir mal, que un pequeño detalle puede truncar sus planes de dominar el mundo. Y también sabe que una retirada a tiempo es una victoria.

Continuar leyendo "Un ejemplo del patrón observer (la versión Java)" »

Un ejemplo el patrón observer (la versión actionScript)

Está desencadenado. El primer ataque ha sido lanzado. El profesor Dispar ha dado las órdenes a sus huestes para dominar el mundo. En post anteriores hemos visto como el profesor Dispar ha conseguido clonar cualquier animal ( con gran predilección por ovejas y vacas ) utilizando un patrón prototype, ha conseguido darlas un rol dinámicamente con el patrón extension objects, y ha repartido las órdenes con un patrón command.

Pero como ya sabemos, el profesor Dispar está loco, pero no es idiota. Sabe, que algo puede salir mal, que un pequeño detalle puede truncar sus planes de dominar el mundo. Y también sabe que una retirada a tiempo es una victoria.

Continuar leyendo "Un ejemplo el patrón observer (la versión actionScript)" »

Mayo 24, 2005

Cómo utilizar los patrones de diseño

Bill Venners ha publicado una conversación con Erich Gamma, en la que hablan sobre "la forma correcta de pensar y de usar los patrones de diseño".

Entre otros puntos importantes tratan la "moda" de los patrones, la flexibilidad que aportan al diseño, cómo sirven para aprender en profundidad los conceptos más abstractos de la programación orientada a objetos...

Una lectura que creo puede resultar interesante.

Aquí está el link: How to use design patterns

Abril 26, 2005

Un ejemplo del patron Command ( la versión Java )

Todo está preparado. Las ovejas y las vacas han sido clonadas y sus roles han sido asignados. Es el momento perfecto para que el Profesor Dispar lance su ataque final. ¡¡¡¡¡Ha llegado el momento de conquistar el mundo!!!!

¿Pero cómo dará el Profesor Dispar a sus tropas la orden de atacar?

Continuar leyendo "Un ejemplo del patron Command ( la versión Java )" »

Abril 06, 2005

Un ejemplo del patrón Extension Objects ( la versión Java )

¿Recuerdas al Professor Dispar?. ¿Recuerdas sus malvados planes para dominar el mundo?.

Hoy veremos cómo el patrón Extension Objects ( o "cómo cambiar el interfaz que implementa una clase en tiempo de ejecución" ) ha ayudado al Profesor Dispar. Pero no va a ser una tarea fácil, porque este patrón es muy complejo, pero ¿quién dijo que ser un genio del mal fuera fácil?.


Continuar leyendo "Un ejemplo del patrón Extension Objects ( la versión Java )" »

Un ejemplo del patrón Extension Objects

¿Recuerdas al Professor Dispar?. ¿Recuerdas sus malvados planes para dominar el mundo?.

Hoy veremos cómo el patrón Extension Objects ( o "cómo cambiar el interfaz que implementa una clase en tiempo de ejecución" ) ha ayudado al Profesor Dispar. Pero no va a ser una tarea fácil, porque este patrón es muy complejo, pero ¿quién dijo que ser un genio del mal fuera fácil?.


Continuar leyendo "Un ejemplo del patrón Extension Objects" »

Marzo 29, 2005

Un ejemplo del Patrón Prototype ( la versión Java )

El Profesor Dispar es un científico español que está planeando dominar el mundo. ¿Quieres conocer los problemas con los que se ha encontrado, y cómo los ha resuelto implementando el patrón prototype?

Continuar leyendo "Un ejemplo del Patrón Prototype ( la versión Java )" »