Wikipedia

Swing (Java)

libreria grafica per Java

Swing è un framework per Java, appartenente alle Java Foundation Classes (JFC) e orientato allo sviluppo di interfacce grafiche. Parte delle classi del framework Swing sono implementazioni di widget (oggetti grafici) come caselle di testo, pulsanti, pannelli e tabelle.

Esempio di interfaccia grafica Swing. La renderizzazione dei font potrebbe variare a seconda della piattaforma utilizzata.

La libreria Swing viene utilizzata come libreria ufficiale per la realizzazione di interfacce grafiche in Java. È un'estensione del precedente Abstract Window Toolkit. La differenza principale tra i due è che i componenti Swing sono scritti completamente in codice Java.

Storia modifica

La Internet Foundation Classes (IFC) era una libreria grafica per Java sviluppata originalmente dalla Netscape Communications Corporation e distribuita per la prima volta nel 16 dicembre 1996.

Il 2 aprile 1997, Sun Microsystems e Netscape Communications Corporation annunciarono la loro intenzione di combinare IFC con altre tecnologie per creare la Java Foundation Classes. Oltre ai componenti originalmente forniti da IFC, Swing introdusse un meccanismo che permetteva il look and feel di ogni componente di una applicazione di essere alterato senza dover fare cambiamenti significativi al codice sorgente. L'introduzione del supporto al look and feel a plug-in permise ai componenti Swing di emulare l'apparenza dei componenti nativi mantenendo comunque il beneficio di essere indipendenti dalla piattaforma. Questa caratteristica rende molto semplice l'avere un look di una applicazione individuale che appare significativamente differente da tutti gli altri programmi nativi.

Originalmente distribuito come una libreria scaricabile separatamente, Swing fu inclusa come parte della Java Standard Edition fin dalla versione 1.2. Le classi Swing sono contenute nella gerarchia package.

Architettura modifica

Swing è una libreria

  • indipendente dalla piattaforma
  • orientata ai componenti
  • estendibile
  • modificabile
  • configurabile
  • loosely-coupled (ad accoppiamento debole)
  • leggera
  • a spedizione di eventi
  • un framework GUI MVC
  • con un thread unico
Indipendente dalla piattaforma
Swing è indipendente dalla piattaforma sia in termini di linguaggio (Java) sia della sua implementazione (una renderizzazione universale e non nativa dei widget).
Estendibile
le diverse parti della libreria Swing sono basate su determinate interfacce e sono collegate in modo da consentire facilmente l'aggancio di implementazioni diverse di queste interfacce. Il programmatore può creare un'implementazione personalizzata di queste interfacce o utilizzare le versioni di default.
Orientata ai componenti
Swing è un framework basato su componenti. Un componente è un oggetto con determinate caratteristiche di comportamento conosciute e specificate. Gli oggetti Swing emettono eventi in modo asincrono, hanno caratteristiche legate ad essi stessi, e rispondono da un ben preciso set di comandi (specifico per componente). In particolare i componenti Swing Java Beans seguono le specifiche dell'architettura JavaBean.
Modificabile
l'applicazione ha modo di ottenere un preciso controllo della renderizzazione dei componenti con i quali è realizzata l'interfaccia grafica. La rappresentazione grafica di un componente swing è data da una combinazione di un set standard di elementi; in particolare, ad ogni componente è affidato il disegno dei bordi, delle rientranze, delle decorazioni, ecc. Solitamente, gli utenti modificano un componente standard di Swing (come una JTable) assegnando bordi, colori, sfondi specifici come proprietà del componente. Il componente userà queste proprietà all'atto del disegnarsi.
Configurabile
Swing, facendo un uso pesante dei meccanismi di runtime e dei percorsi di renderizzazione indiretta, ha la possibilità di modificare a runtime cambiamenti anche fondamentali nei suoi settaggi. Per esempio, una applicazione basata su Swing può cambiare il suo look and feel a runtime (per esempio, dal look and feel di MacOS a quello di Windows XP). Inoltre, gli utenti possono fornire le loro proprie implementazioni di look and feel, il che permette di ottenere cambiamenti uniformi nei look and feel di applicazioni Swing esistenti, senza dover modificare in profondità il codice sorgente dell'applicazione.
Leggera
La configurabilità di Swing è anche dovuta al fatto che non necessita di usare i controlli della GUI del SO nativi per la rappresentazione, ma piuttosto "disegna" i suoi controlli costantemente, attraverso l'uso delle API 2D di Java. Inoltre, un componente Swing non deve necessariamente un corrispettivo nell'insieme dei componenti nativi del SO, e questo significa che è possibile realizzare componenti con la massima libertà, sfruttando a propria discrezione le potenzialità messe a disposizione dalle librerie grafiche di Java 2D.
Loosely-Coupled/MVC
La libreria Swing fa un forte uso del design pattern Model/View/Controller, il quale concettualmente disaccoppia i dati mostrati ed i controlli dell'interfaccia utente attraverso i quali sono mostrati. Grazie a questo, la maggior parte dei componenti Swing hanno associati modelli (specificati in termini di Java interfaces), il programmatore può usare varie implementazioni di default o crearne di proprie. Il framework fornisce implementazioni di default di modelli per le interfacce per tutti i suoi componenti.

Tipicamente, gli oggetti dei modelli dei componenti Swing sono responsabili di provvedere ad una concisa interfaccia per la definizione degli eventi che vengono emessi, nonché proprietà accessibili per il modello dei dati da usare con i JComponent associati. Dato questo il modello di sviluppo MVC è un percorso loosely-coupled di oggetti in relazione collaborativamente, il modello provvede i consueti modi per creare event listeners agli oggetti del data model. Tipicamente, questi eventi sono model centric (ad esempio: l'inserimento di righe in un modello di tabella) e sono mappati dalla specializzazione del JComponent in un ben preciso evento per il componente GUI.

Per esempio, il JTable ha un modello chiamato TableModel che descrive una interfaccia per come una tabella dovrebbe accedere ai dati. Una implementazione di default di questo opera su di un array bidimensionale.

La componente visiva di un JComponent Swing è l'oggetto usato per "rappresentare" graficamente il controllo GUI concettuale. Una distinzione di Swing, come framework GUI, è il suo utilizzo sulla continua rappresentazione di controlli GUI (al contrario dell'uso dei componenti nativi della gui del SO). Questa distinzione è fonte di complicazione quando si mischiano controlli AWT, che usano controlli nativi, con controlli Swing in una GUI.

Deve essere notato che il tipico uso del framework Swing non richiede la creazione di modelli modificati, siccome il framework fornisce un insieme di implementazioni di default che sono trasparentemente, per default, associati con le corrispondenti figlie della classe JComponent nella libreria Swing. In generale, solo componenti complessi come le tabelle e le viste di collezioni potrebbero aver bisogno di modifiche ai loro modelli di default[1].

Legami con AWT modifica

 
Schema che illustra l'organizzazione dei componenti grafici AWT e dei componenti grafici Swing.

La libreria Swing è un'estensione di AWT, più che un suo sostituto. Infatti ogni interfaccia grafica Swing lightweight è basata su un componente AWT heavyweight, perché tutti i componenti top-level in Swing estendono i container top-level AWT. La funzionalità di renderizzazione usata da Swing per disegnare i suoi componenti è fornita da Java2D, un'altra parte di AWT. La disposizione dei componenti viene affidata ai java.awt.LayoutManager. ecc.

Differenze con AWT: il meccanismo di funzionamento modifica

Fin dalle prime versioni di Java, una porzione del Abstract Window Toolkit (AWT) ha fornito API indipendenti dalla piattaforma per la realizzazione delle GUI. In AWT, di fatto l'applicazione si serve di oggetti Java per controllare i componenti nativi specifici per il sistema operativo in utilizzo e che compongono l'interfaccia grafica. Questo significa che il comportamento dei componenti (la reazione agli eventi, il rendering, ecc.) sono affidati alla loro implementazione system-dependent. Per questo motivo, i componenti AWT vengono detti heavyweight components ("componenti pesanti"): a ciò che l'applicazione "vede" come la creazione di un componente AWT, di fatto corrisponde l'allocazione di risorse ad opera del sistema operativo. Al contrario, i componenti Swing sono spesso descritti come lightweight ("leggeri"), perché non necessitano l'allocazione di risorse native nel toolkit della GUI del sistema operativo.

Elementi di AWT utilizzati in Swing modifica

Layout managers

Alla fine, in termini di composizione visuale e gestione, Swing possiede layout relativi (i quali specificano la posizione reciproca tra i componenti) che operano in maniera opposta rispetto al layout assoluto (nel quale è necessario specificare apposta la esatta posizione e le dimensioni di ogni componente). Questa direzione verso visualizzazioni "fluide" è una diretta politica dello sviluppo di Swing che riemerge dalle ceneri del framework AWT e l'associata assunzione sulle applet dell'ambiente operativo che ha tracciato il disegno e sviluppo dell'originale toolkit GUI di Java. Concettualmente, questa visualizzazione della gestione del layout è abbastanza simile a quella che gestisce la renderizzazione del contenuto HTML nei browser, ed indirizza lo stesso insieme di concetti che hanno motivato i suoi creatori.

Container top-level

Se è vero che i singoli componenti sono realizzati completamente in codice Java, i container top-level (finestre di dialogo e applet) sono parzialmente implementati in codice nativo.

Vantaggi rispetto ad AWT modifica

I principali vantaggi di Swing rispetto ad AWT sono conseguenza del fatto stesso che i componenti Swing sono realizzati in puro codice Java. Infatti, questo significa che i componenti funzionano allo stesso modo su tutte le piattaforme per le quali esiste una macchina virtuale. I bug rilevati durante l'esecuzione del sistema grafico (almeno per la parte che riguarda l'interfaccia grafica) sono gli stessi su tutte le piattaforme, il che permette di risolverli con un semplice aggiornamento delle librerie.

Look and feel

Poiché i componenti sono sviluppati in Java, il sistema Swing ha controllo sul rendering grafico dei componenti, e questo ha consentito lo sviluppo di un'API tramite la quale un'applicazione può personalizzare il look and feel della propria interfaccia grafica. In poche parole, il disegno e lo stile grafico dei componenti non vengono richiesti al toolkit grafico nativo del sistema operativo, ma vengono riprodotti tramite una loro emulazione. Questo significa che si può ottenere un nuovo L&F semplicemente implementando le classi Java necessarie (oppure configurando il look and feel Synth, introdotto a partire dal J2SE 5.0).

Libertà nel rendering

Il principale vantaggio della libreria Swing è che essa permette al programmatore di astrarsi dai vincoli imposti dall'architettura del sistema grafico adottato dal sistema operativo in uso. Il sistema grafico AWT risente di queste limitazioni, in quanto l'insieme dei componenti e le caratteristiche che questi ultimi offrono all'applicazione sono ristretti ad uno standard comune, un minimo insieme che possa essere supportato da tutti i sistemi operativi sui quali AWT deve funzionare.

I componenti Swing gestiscono in modo autonomo la propria grafica e il proprio comportamento; è pur vero che il rendering finale deve essere affidato al sistema operativo, in quanto è quest'ultimo che ha in mano la gestione delle periferiche video e delle periferiche che segnalano l'input utente (tastiera, mouse, rotellina del mouse, ecc.), ma è anche vero che Swing "traduce" la sua semantica su quella sottostante dei componenti del SO con un legame molto più debole rispetto a quanto l'architettura stessa dell'AWT consentiva di ottenere.
Così, per esempio, di fatto ogni componente di Swing si disegna sul dispositivo grafico del sistema operativo servendosi di un wrapper opportunamente implementato in Java (realizzato tramite un oggetto java.awt.Graphics). Ma, differentemente dai componenti AWT, i quali delegano il disegno ai widget nativi del SO, i componenti di Swing sono responsabili della loro stessa renderizzazione.

Svantaggi rispetto ad AWT modifica

Il principale svantaggio rispetto ad AWT è quello di una più lenta esecuzione.

Legami con SWT modifica

Lo Standard Widget Toolkit (SWT) è un toolkit concorrente originalmente sviluppato dalla IBM ed ora mantenuto dalla Eclipse Foundation. Le implementazioni SWT sono più in comune con i componenti AWT heavyweight. Questo conferisce benefici come una più accurata fedeltà con il sottostante toolkit window nativo, al costo di una maggior esposizione ad una programmazione più nativa nel modello di programmazione.

L'avvento di SWT ha dato origine ad una grande divisione tra gli sviluppatori del Java desktop con molti fortemente favorevoli a SWT e altri a Swing. Lo sviluppo di Sun su Swing continua a concentrarsi sulla fedeltà del look and feel (PLAF, Pluggable look and feel) in ogni toolkit window. Nel frattempo non vi sono altre risorse di PLAFs fedeli, molti dei quali sono nel sito javootoo Archiviato il 15 luglio 2005 in Internet Archive..

C'è stato un dibattito significativo sulle prestazioni di SWT rispetto a quelle di Swing; La dipendenza di SWT da JNI lo rende lento quando i componenti GUI e Java necessitano di scambiarsi i dati, ma più veloce a disegnarsi quando il modello dei dati è stato caricato nella GUI.

SWT serve alla piattaforma delle finestre molto bene ma alcuni la considerano meno efficace come tecnologia per lo sviluppo multipiattaforma. Usando le funzionalità di alto livello dei window toolkit nativi, SWT riporta alla situazione vista negli anni '90 (con toolkit come zApp, Zinc, XVT e IBM/Smalltalk) dove i toolkit cercavano di mascherare le differenze nel comportamento e gestione del focus, della gestione degli eventi e dei layout grafici. Il fallimento di avere eguali comportamenti su ogni piattaforma può causare errori di programmazione subdoli e difficili da risolvere, con effetti negativi sull'interazione dell'utente e sull'aspetto grafico della GUI.

Esempio modifica

Il seguente è un programma Hello World di esempio che usa Swing. 

import javax.swing.*;

public final class HelloWorld {

    public static void main(String[] args) {

        /* Questo fa sì che tutto il codice che crea e mostra a schermo la GUI venga eseguito sul thread 
           che gestisce la coda degli eventi di Swing (e di AWT). */
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                mainOnEventDispatchThread();
        }   });
        
    }

    // Questo metodo viene sempre invocato sul thread che gestisce la coda degli eventi ↓

    private static void mainOnEventDispatchThread() {
            // Create frame with title "Hello, World!"
            JFrame f = new JFrame("Hello, World!");
            // Dimensione della finestra
            f.setSize(200, 100);

            // Fa sì che il frame richieda alla JVM di terminare il programma
            // quando la finestra viene chiusa.
            f.setDefaultCloseOperation (JFrame.EXIT_ON_CLOSE);

            f.add(new JLabel("Hello, World!"));

            f.setVisible(true);
    }
}

Note modifica

  1. ^ Comunque, per capire bene il potenziale che l'architettura Swing rende possibile, considerate l'ipotetica situazione in cui i modelli modificati delle tabelle e le liste sono creati al di sopra di servizi DAO e/o EJB

Bibliografia modifica

Voci correlate modifica

Altri progetti modifica

Collegamenti esterni modifica

Link dai siti ufficiali:

Altri link:

Estratto da "https://it.wikipedia.org/w/index.php?title=Swing_(Java)&oldid=132803964"