Swing y JFC (Java Foundation Classes)

Cuando el AWT llama a un m�todo oyente de evento, este m�todo se ejecuta en el thread de eventos del AWT. Como todos los dem�s manejos de eventos y los m�todos de dibujo se ejecutan en el mismo thread, un lento m�todo de manejo de eventos puede hacer que el programa parezca no responder y puede relentizar el propio dibujado.

Si necesitas realizar alguna operaci�n lenta como resultado de un evento, hazlo arrancado otro thread (o enviando una petici�n a otro thread) para realizar la operaci�n.

La siguiente subsecci�n presenta el ascentro de todas las clases evento del AWT, la clase AWTEvent. Depu�s, Usar adaptadores y Clases Internas para Manejar Eventos AWT te ofrecer� trucos para evitar un c�digo borroso..

�La clase AWTEvent

Todo m�todo en un interface oyente de evento del AWT tiene un s�lo argumento, un ejemplar de una clase que descienda de la clase java.awt.AWTEvent. Esta clase no define ning�n m�todo o API que podamos usar normalmente. Sin embargo, hereda un m�todo muy �til de la clase java.util.EventObject.

Object getSource()

devuelve el objeto que gener� el evento.

Observa que el m�todo getSource devuelve un Object. Siempre que sea posible, las subclases de AWTEvent definen m�todos similares con tipos de retorno m�s restrictivos. Por ejemplo, la clase ComponentEvent define un m�todo getComponent que devuelve el Component que gener� el evento.

LA figura 68 muestra la herencia de clases de AWTevent. Como se puede ver muchas, pero no todas, las clases de eventos del AWT descienden de la clase ComponentEvent.

El �rbol de herencia de las clases de eventos AWT.

�Eventos Estandard del AWT

El AWT define cerca de una docena de tipos de oyentes de eventos. Se puede decir los tipos de eventos que puede generar un componente mirando las clases de oyentes de eventos que podemos registrar en �l. Por ejemplo, la clase Component define estos m�todos de registros de oyentes.

• addComponentListener
• addFocusListener
• addKeyListener
• addMouseListener
• addMouseMotionListener

Por lo tanto, toda clase que descienda de Component soporta oyentes de component, focus, key, mouse y mouse-motion. Sin embargo la mayor�a de los ejemplares de Component no generan estos eventos; un componnete genera s�lo aquellos eventos para los que los oyentes se han registrado. Por ejemplo, so un oyente de mouse se regostra en un componente particular, y el componente no tiene otros oyentes, entonces el componente s�lo generara eventos de mouse.

�Usar Adaptadores y Clases Internas para Manejar Eventos

Esta secci�n explica c�mo utilizar adaptadores y clases internas para reducir la sobrecarga del c�digo.

La mayor�a de los interfaces de oyentes, al contrario que ActionListener, contienen m�s de un m�todo. Por ejemplo, el interface MouseListener contiene cinco m�todos:mousePressed, mouseReleased, mouseEntered, mouseExited, y mouseClicked. Incluso si s�lo te importan las pulsaciones, si tu clase implementa directamente MouseListener, entonces debes implementar los cinco m�todos de MouseListener. Aquellos m�todos de eventos que no te interesan pueden tener los cuerpos vac�os. Aqu� hay un ejemplo.

//An example with cluttered but valid code.
public class MyClass implements MouseListener {
    ...
	someObject.addMouseListener(this);
    ...
    /* Empty method definition. */
    public void mousePressed(MouseEvent e) {
    }

    /* Empty method definition. */
    public void mouseReleased(MouseEvent e) {
    }

    /* Empty method definition. */
    public void mouseEntered(MouseEvent e) {
    }

    /* Empty method definition. */
    public void mouseExited(MouseEvent e) {
    }

    public void mouseClicked(MouseEvent e) {
	./Event handler implementation goes here...
    }
}

Desafortunadamente, la colecci�n de cuerpos de m�todos vacios resultante puede resultar dura de leer y de mantener. Para ayudarnos a evitar este emborronamiento del c�digo con cuerpos de m�todos vacios, el AWT y Swing proporcionan una clase adapter por cada interface de oyente con m�s de un m�todo. (Manejar Eventos Comunes lista todos los oyentes y sus adaptadores.) Por ejemplo, la clase MouseAdapter implmenta el interface MouseListener. Una clase adaptador implementa versiones vac�as de todos los m�todos del interface.

Para usar un adaptador se crea una subclase, en vez de implementar directamente un interface de oyente. Por ejemplo, extendiendo la clase MouseAdapter, nuestra clase hereda definiciones de vac�as para los m�todos que contiene MouseListener.

/*
 * An example of extending an adapter class instead of
 * directly implementing a listener interface.
 */
public class MyClass extends MouseAdapter {
    ...
	someObject.addMouseListener(this);
    ...
    public void mouseClicked(MouseEvent e) {
	./Event handler implementation goes here...
    }
}

�Qu� pasa si no queremos que nuestras clases de manejo de eventos desciendan de una clase adaptador? Por ejemplo, supongamos que escribimos un applet, y queremos que nuestra subclase Applet contenga alg�n m�todo para manejar eventos de rat�n. Como el lenguaje Java no permite la herencia m�ltiple, nuestra clase no puede descender de las clases Applet y MouseAdapter. La soluci�n es definir una clase interna -- una clase dentro de nuestra subclase Applet -- que descienda de la clase MouseAdapter,

//An example of using an inner class.
public class MyClass extends Applet {
    ...
	someObject.addMouseListener(new MyAdapter());
    ...
    class MyAdapter extends MouseAdapter {
        public void mouseClicked(MouseEvent e) {
	    ./Event handler implementation goes here...
        }
    }
}

Aqu� hay otro ejemplo de uso de clases internas.

//An example of using an anonymous inner class.
public class MyClass extends Applet {
    ...
	someObject.addMouseListener(new MouseAdapter() {
            public void mouseClicked(MouseEvent e) {
	        ./Event handler implementation goes here...
            }
	});
    ...
    }
}

Las clases internas funcionan bien incluso si nuestro manejador de eventos necesita acceder a ejemplares de variables privadas de la clase que la encierra. Siempre que no declaremos una clase interna como static, se podr� referir a ejemplares de variables y m�todos como lo hace el resto de c�digo que contiene la clase. Para hacer que una variable local est� disponible para una clase interna solo tenemos que hacer un copia de la variable como una variable local final.