[JAVA-SWING] Come si implementa un secondo thread per un componente?

[dierre]

Praticamente io c'ho st'applicazione desktop realizzata con MVC.
Questa applicazione ad un certo punto carica dei file ed allora per ogni file caricato volevo aggiornare un contatore su schermo (un semplice label).

Il codice dummy del model (che funziona però con lo stesso principio) è il seguente:

	public void dummyMethod(Integer k) throws InterruptedException{
		for(int i=0;i<10;i++){
			System.out.println(i);
            Thread.sleep(1000);
			this.firePropertyChange(DefaultController.BACKUP_DUMMY, i-1, i);
		}
	}

e sulla view ho

	@Override
	public void modelPropertyChange(PropertyChangeEvent evt) {
		// .......
		
		
		else if( evt.getPropertyName().equals( DefaultController.BACKUP_DUMMY ) ){
			System.out.println("WHAT?");
			this.dummy.setText(evt.getNewValue().toString());
		}
		
	}

Succede che la stampa a console viene esplicitata ma non viene aggiornato il componente grafico ovviamente perché tutto gira sotto l'EDT. Cosa dovrei fare per invece far aggiornare la gui correttamente? Dovrei estendere il panel con Runnable e farlo partire come thread a parte rispetto a quello principale?

SwingWorker non mi serve sinceramente perché non è che devo fare calcoli o roba complessa, devo solo aggiornare un cavolo di button.

[PGI-Bis]

La soluzione è SwingWorker. E qui c'è il perchè.

Dal punto di vista del pulsante, il fatto che tutto giri nell'EDT è cosa buona e giusta: l'aggiornamento del pulsante deve essere fatto nell'edt.

Il problema è "meccanico", ed è nel ciclo. Uno potrebbe aspettarsi che dicendo:

da 1 a 10 -> fai qualcosa

capiti:

1 -> fai qualcosa, 2 -> fai qualcosa, 3 -> fai qualcosa ... 10 -> fai qualcosa.

Ovviamente non è così: dipende da "qualcosa". In particolare bisogna vedere se il risultato di qualocosa è sincrono o asincrono. Magari è una sorpresa ma si può essere asincroni anche con un solo thread.

Quello che capita quando io imposto il testo di un'etichetta, ad esempio, NON è:

etichetta.setText("pippo") -> il valore di text per etichetta diventa pippo, il componente viene aggiornato sullo schermo

ma è:

etichetta.setText("pippo") => il valore diventa pippo, l'etichetta genera un evento repaint e lo preme nella coda degli eventi awt. Quando l'edt arriva a consumare quell'evento, l'aspetto dell'etichetta cambia mostrando il testo pippo.

Quindi il nostro ciclo:

da 1 a 10 fai qualcosa

dove qualcosa è un conto, che può essere o non essere oneroso, a cui segue l'aggiornamento di una proprietà che determina l'aspetto di un componente (e che quindi causa l'accodamento di una richiesta repaint), produce, in termini di unità di esecuzione dell'edt, questo:

(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
(aggiorna componente)
(aggiorna componente)
(aggiorna componente)
(aggiorna componente)
(aggiorna componente)
(aggiorna componente)
(aggiorna componente)
(aggiorna componente)
(aggiorna componente)

Cioè ad ogni passaggio nel ciclo si genera una richiesta di aggiornamento di un componente che viene accodata. Siccome l'edt è impegnato a ciclare, non può consumare la richiesta di aggiornamento finchè non abbia finito il ciclo. Quando il ciclo finisce, fa tutti e 10 gli aggiornamenti in un botto.

A video infatti dovresti vedere non l'aggiornamento progressivo dell'etichetta ma un solo aggiornamento (perchè i repaint vengono compattati).

Dunque non è un problema di onerosità dei conti: quella causa al massimo delle sgradevoli interruzioni nella capacità dell'interfaccia grafica di rispondere all'interazione utente. E' proprio una questione materiale: nun se po' fa'.

Quello che ti serve è "trasformare" il prodotto del ciclo:

conta conta conta, aggiorna aggiorna aggiorna

in

conta, aggiorna, conta, aggiorna, conta, aggiorna.

Come si fa? Evidentemente dobbiamo trasformare il ciclo in un accodamento ricorsivo di eventi.

Così da:

for(int i = 0; i < 10; i++) {
    model.setText("Hello " + i);
}

Passiamo a:

Runnable loop = new Runnable() {
	
	int i = 0;

	public void run() {
		if(i == 10) return;
		model.setText("Hello " + i);
		i += 1;
		EventQueue.invokeLater(this);
		try {
			Thread.sleep(1000);
		} catch(InterruptedException ex) { return; }
	}
};
EventQueue.invokeLater(loop);

E' chiaro che scrivere una cosa del genere ti vale una denuncia all'interpol, se non altro perchè è molto più chiaro se usi SwingWorker:

new SwingWorker<Void, Number>() {

	public Void doInBackground() throws Exception {
		for(int i = 0; i < 10; i++) {
			publish(i);
			Thread.sleep(1000);
		}
		return null;
	}
	
	public void process(java.util.List<Number> data) {
		for(Number e: data) model.setText("Hello " + e);
	}
}.execute();

Non è più chiaro esteticamente ma per via della funzione di SwingWorker: uno legge il codice, vede SwingWorker, vede publish e capisce che c'è una serie di compiti eseguiti dall'edt.

[dierre]

Grazie per la risposta. Ieri notte poi ho trovato una soluzione temporanea:

	private void caricaFiles( java.awt.event.ActionEvent evt){
		Thread workerThread = new Thread() {
			public void run(){
				File temp = new File(VolumePanel.this.cartella);
				VolumePanel.this.vuota.setText("");
				if(temp.isDirectory() && temp.canWrite()) VolumePanel.this.controller.copyFiles(temp);
				else VolumePanel.this.vuota.setText("Controlla di avere i permessi di scrittura sulla directory scelta");
			}
		};
		workerThread.start();
	}

Però adesso mi studio meglio il tuo post e vedo di usare lo SwingWorker.

[dierre]

Ciao! Allora mi sono anche letto questo: http://en.wikipedia.org/wiki/SwingWorker

Penso che alla fine vada bene anche la mia soluzione, non credi? Voglio dire lo SwingWorker ha più funzionalità ma dal momento che io sto usando il pattern MVC le varie get, publish etc...sono l'equivalente delle notifiche tra model e view che io già uso, di conseguenza facendo partire la chiamata al controller per far caricare i file ha essenzialmente lo stesso effetto giusto? Affida al nuovo 3d il caricamento dei file e lascia l'EDT libero.

[PGI-Bis]

Sono certo che non vada bene.

Quando usi un secondo thread per evitare di sovraccaricare l'edt fai uscire un problema dalla porta e te ne entra un altro dalla finestra.

Quello che entra dalla finestra riguarda l'accesso a risorse condivise da più thread.

I metodi doInBackground e process di uno SwingWorker non sono semplicemente eseguiti da thread diversi ma sono anche coordinati in modo che ciò che il thread in background genera e pubblica sia leggibile dall'edt nel process.

Lo fa seguendo le regole del linguaggio java che stabiliscono quando si possa dire che ciò che un thread legge corrisponda a ciò che un altro thread ha scritto.

Puoi certamente usare un thread nudo e crudo al posto di SwingWorker ma sei comunque obbligato a garantire l'integrità del tuo programma nel passaggio single-thread multi-thread. L'MVC da questo punto di vista è indifferente.

[dierre]

Che intendi per "risorse condivise"?

Il controller richiama il metodo per fare la copia che usa sì una lista condivisa ma la usa in lettura e nient'altro in quel momento la usa. Ovviamente mi son ben guardato dal far danni ai dati dell'applicazione.

[PGI-Bis]

In generale, tutti i riferimenti e i riferimenti accessibili tramite loro.

I controlli che devi fare dipendono dal codice che hai scritto. Ad esempio, per via di una delle regole, sai che il valore del campo "cartella" letto dal thread che lanci è sincronizzato con l'ultimo assegnamento che l'edt ha compiuto su quel valore.

Assumendo che sia una stringa o un file, sei a posto, perchè è immutabile (cioè tutti i campi accessibili tramite "cartella" sono thread-safe per via di un'altra regola).

controller può essere o non essere thread-safe, dipende da com'è fatto. Vale anche qui la regola di prima per cui il suo valore (diretto e indiretto) è quello dell'ultima scrittura eseguita nell'edt. Se eventuali scritture successive non pregiudicano l'integrità del programma potrebbe essere ok. Se oltre a leggere fa qualcos'altro (ad esempio notificare un evento) non va bene.

Per "vuota", setText è uno dei pochi metodi di swing che può essere invocato da un thread diverso dall'edt SE il documento associato al componente si affida ad AbstractDocument (se non hai cambiato il documento associato allora è ok).

Come vedi ci sono un sacco di se. Per controllarli bisogna conoscere il modello di memoria di Java. Se li verifichi tutti, il programma è ok.

Ovviamente non è così che si procede perchè la quantità di precondizioni a cui soggiace il programma non è indifferente e dipende da norme che sono generalmente considerate complicate.

[dierre]

Sì sì. Son praticamente solo file. Cmq ora mi adopero per passare allo SwingWorker anche se credo che a questo punto forse devo cambiare il metodo che copia i file se voglio aggiornare la GUI per ogni file copiato.

Perché al momento succede questo:

	public void copyFiles( File target ){
		
		int length = this.directories.size();
		int index = 0;
		
		for(Directory d:this.directories){
			for(File f:d.getFiles()){
				try {
					this.osm.copyFile(d.getPath(), f, target);
					this.firePropertyChange(DefaultController.BACKUP_UPDATE_GUI, length, index++);
				} catch (IOException e) {
					this.firePropertyChange(DefaultController.BACKUP_MESSAGE, null, "ERRORE NEL CARICAMENTO FILES!");
					//e.printStackTrace();
				}	
			}
		}

		try {
			this.updateDate();
		} catch (SQLException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		} catch (ClassNotFoundException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		this.firePropertyChange(DefaultController.BACKUP_MESSAGE, null, "FILE CARICATI!" );
	}

[PGI-Bis]

Lì vale lo stesso discorso di prima. Ad esempio se il firePropertyChange è realizzato tramite uno SwingPropertyChangeSupport, inizializzato col booleano a true, allora è sia thread-safe che "swing-safe" (cioè le notifiche sono automaticamente gestite dall'edt). Altrimenti devi averlo reso thread&swing safe a mano.

Idem per updateDate(). Se l'updateDate coinvolge l'aggiornamento di componenti generalmente deve essere delegato all'edt.

Insomma, c'è una ragione per 'sto SwingWorker che non è solo il fatto di lanciare un altro thread.

[dierre]

Il tizio della Oracle ha usato un propertyChangeSupport. No this.update() aggiorna la data nel db all'ora corrente.

Comunque messaggio ricevuto. Tnx!