|
Los contenedores del AWT suelen tener asociados un “LayoutManager” predeterminado, pero, de cualquier manera, el programador podrá decidir la disposición que prefiera para un contenedor dado usando de la función siguiente en el ámbito del contenedor apropiado:
void setLayout( LayoutManager instanciaExtensionLayoutManager );
a la que se pasa como parámetro una instancia de una clase derivada-de (extensión-de) LayoutManager (no olvidemos que ésta es una clase abstracta y, por tanto, no puede instanciarse), bien de las vistas anteriormente bien de las codificadas por algún inquieto codificador compulsivo:
setLayout( new BorderLayout() );
setLayout( new FlowLayout( FlowLayout.CENTER, 7, 7 );
EVENTS
Un contenedor “soltado” en un entorno gráfico se convierte en rápido receptor de eventos de todo tipo, singularmente de los relacionados con movimientos del ratón, pulsaciones de teclas, creación/movimiento/destrucción de partes gráficas y, por último, los referidos a acciones del usuario respecto de componentes (elección de un menú, presionado de un botón, etc.).
Los eventos de ratón se controlan mediante funciones que provienen de la clase “java.awt.Component”:
public boolean mouseDown( Event evt, int x, int y );
public boolean mouseDrag( Event evt, int x, int y );
public boolean mouseEnter( Event evt, int x, int y );
public boolean mouseExit( Event evt, int x, int y );
public boolean mouseMove( Event evt, int x, int y );
public boolean mouseUp( Event evt, int x, int y );
al igual que los de pulsación de teclas:
public boolean keyDown( Event evt, int key );
public boolean keyUp( Event evt, int key );
En cuanto a los de movimiento de partes gráficas, ya tendremos tiempo de examinarlos cuando estudiemos la actualización visual de los applets. Quedan, pues, las acciones, y éstas pueden ser captadas mediante la sobrecarga de dos distintos métodos de “Component”:
public boolean handleEvent( Event evt )
{
// todos los eventos están relacionados en la clase Event.
switch( evt.id ) {
case Event.KEY_PRESS:
// código a ejecutar ante una pulsación de tecla.
break;
case Event.WINDOW_MOVED:
// código para atacar un movimiento de ventana.
return true;
default:
// lanza el evento hacia arriba en la jerarquía para
// todos aquellos casos (eventos) no contemplados aquí.
return super.handleEvent( evt );
}
return false;
}
y la más frecuentemente usada (en lo poco visto, claro):
public boolean action( Event evt, Object arg )
{
if (arg instanceof String ) {
// ejecuta alguna acción con la cadena
// no debiendo olvidar el cast: “(String)arg”
}
return false; // remite el evento al manejador por defecto
}
Como en la mayoría de bibliotecas gráficas de C++, el mecanismo de devolución de valor es sencillo: si la clase consume el evento simplemente devuelve “true”, pues si el valor de retorno es “false” el AWT entenderá el evento como no consumido y actuará en consecuencia manejándolo.
PANEL
Esta clase representa el más simple de los contenedores de componentes gráficos. En realidad se trataba de crear una clase no-abstracta (Container sí lo es) que sirviera de base a los applets y a otras pequeñas aplicaciones. La clase Panel consta de dos métodos propios: el constructor, cuyo fin es crear un nuevo Panel con un LayoutManager de tipo FlowLayout, y el método “addNotify()” que, sobrecargando la función del mismo nombre en la clase Container, llama al método createPanel() del ToolKit adecuado, creando así un “PanelPeer”. El AWT enviará así al Panel (y por ende al Applet) todos los eventos que sobre él ocurran. Esto, que puede sonar un poco rebuscado, obedece al esquema arquitectónico de la AWT, principal causa actual de la mayoría de los problemas de Java. En realidad se trata de un bien conocido esquema de separación interfaz/implementación que establece por un lado una clase de “interfaz” y por otro distintas clases de “implementación” para cada una de las plataformas elegidas.
APPLET
Vale la pena detallar el interfaz de la clase Applet (según MS Visual J++):
public class java.applet.Applet extends java.awt.Panel
{
// Constructor
public Applet();
// Métodos
// destruye el applet y libera los recursos adquiridos
public void destroy();
// devuelve información del contexto del applet
// (usualmente el visor web)
public AppletContext getAppletContext();
// procura información sobre autor, nombre applet, etc.
public String getAppletInfo();
// devuelve un clip de audio adscrito a una URL o Null
public AudioClip getAudioClip(URL url);
public AudioClip getAudioClip(URL url, String nombre);
// proporciona la URL del applet
public URL getCodeBase();
// procura la URL del documento que embebe al applet
public URL getDocumentBase();
// capta una imagen (con nombre o no) en una URL
public Image getImage(URL url);
public Image getImage(URL url, String nombre);
// recupera un parámetro del applet mediante su nombre
public String getParameter(String nombre);
// devuelve un array con los parámetros pasados al applet
public String[][] getParameterInfo();
// inicialización automática del applet (variables, etc.)
public void init();
// indica si el applet está activo o no
public boolean isActive();
// interpreta un clip de audio
public void play(URL url);
public void play(URL url, String nombre);
// cambia el tamaño del applet
public void resize(Dimension d);
public void resize(int ancho, int alto);
// el interfaz entre el visor y el applet
public final void setStub(AppletStub stub);
// muestra mensaje en el contexto del applet (vg, un visor)
public void showStatus(String mensaje);
// activa el applet automáticamente cuando está a la vista
public void start();
// desactiva el applet cuando queda fuera del campo de visión
// o justo antes de llamar a destroy()
public void stop();
}
de forma que podamos rápidamente pasar a la programación.
EL CÓDIGO
Examinemos un elemental applet:
import java.applet.*;
import java.awt.*;
La palabra clase “import” es una mezcolanza de “#include” y “namespace” de C++, que hace visibles en nuestro código las clases correspondientes a los paquetes (packages) que se indican. Si tales líneas se omitieran podríamos seguir accediento a las clases necesitadas únicamente cualificándolas con su dirección (path) completa: así para usar Applet, deberíamos codificar “java.applet.Applet”. El hecho, con todo, de que la jerarquía de clases se corresponda con el árbol de directorios da mucho que pensar.
public class Prueba extends Applet implements Runnable {
La palabra reservada “extends” indica que la clase “Prueba” es, en este caso, una subclase (deriva) de la clase “Applet”, e “implements” señala que nuestra clase viene obligada a implementar la funcionalidad del “interfaz” Runnable.
Thread m_Prueba = null;
StringBuffer buffer;
Estas son variables de la clase.
void muestra( String frase ) {
System.out.println( frase );
buffer.append( frase );
repaint();
}
Necesitamos de esta típica función de ayuda (helper function) que evitará la repetición del mismo código en el resto de los métodos, que en el siguiente bloque de código se detallan en estricto orden de ejecución (init, start, paint, stop, destroy):
public void init() {
buffer = new StringBuffer();
// El establecimiento del color evita “flicks”
setBackground( Color.white );
muestra( “Inicialización” );
}
Aquí se inicializan las variables, pues éste es el método que primera y únicamente es llamado por el sistema al cargar un applet.
public void start() {
// esta función
muestra( “Comienza la acción” );
}
La función start() es automáticamente llamada cada vez que la zona de visualización en que está ubicado el applet se expone a la visión, a fin de optimizar el uso de los recursos del sistema y no ejecutar algo que no puede ser apreciado (aunque el programador puede variar este comportamiento y hacer que un applet siga activo aun cuando esté fuera del área de visión). Esto es, imaginemos que cargamos un applet en un visor minimizado: el sistema llamará al método init(), pero no a start(), que sí será llamado cuando restauremos el visor (browser) a un tamaño que permita ver el applet. Naturalmente start() se puede ejecutar varias veces: la primera tras init() y las siguientes (pues init() sólo se ejecuta una vez) tras haber aplicado el método stop().
public void paint( Graphics g ) {
// dibuja un rectángulo alrededor del área de visión del applet
g.drawRect( 0, 0, size().width -1, size().height - 1 );
// dibuja la cadena dentro del anterior rectángulo
g.drawString( buffer.toString(), 5 15 )
}
Entramos aquí de lleno en las cuitas gráficas de la biblioteca AWT. Cada vez que la zona del applet es cubierta por otra ventana (y singularmente la primera vez que se carga el applet), el scroll desplaza el applet fuera de la zona de visión o el applet cambia de posición debido a un redimensionamiento del visor, el sistema llama automáticamente a la función “paint” pasando como argumento un objeto de tipo “Graphics” que delimita la zona a ser pintada (en realidad se pasa una referencia al contexto gráfico en uso) y que, en nuestro caso, representa la ventana del applet en la página web. Sobre este objeto gráfico podemos realizar operaciones, como las que se exponen arriba.
public void update( Graphics g ) {
paint( g );
}
Hemos dicho que, en las situaciones detalladas anteriormente que “dañan” la zona de exposición del applet, el sistema llama a la función “paint”, pero en realidad la llamada se realiza a la función “update”, cuyo comportamiento establecido en la clase “Component” es llamar a la función “paint” … ¡tras rellenar el applet con su color de fondo por defecto! Pudiera así parecer que se trata de una función de efecto neutro, pero si la función “paint” cambiara el color de fondo, el usuario percibiría un “flick” de cambio de colores nada agradable. El programador deberá cuidarse por lo común, así, de eliminar este efecto de “limpia primero” sobrecargando la función “update” para que llame únicamente a “paint”. Otra solución sería insertar el código de pintado en una sobrecarga de la función “update” y escribir un método “paint” que sólo llame a “update”. La última solución es usar de la función “setBackground(Color)” en el método “init” para así evitar el efecto visual sin tener que sobrecargar el método “update”. Estas razones son las mismas que aconsejan usar el método “resize” inserto en “init” para evitar el mismo desagradable efecto.
public void stop() {
muestra( “Paraliza la acción” );
}
public void destroy() {
muestra( “Liberación de recursos” );
}
}
La función “stop” es llamada cuando el visor web no incluye en su campo de visión al applet (por ejemplo, cuando abandona la página en que está inserto), de forma que el programador puede aquí paralizar los hilos (threads) que no resulten necesarios respecto de un applet no visible, y luego recuperar su actividad mediante la función “start”. El método “destroy” se llama (siempre después de “stop”) cuando necesitan ser liberados todos los recursos dispuestos por un applet (por ejemplo, cuando se cierra el visor web).
Queda notar, entre otras muchas cosas que requerirán del esforzado lector un estudio atento de la biblioteca de clases Java, que se podrá forzar la actualización de un applet (la llamada a “update”) mediante el uso de la función “repaint” (con distintas signaturas que incluyen tiempo de repintado y localización cartesiana, aparte de la mera función sin argumentos). Pero, ojo, AWT posee “cierta inteligencia” (esta conjunción suele resultar nefasta), de forma que si se llama a “update” mediante “repaint” con una frecuencia muy corta, AWT ignorará las llamadas a “update” que estime oportuno, pues considera a esta función un bien escaso.
CONSTRUCCIÓN ASISTIDA DE APPLETS
Parece prudente esperar que un lenguaje supuestamente avanzado como Java presente un entorno de desarrollo también avanzado, de forma que no tengamos que codificar los applets “a pedal”. Bien, así es, más o menos. Existen muchos entornos de este tipo: Symantec Espresso/Café, Java WorkShop, IBM VisualAge for Java, Microsoft Visual J++, etc., y de entre todos ellos a efectos pedagógicos nos quedaremos, por sus prestaciones y adecuado IDE, con el de Microsoft, que cada vez lo va haciendo mejor. |
