Visual J++ 6.0

MokaByte Numero 23 - Ottobre 98

di Massimo Carli	Corso Swing I parte
	Cominciamo, questo mese, il corso sulle nuove GUI di Java

Iniziamo questo mese un corso sui nuovi strumenti che Java mette a disposizione per la realizzazione di interfacce grafiche. L'obiettivo di questa prima puntata è quello di esporre le motivazioni che hanno portato i programmatori della JavaSoft a creare queste nuove API e di spiegare quelle che sono le loro caratteristiche principali. La caratteristica del corso deve essere la semplicità per cui ogni aspetto sarà spiegato nei dettagli utilizzando il linguaggio più semplice possibile. Altro obiettivo che il corso intende raggiungere è quello di poter essere una guida non solo per coloro che già programmano in Java e che vogliono conoscere queste nuove classi, ma anche per coloro che iniziano a programmare avendo questa nuova realtà a disposizione. Ecco che saranno trattati anche argomenti che, a prima vista, possono sembrare slegati dalle Swing ma che sono di fondamentale importanza quali il modello per delega nella gestione degli eventi (Delegation Model) e le Inner Classes.

Un po' di Storia

Percorriamo brevemente quello che è stato il cammino intrapreso da Java nel fornire gli strumenti per la realizzazione di interfacce grafiche. La prima versione del JDK (Java Development Kit) effettivamente utilizzata, principalmente nella realizzazione di applet, è stata la 1.02. Essa prevede pochi package tra cui quello relativo alla gestione dei vari widget che compongono una GUI ovvero il famoso package java.awt, dove con AWT si intende Abstract Windows Toolkit. L'insieme dei componenti rappresentati dalle classi di questo package (Button, TextField, ecc) si rifà a widget equivalenti costruiti nel sistema operativo in cui la JVM è implementata. Questi componenti prendono il nome di peer. Le seguenti righe di codice:

Panel panel = new Panel();
Button button= new Button("Bottone");
panel.add(button);

permettono di creare un oggetto Panel che rappresenta un semplice contenitore di widget, contenente un semplice pulsante. Il bytecode relativo a queste poche righe, creato con il compilatore del JDK1.02, contiene informazioni relative al tipo di oggetto e non informazioni relative a come l'oggetto stesso è costruito. Spieghiamoci meglio. Nel nostro esempio il bytecode creato dice che abbiamo costruito un Panel al cui interno vi è un bottone. In fase di esecuzione l'interprete non crea il Panel ed il Bottone ma delega la creazione di questi componenti al sistema operativo "ospitante" la JVM. Ecco che se eseguiamo il bytecode in un sistema operativo Windows95 otteniamo una certa interfaccia mentre in altri sistemi operativi, ad esempio Solaris, l'interfaccia può apparire diversa proprio perché il pulsante ora è quello di Solaris. Portabilità non significa solamente realizzazione di programmi che funzionano correttamente in diversi SO ma anche realizzare applicazioni che, nei diversi SO, si possono mostrare allo stesso modo. Il precedente Panel deve poter essere visualizzato allo stesso modo in ogni SO in cui è definita la JVM secondo le specifiche.

NOTA: L'affermazione fatta relativamente al concetto di portabilità potrebbe non trovare tutti d'accordo. Fatto fondamentale è l'omogeneità nel funzionamento di un applicazione nelle varie piattaforme. Per quello che riguarda come l'interfaccia grafica si presenta, portabilità potrebbe significare far apparire l'interfaccia grafica come se fosse nativa al SO in cui l'applicazione è in esecuzione. Si vorrebbe, comunque, che un utente abituato ad una interfaccia grafica in ambiente Windows la ritrovi anche se eseguisse l'applicazione in ambiente Solaris. Questo è l'obiettivo delle Swing e sarà più chiaro in seguito.

L'utilizzazione dei peer presenta alcuni svantaggi. I peer non possono essere modificati nelle loro caratteristiche attraverso Java. Anzi, mentre in ambiente Solaris il Button poteva essere colorato, in ambiente Windows95 questo non poteva avvenire. Questo perché il bottone di Solaris prevedeva la possibilità di essere colorato a differenza del bottone di Windows95. Le JVM dovevano, inoltre, tenere conto dei vari bug presenti, differenti non solo tra SO diversi ma anche tra versioni dello stesso SO. Le osservazioni fatte ci inducono a dire che l'utilizzo dei peer non è la migliore soluzione per la realizzazione di interfacce uguali in ogni implementazione della JVM. Il JDK1.1 ha avuto grandissima importanza, non solo per l'introduzione di API fondamentali quali JDBC (Java DataBase Connectivity) che permettono l'accesso a DB, ma anche nel cammino verso la creazione delle GUI. Il lavoro fatto in tale senso è fondamentale anche apparentemente poco visibile. Possiamo dire che le novità principali in tale senso sono state:

°Nuova gestione degli eventi (Delegation Model) introdotta come conseguenza della pubblicazione delle specifiche JavaBeans (i componenti Java). Questa nuova gestione degli eventi permette l'interazione tra componente diversi attraverso l'utilizzo di speciali classi dette Adapter. La spiegazione di questo nuovo modello, sebbene già trattata nei numeri scorsi di MB, sarà argomento di una specifica puntata del presente corso.

°LightWeight Component ovvero la classe java.awt.Component leggera. Nel cammino verso le Swing questo passo è fondamentale. Vediamo di seguito il perché.

L'obiettivo che si vuole raggiungere è quello di poter visualizzare una certa interfaccia grafica allo stesso modo in ogni implementazione della JVM. Si è pensato allora di costruire, utilizzando le potenzialità del SO in cui la JVM è stata implementata, una tavolozza su cui disegnare, utilizzando solo Java, i vari componenti. La tavolozza in questione è proprio il LightWeight Component introdotto in precedenza. Questa classe, a differenza di quella del JDK1.02, può essere istanziata e gestisce la trasparenza. Il termine LightWeight indica che essa non utilizza più molte delle pesanti risorse del SO ma è, appunto, leggero. Il fatto di poter disegnare e gestire i vari widget utilizzando il linguaggio Java assicura che gli stessi widget siano uguali in ogni JVM di ogni SO. Questo perché sono disegnati allo stesso modo con gli stessi strumenti. Non solo. Per lo stesso motivo, è possibile disegnare uno stesso componente in modo diverso che possa richiamare il Look relativo ad un particolare SO. Facciamo quindi un ulteriore passo avanti. E' possibile creare delle interfacce grafiche che appaiono native al SO in cui l'applicazione è in esecuzione, non utilizzando i widget dello stesso SO (peer), ma disegnandoli opportunamente. Se è possibile disegnare il Button allo stesso modo nelle varie implementazioni della JVM in quanto si utilizzano le stesse istruzioni e classi Java, è possibile scegliere anche il modo in cui questo viene fatto. Ecco che si possono riprodurre, utilizzando solamente le classi Java, i widget secondo la grafica (il Look) del SO in cui l'applicazione è in esecuzione oppure secondo un Look vincolato solamente alla fantasia del programmatore. Come ultima nota diciamo che le Swing sono nate sulla base delle IFC (Internet Foundation Classes ) della Netscape (che ha collaborato con la JavaSoft ed IBM nella loro creazione) e lo vedremo nitidamente in alcuni componenti.

Ma cosa sono le Swing?

Nel paragrafo precedente abbiamo visto quelle che sono state le motivazioni che hanno portato alla necessità di creare un nuovo set di widget per la creazione di GUI in Java. Le Swing fanno parte di un insieme di package che va sotto il nome di JFC (Java Foundation Classes). Esse prevedono gruppi di classi ed interfacce che si possono suddividere in:

Swing : Nuovo set di widget per la realizzazione di GUI.

Java 2D : Insieme di strumenti per la grafica bidimensionale

Accessibility : Tool che permettono di interfacciare una applicazione con particolari sistemi (lettori Breille, riconoscitori vocali, touch screen, ecc.) utilizzati per l'accesso alla stessa da parte di utenti portatori di handicap.

Drag and Drop : Supporto al passaggio di oggetti tra due applicazioni Java o tra una applicazione Java ed una nativa al SO.

Questo corso riguarda le Swing ma presto su MB troverete un corso su Java2D ed articoli relativi al D&D e Accessibility.

Conclusioni

In questa prima puntata abbiamo introdotto le Swing attraverso la ricostruzione della storia di Java relativamente alla realizzazione di interfacce grafiche. Nella prossima puntata vedremo come questo viene ottenuto attraverso la descrizione del modello MVC (Model View Controller) introducendo poi, una delle principali caratteristiche delle Swing ovvero il PL&F (Pluggable Look and Feel).

MokaByte Web 1998 - www.mokabyte.it
MokaByte ricerca nuovi collaboratori. Chi volesse mettersi in contatto con noi può farlo scrivendo a mokainfo@mokabyte.it