MokaByte Numero 13 - Novembre 1997
		Le Swing API
	di Massimo Carli	Iniziamo questo mese un corso sui nuovi componenti leggeri che faranno parte dell'attesissimo JDK1.2

Un po' di storia

Prima del 1995 nessuno poteva prevedere quale fosse stato l'impatto che Java avrebbe avuto nel mondo dell'informatica. Nato come linguaggio per la programmazione di dispositivi elettronici di consumo (lavatrici, televisori, ecc.), Java si è subito affermato come linguaggio per lo sviluppo del software per internet. In questi anni Java è maturato notevolmente non solo nel linguaggio ma soprattutto negli strumenti. Non poteva mancare, quindi, un miglioramento anche nella gestione dell'interfaccia grafica ovvero nell'uso di quello che si chiama AWT (Abstract Window Toolkit). L'originale AWT era stato progettato tenendo conto della necessità di creare dei semplici componenti per la realizzazione di applet piuttosto che orientarsi verso la creazione di oggetti di elevate prestazioni. L'originale AWT era stato costruito per convivere con un modello di gestione degli eventi basato sulla ereditarietà che non poteva affermarsi anche nelle versioni successive di Java data la difficoltà nella creazione di interazioni tra oggetti non legati tra loro da vincoli di parentale appunto. L'originale AWT era privo di molti strumenti che ci si aspetta di trovare in un linguaggio come java tra i quali: il supporto alla stampa, la gestione della navigazione con tasti, uno scroll pane, ecc. Il peggior difetto dell'AWT è sempre stato, comunque, il grande numero di bug, molti dei quali legati all'utilizzo dei famosi peer. Se andiamo ad osservare le classi relative alla versione 1.02 del JDK, notiamo la presenza di moltissime classi cosiddette peer. Per ogni oggetto presente nell'awt esisteva un oggetto peer che non era altro che il relativo oggetto nel sistema operativo relativo alla implementazione della JVM. Questo approccio basato sui peer, che utilizza componenti nativi, non permette di raggiungere completamente l'obiettivo della portabilità in quanto capitava che una interfaccia grafica apparisse in un modo su una piattaforma e completamente diversa in un'altra con ovvie conseguenze. Invece che creare nuovi e migliori componenti java, i programmatori JavaSoft impegnavano il loro tempo a scovare e correggere le varie bug dei vari peer. La necessità di un'alternativa divenne allora scontata. La sensazione che le AWT fossero "alla frutta" era ormai evidente tanto che iniziarono ad affermarsi componenti di terze parti come le IFC (Internet Foundation Classes) della Netscape. Furono proprio le IFC a convincere la JavaSoft a intraprendere, con la Netscape, la strada verso la realizzazione di un insieme di componenti leggeri e potenti che sostituissero le vecchie classi dell'AWT. Nascono quindi le JFC (Java Foundation Classes).
 

Cosa sono le JFC?

Le Java Foundation Classes sono un insieme di API (Application Program Interface) che comprendono:

1) L'Abstract Window Toolkit relativo al JDK1.1 che comprende già i componenti leggeri (LightWeight Component) e la gestione degli eventi secondo il modello per delega (Delegation Model) nato a seguito e per le specifiche JavaBeans.
2) I componenti Swing che rappresentano l'argomento di questo corso
3) Le Java 2D API che verranno trattate dal nostro esperto di grafica DeRiso.
4) Accessibility API attraverso le quali lo sviluppatore Java sarà in grado di creare delle applicazioni Java che possono interagire con altre tecnologie quali riconoscitori vocali, touch screen ed altro.

Le JFC sono basate sul core delle AWT del JDK1.1 il quale comprende:

1) Modello degli eventi per delega
2) Componenti leggeri
3) Clipboard e gestione del trasferimento dei dati
4) Stampa ed operazioni mouseless (senza l'utilizzo del mouse).

In sintesi, le Swing (swing non è un acronimo) sono una collezione di componenti leggeri costruiti sull'AWT del JDK1.1 che forniscono componenti quali:

* Borders
* Buttons
* Icons
* Tables

e molti altri che vedremo durante il corso.
 

Lo schema Model/View/Controller

In questo paragrafo vediamo cosa è una architettura MVC e come viene implementata nelle JFC. L'architettura Model/View/Controller è stata introdotta come parte della versione Smalltalk-80 del linguaggio di programmazione Smalltalk (un linguaggio object oriented abbastanza popolare inventato da Alan Kay). L'architettura MVC è stata introdotta per facilitare la programmazione in sistemi che hanno rappresentazioni multiple e sincronizzate di uno stesso insieme di dati. La caratteristica principale di questa architettura è che le sue varie parti, che sono il modello, i controller e le view, sono trattate come entità distinte e che una qualunque variazione fatta al modello da parte di un qualunque controller, si deve riflettere immediatamente in tutte le view. In pratica le view devono esprimere in ogni istante lo stato del modello. Il MVC ha i seguenti vantaggi:

1) C'e' una netta separazione tra i vari componenti di un programma i quali possono essere sviluppati indipendentemente l'uno dagli altri
2) Esistono delle API ben definite che, se opportunamente utilizzate, fanno in modo che la modifica del codice relativo ad un componente non abbia come conseguenza la modifica di un qualunque altro.
3) Il collegamento tra il modello e il view (l'interfaccia grafica per intenderci) avviene a runtime e non in fase di compilazione.

L'architettura Model/View/Controller permette la progettazione e la programmazione dei vari componenti in modo indipendente tra loro collegandoli solamente in runtime. Se un componente dovesse diventare inutilizzabile, può essere sostituito senza influire sugli altri componenti.
Ma cosa sono in pratica il Model, le View ed i Controller? Il modello è quell'oggetto che rappresenta i dati nel programma. Esso gestisce i dati e ne regola l'elaborazione. Il modello non è a conoscenza dei suoi controller e tanto meno delle sue view; non contiene riferimenti ad essi. Piuttosto, è il sistema che si prende la responsabilità di mantenere i link tra il modello e le sue view e di notificare a quest'ultime le variazioni nei dati del modello.
Le view sono quegli oggetti che gestiscono la rappresentazione visuale dei dati del modello. Esse producono la rappresentazione visuale dell'oggetto modello e visualizza i dati allo user. Esso interagisce con il modello attraverso un riferimento ad esso.
Ultima componente è il controller che permette all'utente di interagire con l'ambiente modificando i dati contenuti nell'oggetto modello. Esso è responsabile, in sintesi, delle operazioni di interazione dell'utente con il modello e della conseguente modifica della rappresentazione attraverso le view. Esso interagisce con il modello attraverso un riferimento ad esso.
Per concludere il paragrafo facciamo un semplicissimo esempio. Consideriamo un pulsante che, mentre è tenuto premuto, cambia colore. In questo caso il modello sarà rappresentato da una variabile interna che memorizza le informazioni relative al colore, la view è rappresentata dalla colorazione del bottone ed il controller è i modulo di gestione dell'evento di pressione. Quando si preme il pulsante si agisce sul modello a cui corrisponde una view particolare. Questo esempio, molto semplice, non si discosta molto da quella che è l'implementazione dell'architettura MVC nelle Swing Api che inizieremo a vedere nel paragrafos seguente.
 

MVC e JFC

Una caratteristica degli oggetti swing è quella che si riassume nei termini "pluggable look-and-feel" che permette di ottenere un maggiore affidabilità e consistenza delle applicazioni ed applet nelle varie piattaforme. Esso fornisce un potente meccanismo per individuare la rappresentazione visuale più adatta di un componente senza dover necessariamente ereditare l'intero componente utilizzato fino a quel momento nella stessa applicazione. Con la pluggable look-and-feel è possibile fare in modo che l'utente modifichi l'aspetto visual dell'applicazione o applet a runtime senza il bisogno di riavviare l'applicazione ed utilizzando sempre un aspetto a loro famigliare. Questa caratteristica è particolarmente utile a coloro che andranno ad utilizzare Network Computer che potranno scegliere l'aspetto dell'applicazione a loro più semplice.
La versione delle Swing API fornite con il JDK1.2 supporteranno due implementazioni del look-and-fell:

1) basic look-and-feel : produrrà una serie di componenti caratteristici degli ambienti windows
2) IFC style look-and-fell : produrrà un look simile a quello delle IFC di Netscape

Aspetto fondamentale diventa, inoltre, ala possibilità di integrare, senza notevoli sforzi, nuovi stili di look-and-feel adattabili ai componenti già creati e disponibili.
La capacità di passare velocemente da un stile look-and-feel ad un altro è il risultato della implementazione delle MVC. Esse, infatti, dividono ciascun componente nelle suddette tre parti:

1) Modello : contiene le informazioni relative allo stato del componente
2) View : rappresentazione visuale del modello (look)
3) Controller : gestione degli eventi

Il L&F (look-and-fell) di ciascun componente è integrato nelle parti relative alle view ed al controller. Differenti tipi di view (look) e controller (feel) possono essere implementati su un singolo modello. Ciascuna delle tre parti del MVC ha la sua specifica area di responsabilità.
Rispetto ad una architettura MVC classica, le Swing presentano alcune particolarità. Nella implementazione dell'architettura MVC nelle Swing API, il modello non è solamente responsabile della gestione dei dati ma deve gestire anche quelli che sono gli ascoltatori della variazione dei dati stessi. Nel caso specifico delle Swing, se abbiamo un bottone che viene premuto, il modello dovrà contenere anche i riferimenti agli ascoltatori che dovrà avvisare quando l'evento si verificherà (delegation model).
Le Views devono in ogni istante fornire una rappresentazione dello stato del modello. Esse dovranno quindi essere in ascolto degli eventi del modello, visualizzando le opportune modifiche grafiche.
Infine, i controller ascoltano il verificarsi di eventi e reagiscono di conseguenza. Nel nostro contesto chiameremo sempre i controller con il termine di listener. In pratica quando parliamo di controller nell'architettura MVC parliamo di listener nel delegation model.
Attraverso la separazione delle repsnsabilità tra view, modelli e listener, si ottengono componenti realizzabili da parti distinte ed intercambiabili. Un bottone, per esempio, può essere visualizzato come in un ambiente Windows95 oppure Macintosh o persino secondo una view personalizzata. Le Swing permettono di modificare il L&F di un singolo componente o di un insieme di componenti ricorsivamente contenuti in un container.
Nel prossimo articolo vedremo, in modo più dettagliato e con l'ausilio di alcuni esempi, come realizzare P&L personalizzati di uno stesso componente Swing.
 
 

	MokaByte rivista web su Java MokaByte ricerca nuovi collaboratori Chi volesse mettersi in contatto con noi può farlo scrivendo a mokainfo@mokabyte.it