INTERFACCE GRAFICHE IN JAVA - II

[Per corso su Java vedere http://java.sun.com/docs/books/tutorial/]

Contenitori in Java

Contenitori Top-level

Realizzati come finestre top-level nell'ambiente in cui sara' eseguito il programma Java.

frame:dialogo:

Contenitori intermedi

Contenitori di uso generale:
scrolled pane:split pane: tabbed pane:
Contenitori per usi speciali:
internal frames su desktop:

Dispositivi in Java

Dispositivi di controllo

In grado di ricevere input e mostrare informazioni di stato.

Vari tipi di bottoni

bottoni varii:

Vari tipi di menu' e di voci di menu'

Le classi di voci di menu' rispecchiano le classi di bottoni: Classi per i menu':
Menu' con voci di vari tipi (Swing):

Altri dispositivi

Dispositivi per mostrare informazioni

Non sensibili a input:
progression bar:

Dispositivi per mostrare / acquisire informazioni formattate

Mostrano informazioni complesse, possono essere anche editabili:
textarea:table:tree:

Dispositivi con funzioni speciali

Per scegliere un file nel file system: Per scegliere un colore: JColorChooser

Layout Management

Processo di stabilire automaticamente dimensioni e posizione delle componenti all'interno di un contenitore. Ogni contenitore ha un layout manager.

Potrei lavorare senza layout manager, ma allora dovrei fornire posizione assoluta di ogni componente all'interno del contenitore, ed avrei problemi quando il contenitore top-level viene redimensionato.

Classi di layout managers

Gestione degli eventi in Java

Parte di AWT, usate anche in Swing.

Classi di eventi

Gli eventi sono classificati a seconda della loro causa scatenante, che puo' essere: Classi di eventi hanno nomi del tipo XXXEvent dove XXX e' la causa. Es: MouseEvent...

Ogni classe di componente e' una potenziale sorgente di certe classi di eventi. Es: un bottone puo' originare eventi di classe "azionamento" (classe ActionEvent).

Event listeners

Posso registrare un event listener per ricevere eventi di una certa classe da una certa componente dell'interfaccia.

Vi e' un event listener per ogni classe di evento: se la classe evento e' XXXEvent, la classe listener e' XXXEventListener. La classe listener prevede uno o piu' metodi che scattano quando il listener riceve un evento di quella classe.
In realta' un listener non e' una classe, ma un'interfaccia (come una classe, ma l'implenentazione dei metodi non e' definita).

Stabilita la classe di eventi che voglio catturare, devo creare una sottoclasse del listener corrispondente, fornendo il codice dei suoi metodi (essendo i listener interfacce e non classi, non si dice "sottoclasse" bensi' "implementazione").
Poi associo il listener alla componente sulla quale voglio catturare gli eventi.

Esempio: voglio catturare azionamento di un bottone.

Quando l'utente azionera' il bottone, scattera' l'action listener che eseguira' le operazioni.

Questo paradigma si chiama delegation perche' il bottone delega l'azione da eseguire ad un altro oggetto (il listener).

Posso associare lo stesso event listener a piu' componenti nell'interfaccia: questi reagiranno allo stesso evento nello stesso modo.
Posso associare piu' event listener allo stesso oggetto: questo avra' piu' reazioni.

Il fatto che i listeners siano interfacce e non classi (cioe' che non implementino i metodi) implica che per i listener che hanno piu' metodi devo fornire un'implementazione di tutti i metodi, inclusi quelli che non mi interessano (l'implementazione di questi non fara' nulla: {}).
Per comodita' sono forniti adapters che forniscono implementazione standard di un listener (dove tutti i metodi non fanno nulla): creo sottoclasse dell'adapter ridefinendo solo i metodi che mi interessano.

Esempio: La classe WindowEvent corrisponde a eventi sulle finestre top-level: apertura / chiusura, iconificazione / deiconificazione...
La classe WindowListener ha un metodo per ciascuno degli eventi di cui sopra. Se voglio reagire solo all'evento di chiusura: