[JAVA] Aiuto per GUI & Threads

[Emaborsa]

Come progettino universitario dobbiamo scrivere una mini chat che comprende server+cleint. In 3 classi ho scritto tutto, abbastanza semplice. Funziona perfettamente sotto Terminal. Ieri volevo iniziare a creare la veste grafica. La mia idea era di Creare una GUI iniziale con la presentazione del progetto e con 2 bottoni, per poter O avviare il server O avviare un cleint. Ho usato Swing ma ammetto che non sono molto pratico a fare GUI. Comunque sia, GUI iniziale fatta, semplice ma per il progetto basta (Appena riesco vi fosto lo screen). I bottoni ovviamente hanno un actionlistener. Ora cliccando per esempio sul bottono Server, vorrei fare aprire un'altra Finestra e chiudere quella precedente. Come faccio? Riesco a farne aprire una nuova, ma l'altra come faccio a chiuderla? Posso mettere un setvisible(false)? ...non mi sembra la soluzione migliore.

Arriviamo ad un altro problema. Ho crato anche la GUI per il server. poca roba, giusto 2 bottoni per avviarlo e fermarlo e qualche textarea. Nel bottone start ovviamente c'è il comando per creare un oggetto del mio server ed avviarlo. Nell'avvio c'è un loop infinito per riconoscere i vari client in entrata e servirli. Per via di questo loop mi si blocca la gui, perchè il comando che avvia il loop non termina. Come faccio? Uso i Thread? Se SI, come?

[banryu79]

Originariamente inviato da Emaborsa

I bottoni ovviamente hanno un actionlistener. Ora cliccando per esempio sul bottono Server, vorrei fare aprire un'altra Finestra e chiudere quella precedente. Come faccio? Riesco a farne aprire una nuova, ma l'altra come faccio a chiuderla? Posso mettere un setvisible(false)? ...non mi sembra la soluzione migliore.

Supponiamo che
1) hai ilriferimento al JFrame da chiudere ('frame' nell'esempio);
2) il JFrame da chiudere ha la sua defaultCloseOperation settata a DISPOSE_ON_CLOSE;
Puoi fare così:

...
// nell'actionPerformed del listener associato al JButton "Server"
WindowEvent closing = new WindowEvent(frame, WindowEvent.WINDOW_CLOSING);
frame.dispatchEvent(closing);
...

Originariamente inviato da Emaborsa

Arriviamo ad un altro problema. Ho crato anche la GUI per il server. poca roba, giusto 2 bottoni per avviarlo e fermarlo e qualche textarea. Nel bottone start ovviamente c'è il comando per creare un oggetto del mio server ed avviarlo. Nell'avvio c'è un loop infinito per riconoscere i vari client in entrata e servirli. Per via di questo loop mi si blocca la gui, perchè il comando che avvia il loop non termina. Come faccio? Uso i Thread? Se SI, come?

La GUI si blocca perchè il codice del tuo loop viene eseguito dall'EDT.
La soluzione è creare e lanciare un nuovo Thread a cui far eseguire il tuo loop.
Trovi degli spunti in questa discussione.
Visto che lavori con Swing può esserti utile il tutorial che ho in firma.

[Emaborsa]

Grazie della risposta, ma mi sa che devo fare ancor amolta pratica. Il fatto che devo usare i Threads lo immaginavo, altrimenti è normale che mi se blocca.
Il punto è che ci ho pure provato, ma non sono risucito a mettere assieme il tutto che funzioni a dovere. Come detto sopra, non sono pratico a fare GUI...perciò nemmeno di Swing. Visto che lo hai accennato, che alternative (migliori) avrei a swing?

[banryu79]

Originariamente inviato da Emaborsa

Il punto è che ci ho pure provato, ma non sono risucito a mettere assieme il tutto che funzioni a dovere. Come detto sopra, non sono pratico a fare GUI...perciò nemmeno di Swing. Visto che lo hai accennato, che alternative (migliori) avrei a swing?

Non lo so: conosco bene solo Swing. SWT lo conosco pochissimo, ma da quel poco che so anche la sua architettura è a single-thread (quindi dovresti comunque affrontare gli stessi "problemi" che stai affrontando ora in Swing).
Se per "alternative migliori" intendi una libreria/framework la cui architettura supporti il multithreading in modo trasparente all'utente-programmatore, non ne conosco.
L'architettura basata sul modello "single-thread" per i GUI framework fin'ora si è imposta come la preferenziale per un tot di ragioni.

In ogni caso, la morale della favola è che scrivendo applicazioni basate su interfaccia grafica prima o poi sbatti contro queste questioni, e in un modo o nell'altro le devi studiare e imparare per poterle controllare e gestire. Non c'è scampo (l'opzione è rinunciare alla GUI).

Se vuoi un consiglio, fossi in te inizierei proprio dal tutorial che ho in firma: in 3 orette lo leggi tutto con una certa calma, in modo da riuscire a "digerire" mentalmente tutti i concetti, fossero anche tutti nuovi per te.
In particolare, la faccenda dell'EDT e dei thread, è trattata proprio nelle prime pagine (e giustamente direi: non ha senso studiare Swing senza questa premessa fondamentale).

Poi puoi leggerti questo per approfondire il threading model in Swing.

[Emaborsa]

Appena riesco. magari il fine settimana mi studierò per bene lo swing.
Tornando al mio "progetto", se faccio some mi hai scritto in pratica premo il bottone, viene chiuso il frame in questione e nel tasto devo avviarene un altro (un'altra classe che è o extends JFrame o implements Runnable)? ...ho capito bene?
Altra cosa: Che ne pensi degli editor come VISUAL EDITOR e affini?

[banryu79]

Originariamente inviato da Emaborsa

...
Tornando al mio "progetto", se faccio some mi hai scritto in pratica premo il bottone, viene chiuso il frame in questione e nel tasto devo avviarene un altro (un'altra classe che è o extends JFrame o implements Runnable)? ...ho capito bene?

Tieni presente che il metodo actionPerformed è eseguito dall'EDT.
Chiudi il frame che devi chiudere e apri il nuovo frame, se devi aprirne uno nuovo.
La faccenda del Runnable da lanciare in un altro Thread è necessaria qualora quel Runnable incapsuli computazioni da lanciare alla pressione del bottone e che non si vogliono/devono far eseguire all'EDT.

Dunque la situazione è questa:
1 - chiudere una finestra
2 - aprire un'altra finestra
3 - eseguire delle computazioni che non devono impegnare l'EDT

Il thread che processa questa "lista della spesa" è l'EDT
Resta da chiarire se il punto 3) deve essere eseguito in sincrono con il termine dell'esecuzione del punto 2) oppure se questi due punti sono asincroni tra loro.

Se lo scenario è il primo [eseguo 2) completamente e dopo eseguo 3)] si può lanciare un frame (punto 2)) il quale implementa un WindowListener che ascolta se stesso e risponde all'evento "Window Opened" eseguendo le operazioni previste al punto 3) che saranno incapsulate in un Runnable ed eseguite in un nuovo thread (perchè è sempre l'EDT che esegue i metodi dei listener).

Se lo scenario, invece, è il secondo [eseguo 2) e 3)] si può lanciare un frame (punto 2) e creare e avviare un nuovo Thread che esegue le operazioni previste al punto 3) che saranno incapsulate in un Runnable per il motivo che sappiamo.

Originariamente inviato da Emaborsa

...
Altra cosa: Che ne pensi degli editor come VISUAL EDITOR e affini?

Mai usato, dato che lavoro esclusivamente con NetBeans, dove c'è Matisse.
Penso che siano utili per prototipare rapidamente le GUI, ma non sollevino il programmatore da una solida conoscenza delle API (Swing, SWT o quant'altro): se questa manca è normale incappare in difficoltà e relative perdite di tempo, e queste ultime vanificano l'utilità dell'editor visuale che scrive il codice al posto nostro.

[WarDuck]

Usa NetBeans... non capisco perché bisogna complicarsi la vita.

@banryu: se il disegnatore di interfacce è fatto come cristo comanda, e soprattutto se non è necessario un controllo granulare dell'intera interfaccia, non vedo perché complicarsi la vita.

Scrivere a mano tutto quanto è pura follia.

[banryu79]

Originariamente inviato da WarDuck

@banryu: se il disegnatore di interfacce è fatto come cristo comanda, e soprattutto se non è necessario un controllo granulare dell'intera interfaccia, non vedo perché complicarsi la vita.

Ho solo espresso la mia opinione, frutto della mia singola limitata (lo sottolineo: singola e limitata) esperienza.
A scanso di equivoci non volevo dire (e se rileggi bene non lo dico ne lo sottointendo) che gli editor visuali per GUI sono delle ciofeche e non bisognerebbe usarli: dico solo che non dispensano il programmatore che li utilizza dalla conoscenza della API del framework per GUI che si sta utilizzando.
Osservazione piuttosto banale, d'accordo, ma è quello che io penso vada sempre tenuto ben presente.

[WarDuck]

Originariamente inviato da banryu79

Ho solo espresso la mia opinione
[..]

Anche io tranquillo , in effetti ho letto un po' troppo velocemente, quello che dici è pienamente condivisibile.

Comunque in ogni caso consiglio all'autore del thread di provare l'ottimo NetBeans, se già non lo usa.

Per il resto per non far bloccare la GUI dovrebbe essere sufficiente creare un thread separato (o sfruttare gli Executor che però ho usato pochissimo e non ricordo molto).

[banryu79]

Originariamente inviato da WarDuck

Anche io tranquillo , in effetti ho letto un po' troppo velocemente, quello che dici è pienamente condivisibile.

Comunque in ogni caso consiglio all'autore del thread di provare l'ottimo NetBeans, se già non lo usa.

Sì, anche io, se lavora con Swing.
C'è da tenere presente però, che se non ha mai visto NetBeans prima e al contrario è già produttivo con Eclipse il passaggio dall'uno all'altro implica il dover affrontare e superare (e quindi tempo) le classiche ed eventuali difficoltà dovute al doversi abituare a un nuovo ambiente di sviluppo.

Originariamente inviato da WarDuck

Per il resto per non far bloccare la GUI dovrebbe essere sufficiente creare un thread separato (o sfruttare gli Executor che però ho usato pochissimo e non ricordo molto)

Per lo stesso senso (tempo) sotteso nel mio commento al primo quote, qui sopra, ho preferito non suggerire ad Emaborsa l'uso di Executor (o ancora meglio SwingWorker); suppongo siano API non ancora patrimonio delle sue conoscenze.

Credo che per fare quello che deve, sia sufficiente sapere dell'architettura a thread singolo di Swing e dell'EDT, (di quando entra in gioco, del fatto di non fargli eseguire computazioni onerose e del fatto che bisogna fargli eseguire tutte le operazioni che mutano i componenti grafici) e conoscere l'uso della classe Thread, dell'interfaccia Runnable e dei metodi SwingUtilities.invokeLater e SwingUtilities.invokeAndWait.

Queste sono (assieme al memory model del linguaggio), secondo me, le conoscenze basilari indispensabili per gestire senza paura questioni non troppo complesse di multithreading in Swing.

[Emaborsa]

Grazie ad entrambi.
Allora, diciamo che sono abbastanza nuovo nella programmazione, sono al secondo anno di università, e prima di allora non avevo mai programmato.
Stiamo facendo progettini, piano piano si scoprono cose nuove...
La prima volta che ho dovuto fare una GUI non sapevo da che parte iniziare allora ho rubato pezzi di codice per mettere insieme qualcosa e da li ho capico qualcosina....che però è troppo poco. Altri hanno usato Visual Editor per Eclipse, che però sull'ultimo Eclipse non va (non hanno ancora fatto la versione nuova). Poi ho trovato quello di Google che secondo me è già meglio.
Ho provato ad usare anche Netbeans, ma il punto è che ne so troppo poco di swing, e perciò ho deciso di seguire un tutorial che mi mostri il tutto. Vorrei arrivare a farmi una GUI a mano senza editor, ovviamente parlo di GUI semplici. Se devo fare una gui complessa di sicuro andrei di editor.

[banryu79]

Originariamente inviato da Emaborsa

[...]
ma il punto è che ne so troppo poco di swing, e perciò ho deciso di seguire un tutorial che mi mostri il tutto. Vorrei arrivare a farmi una GUI a mano senza editor, ovviamente parlo di GUI semplici. Se devo fare una gui complessa di sicuro andrei di editor.

Bingo!
Segui il tutorial che ho in firma, è eccellente per chi parte da zero

Una volta assorbito, continua con il tuo progetto e ogni volta che incontri un problema circa la GUI (devi usare un componente che non hai mai usato prima, devi rispondere a eventi generati dai componenti della GUI che ancora non conosci, ecc...) vai a questa "lesson":
- Lesson: Using Swing Components
e consulta la sezione "HowTo" relativa allo specifico componente che ti interessa.

Quella lesson fa parte della più ampia "trail" su Swing:
- Trail: Creating a GUI With JFC/Swing (nota che c'è un tutorial proprio sul threading in Swing)

Che a sua volta è una macro-sezione dell'immenso "The Really Big Index":
- The Really Big Index (The Java Tutorials)

Tienti queste risorse sempre sottomano e impara a consultarle con destrezza: assieme ai javadoc delle classi del JDK forniscono un'ottima documentazione.