[java] ....attendere prego....

[c-darma]

ho un applet ; cliccando un pulsunte parte una procedura su database. E' possibile far comparire una finestra del tipo "esecuzione in corso, attendere prego" mentre la procedura si fa il lavoro su database?

[PGI-Bis]

Premetto che per queste cose c'è SwingWorker ma è una classe talmente barocca che mi rifiuto di usarla. Per questioni di concorrenza e di reattività dell'interfaccia, quello che vuoi fare deve essere diviso in tre parti.

1. premo il pulsante e si apre la finestra "Lavori in corso..."
2. nel mentre, un Thread a parte esegue la query
3. quando il Thread ha terminato il suo lavoro, chiude la finestra

Apertura e chiusura della finestra devono essere affidate all'AWT Event Dispatcher Thread. L'esecuzione della query potrebbe essere delegata ad un Thread a parte e deve esserlo nel caso in cui la finestra di dialogo sia bloccante.

Un modo sintetico per fare tutto questo è creare una classe astratta che possiede tre metodi, uno per ognuna delle fasi su citate, automaticamente affidate al Thread corretto. Ad esempio:

public abstract class SimpleWorker {
/** Eseguito dall'AWT Event Dispatcher */
public abstract void startNotify();

/** Eseguito dall'AWT Event Dispatcher */
public abstract void endNotify();

/** Eseguito da un Thread diverso dall'AWT Event Dispatcher */
public abstract void doInBackground();

public void execute() {
new Thread(runner, "Simple Worker Thread").start();
}

private final Runnable startRunner = new Runnable() {
public void run() {
startNotify();
}
};

private final Runnable endRunner = new Runnable() {
public void run() {
endNotify();
}
};

private final Runnable runner = new Runnable() {
public void run() {
java.awt.EventQueue.invokeLater(startRunner);
try {
doInBackground();
} finally {
java.awt.EventQueue.invokeLater(endRunner);
}
}
};
}

A questo punto estendi quella classe e ne crei una che:

1. nel metodo startNotify apre la finestra di attesa
2. nel metodo doInBackground esegue la query
3. nel metodo endNotify chiude la finestra di attesa.

Ad esempio:

public class QueryExecutor extends SimpleWorker {
private final JDialog dialog;

public QueryExecutor(Frame parent) {
dialog = new JDialog(parent, true);
dialog.setDefaultCloseOperation(JDialog.DO_NOTHING_ON_CLOSE);
dialog.setSize(300, 200);
dialog.add(new JLabel("Lavori in corso...", JLabel.CENTER));
dialog.setResizable(false);
dialog.setLocationRelativeTo(parent);
}

public void startNotify() {
dialog.setVisible(true);
}

public void doInBackground() {
//simula l'esecuzione della query...
try {
Thread.sleep(1000);
} catch(InterruptedException ex) {
ex.printStackTrace();
}
}

public void endNotify() {
dialog.dispose();
}
}

Per provare il tutto puoi usare una classe Main tipo:

public class Main {
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
new Main().showMainWindow();
}
});
}

private JFrame mainWindow = new JFrame("Finestra principale");

public Main() {
JButton button = new JButton("Esegui query...");
JPanel panel = new JPanel(new FlowLayout());
panel.add(button);
button.addActionListener(buttonListener);
mainWindow.add(panel, BorderLayout.SOUTH);
mainWindow.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
}

public void showMainWindow() {
mainWindow.pack();
mainWindow.setVisible(true);
}

private ActionListener buttonListener = new ActionListener() {
public void actionPerformed(ActionEvent e) {
new QueryExecutor(mainWindow).execute();
}
};
}

Nota che l'ordine di invocazione dei metodi startNotify, endNotify e doInBackground è relativamente garantito: doInBackground può partire prima di startNotify ma startNotify è sempre eseguito prima di endNotify.

[^TiGeRShArK^]

Premetto che per queste cose c'è SwingWorker ma è una classe talmente barocca che mi rifiuto di usarla.
perchè barocca? :D
io l'ho trovata interessante..
certo per fare cose semplici come quella richiesta in questo thread è assolutamente esagerata..
Ma per fare cose piuttosto complesse la trovo una buona soluzione.
Avevo dato un'occhiata al codice del applicazione che tramite web services faceva delle ricerche su flicker generando delle thumbnails e permettendo di vedere ogni immagine ingrandita e non mi è parsa affatto male come soluzione :p

[PGI-Bis]

Perchè ha 18 metodi, una classe annidata, concretizza tre interfacce è generica con due parametri e può notificare eventi PropertyChange che, tra tutti, sono quelli meno significativi dell'intero pacchetto di librerie standard. Astratta, ovviamente.

Sinceramente non so cos'altro avrebbero potuto metterci dentro. Forse un paio di metodi nativi, così, ad abundantiam.

E' semplicemente indecorosa.

[PS] Ah, dimenticavo: è pure una one-shot "semantica". Non puoi invocare due volte il metodo execute ma non c'è nulla che lo impedisca.

[lovaz]

In poche parole:

dialog.setVisible(true);
new Thread() {
public void run()
{
chiamaIlMioAmicoDataBase();
SwingUtilities.invokeLater( new Runnable() {
public void run() { dialog.dispose(); }
} );
}
}.start();


Scusate la sintesi :D

Ho letto anche io l'articolo su SW, e quello che ne ho ricavato
è che hanno ideato una classe che è più complessa del problema che
dovrebbe risolvere, l'unica novità rispetto alla vecchia SW è la
gestione del "progresso", ma non è difficile fare anche quella "a mano".

Per fare un raffronto, non è come rifare da zero una lista, visto che
le liste della libreria java sono di utilizzo immediato, e probabilmente
implementate meglio di come un programmatore qualunque possa fare.

SwingWorker invece è una forzatura inutile - sempre imho, eh...