Swing (Java)
Swing è un framework GUI indipendente dalla piattaforma, “model-view-controller” per Java, che segue un modello di programmazione a thread singolo. Inoltre, questo framework fornisce un livello di astrazione tra la struttura del codice e la presentazione grafica di una GUI basata su Swing.
FoundationsEdit
Swing è indipendente dalla piattaforma perché è completamente scritto in Java. La documentazione completa per tutte le classi Swing può essere trovata nella Java API Guide per la versione 6 o nella Java Platform Standard Edition 8 API Specification per la versione 8.
ExtensibleEdit
Swing è un’architettura altamente modulare, che permette il “plugging” di varie implementazioni personalizzate di interfacce specifiche del framework: Gli utenti possono fornire le loro implementazioni personalizzate di questi componenti per sovrascrivere le implementazioni di default utilizzando il meccanismo di ereditarietà di Java tramite javax.swing.LookAndFeel.
Swing è un framework basato su componenti, i cui componenti sono tutti derivati dalla classe javax.swing.JComponent. Gli oggetti Swing sparano eventi in modo asincrono, hanno proprietà vincolate, e rispondono ad un insieme documentato di metodi specifici per il componente. I componenti Swing sono componenti JavaBeans, conformi alle specifiche JavaBeans.
ConfigurableEdit
La forte dipendenza di Swing dai meccanismi di runtime e dai modelli di composizione indiretta gli permette di rispondere a run time a cambiamenti fondamentali nelle sue impostazioni. Per esempio, un’applicazione basata su Swing è capace di cambiare a caldo la sua interfaccia utente durante il runtime. Inoltre, gli utenti possono fornire la propria implementazione di look and feel, che permette cambiamenti uniformi nel look and feel delle applicazioni Swing esistenti senza alcun cambiamento programmatico al codice dell’applicazione.
Lightweight UI
L’alto livello di flessibilità di Swing si riflette nella sua capacità intrinseca di sovrascrivere i controlli GUI del sistema operativo host nativo (OS) per visualizzare se stesso. Swing “dipinge” i suoi controlli usando le API Java 2D, piuttosto che chiamare un toolkit di interfaccia utente nativo. Così, un componente Swing non ha un corrispondente componente GUI nativo del sistema operativo, ed è libero di rendersi in qualsiasi modo possibile con le sottostanti GUI grafiche.
Tuttavia, nel suo nucleo, ogni componente Swing si basa su un contenitore AWT, poiché (Swing) JComponent estende (AWT) Container. Questo permette a Swing di collegarsi alla struttura di gestione della GUI del sistema operativo ospitante, includendo le mappature cruciali del dispositivo/schermo e le interazioni dell’utente, come la pressione dei tasti o i movimenti del mouse. Swing semplicemente “traspone” la propria semantica (OS-agnostica) sui componenti sottostanti (OS-specifici). Così, per esempio, ogni componente Swing dipinge la sua rappresentazione sul dispositivo grafico in risposta ad una chiamata a component.paint(), che è definita in (AWT) Container. Ma a differenza dei componenti AWT, che delegavano la pittura al loro widget “pesante” nativo del sistema operativo, i componenti Swing sono responsabili del proprio rendering.
Questa trasposizione e disaccoppiamento non è meramente visiva, e si estende alla gestione e applicazione da parte di Swing della propria semantica indipendente dal sistema operativo per gli eventi sparati all’interno delle gerarchie di contenimento dei componenti. In generale, l’architettura Swing delega al contenitore AWT il compito di mappare i vari tipi di semantica GUI del sistema operativo su un modello semplice, ma generalizzato. Costruendo su quella piattaforma generalizzata, stabilisce la propria ricca e complessa semantica GUI nella forma del modello JComponent.
Loosely coupled e MVCEdit
La libreria Swing fa un uso pesante del pattern di progettazione software model-view-controller, che disaccoppia concettualmente i dati visualizzati dai controlli dell’interfaccia utente attraverso cui vengono visualizzati. A causa di questo, la maggior parte dei componenti Swing hanno modelli associati (che sono specificati in termini di interfacce Java), e i programmatori possono usare varie implementazioni predefinite o fornire le proprie. Il framework fornisce implementazioni predefinite di interfacce di modelli per tutti i suoi componenti concreti. L’uso tipico del framework Swing non richiede la creazione di modelli personalizzati, poiché il framework fornisce un insieme di implementazioni predefinite che sono associate in modo trasparente, per default, alla corrispondente classe figlia JComponent nella libreria Swing. In generale, solo i componenti complessi, come le tabelle, gli alberi e talvolta le liste, possono richiedere implementazioni di modelli personalizzati intorno alle strutture dati specifiche dell’applicazione. Per avere un buon senso del potenziale che l’architettura Swing rende possibile, si consideri la situazione ipotetica in cui i modelli personalizzati per le tabelle e gli elenchi sono wrapper sopra i servizi DAO e/o EJB.
In genere, gli oggetti del modello del componente Swing sono responsabili di fornire un’interfaccia concisa che definisce gli eventi sparati e le proprietà accessibili per il modello di dati (concettuale) da utilizzare dal JComponent associato. Dato che il pattern MVC generale è un modello di relazione tra oggetti collaborativi liberamente accoppiati, il modello fornisce i mezzi programmatici per collegare gli ascoltatori di eventi all’oggetto del modello di dati. Tipicamente, questi eventi sono incentrati sul modello (es: un evento “riga inserita” in un modello di tabella) e sono mappati dalla specializzazione JComponent in un evento significativo per il componente GUI.
Per esempio, il JTable ha un modello chiamato TableModel che descrive un’interfaccia per come una tabella potrebbe accedere ai dati tabulari. Un’implementazione predefinita di questo opera su un array bidimensionale.
Il componente vista di un JComponent Swing è l’oggetto usato per rappresentare graficamente il controllo concettuale della GUI. Una distinzione di Swing, come framework GUI, è nella sua dipendenza dai controlli GUI resi programmaticamente (in opposizione all’uso dei controlli GUI del sistema operativo nativo). Prima di Java 6 Update 10, questa distinzione era una fonte di complicazioni quando si mescolavano i controlli AWT, che usano controlli nativi, con i controlli Swing in una GUI (vedi Miscelazione di componenti AWT e Swing).
Infine, in termini di composizione e gestione visiva, Swing favorisce i layout relativi (che specificano le relazioni di posizione tra i componenti) rispetto ai layout assoluti (che specificano l’esatta posizione e dimensione dei componenti). Questa inclinazione verso un ordinamento visivo “fluido” è dovuta alle sue origini nell’ambiente operativo dell’applet che ha incorniciato la progettazione e lo sviluppo del toolkit originale di Java GUI. (Concettualmente, questa visione della gestione del layout è abbastanza simile a quella che informa il rendering del contenuto HTML nei browser, e affronta lo stesso insieme di preoccupazioni che ha motivato la prima.)
Relazione con AWTEdit
Dalle prime versioni di Java, una parte dell’Abstract Window Toolkit (AWT) ha fornito API indipendenti dalla piattaforma per i componenti dell’interfaccia utente. In AWT, ogni componente è reso e controllato da un componente peer nativo specifico del sistema di windowing sottostante.
Al contrario, i componenti Swing sono spesso descritti come leggeri perché non richiedono l’allocazione di risorse native nel windowing toolkit del sistema operativo. I componenti AWT sono indicati come componenti pesanti.
Molte delle API Swing sono generalmente un’estensione complementare di AWT piuttosto che una sostituzione diretta. Infatti, ogni interfaccia leggera Swing alla fine esiste all’interno di un componente pesante AWT perché tutti i componenti di primo livello in Swing (JAppletJDialogJFrame, e JWindow) estendono un contenitore AWT di primo livello. Prima di Java 6 Update 10, l’uso di componenti leggeri e pesanti all’interno della stessa finestra era generalmente scoraggiato a causa di incompatibilità di ordine Z. Tuttavia, le versioni successive di Java hanno risolto questi problemi, ed entrambi i componenti Swing e AWT possono ora essere usati in una GUI senza problemi di ordine Z.
La funzionalità di rendering di base usata da Swing per disegnare i suoi componenti leggeri è fornita da Java 2D, un’altra parte di JFC.
Relazione con SWTEdit
Lo Standard Widget Toolkit (SWT) è un toolkit concorrente originariamente sviluppato da IBM e ora mantenuto dalla comunità Eclipse. L’implementazione di SWT ha più cose in comune con i componenti pesanti di AWT. Questo conferisce benefici come una più accurata fedeltà con il sottostante toolkit di windowing nativo, al costo di una maggiore esposizione alla piattaforma nativa nel modello di programmazione.
C’è stato un significativo dibattito e speculazione sulle prestazioni di SWT rispetto a Swing; alcuni hanno suggerito che la pesante dipendenza di SWT da JNI lo renderebbe più lento quando il componente GUI e Java hanno bisogno di comunicare dati, ma più veloce nel rendering quando il modello dei dati è stato caricato nella GUI, ma questo non è stato confermato in nessun modo. Una serie abbastanza approfondita di benchmark nel 2005 ha concluso che né Swing né SWT superano chiaramente l’altro nel caso generale.