Aiuto su multi thread e jdialog

[fermat]

ciao valia!

ma infatti non vorrei un esempio completo figurati!!

però continuo a nn capire.
se non è lo swing worker che istanzia il jdialog chi lo fa?
perchè se lo fa il jframe, l'applicazione giustamente non va avanti perchè il thread principale rimane bloccato.

[andbin]

se non è lo swing worker che istanzia il jdialog chi lo fa?
perchè se lo fa il jframe, l'applicazione giustamente non va avanti perchè il thread principale rimane bloccato.

Nel contesto di un evento (es. actionPerformed):
a) (istanzi se necessario) rendi visibile il JDialog.
b) istanzi il tuo SwingWorker (puoi passargli il JDialog) e lo fai partire (con execute() ).
fine della gestione evento (tutto questo dura pochissimo, non tiene impegnato il EDT!).

Se il tuo SwingWorker ha il riferimento al JDialog e nel doInBackground() vuoi di tanto in tanto aggiornarlo: "pubblichi" i dati con publish ed essi "passano" nel process invocato nel EDT.
Alla fine di tutto, in done nel EDT puoi chiudere il JDialog.

[fermat]

allora, nell'actionPerformed richiamo questo metodo:

    private void createConnection() {
        try {
            if (CheckConnection.check()) {
                JDialog jd = new JDialog(this, true);
                jd.add(BorderLayout.CENTER, new JLabel("...LOADING..."));
                jd.setDefaultCloseOperation(JDialog.DO_NOTHING_ON_CLOSE);
                jd.setSize(300, 75);
                jd.setResizable(false);
                jd.setLocationRelativeTo(this);
                LoadingDialog ld = new LoadingDialog(jd);
                ld.execute();
            } else {
                JOptionPane.showMessageDialog(null, "No connection");
            }
        } catch (IOException ex) {
            JOptionPane.showMessageDialog(null, ex.getMessage());
        }
    }

nello swing worker:

public class ServiceWorker extends SwingWorker<Object, Object> {

    private Service jsb;
    private JDialog jd;

    public ServiceWorker(JDialog jd) {
        jsb = new Service();
        this.jd = jd;
    }

    @Override
    protected Object doInBackground() throws Exception {
        SwingUtilities.invokeLater(new Runnable() {
            @Override
            public void run() {
               jd.setVisible(true);
                try {
                    jsb.launchService("all_books");
                    jsb.launchService("all_authors");
                    jsb.launchService("all_editors");
                    jsb.download(UrlAndPath.JSON_LIBRI);
                    jsb.download(UrlAndPath.JSON_AUTORI);
                    jsb.download(UrlAndPath.JSON_EDITORI);
                    jsb.download(UrlAndPath.GRAPH_AUTHORS);
                } catch (IOException ex) {
                    JOptionPane.showMessageDialog(null, ex.getMessage());
                }
            }
        });
        return null;
    }
    
    @Override
    protected void done() {
        jd.setVisible(false);
    }

}

così mi pare che vada.
dal punto di vista logico invece, andrebbe bene??

[andbin]

così mi pare che vada.
dal punto di vista logico invece, andrebbe bene??

Alt ... n'attimo.
Innanzitutto uno degli obiettivi di SwingWorker è proprio quello di evitare (il più possibile) al programmatore di dover fare, durante un lavoro "lungo", i noiosi invokeLater con il solito Runnable anonimo. Se nel doInBackground ti metti a fare invokeLater ..... forse non stai sfruttando proprio bene SwingWorker ...

Inoltre launchService/download di Service cosa fanno? Fanno del lavoro "lungo"? E allora perché lo fai eseguire nel EDT?
Perché così, tra l'altro, il doInBackground ti dura niente ... nel senso che è praticamente quasi istantaneo ..... e allora ripeto: cosa ti serve così SwingWorker?

[fermat]

launchService/download lanciano dei service remoti che eseguono delle query, e poi scaricano i file in formato json sul pc in modo da avere sempre in locale e offline il tutto, e aggiornare i dati solo quando serve.

la lunghezza del lavoro ovviamente dipende dalla quantità di dati che estrapola il db, da quanto sono grandi i file e dalla connessione.

nel momento in cui decido di aggiornare i dati, il frame dovrebbe rimanere "bloccato" per il tempo che viene eseguita l'operazione, per evitare di fare altre operazioni che possano andare in conflitto.

in questo caso il JDialog è solo un "abbellimento" per dire all'utente che il programma non è bloccato, ma che sta eseguendo una operazione di aggiornamento.

tutto qua!
forse per come è concepito SwingWorker non fa al caso mio.

[andbin]

la lunghezza del lavoro ovviamente dipende dalla quantità di dati che estrapola il db, da quanto sono grandi i file e dalla connessione.

nel momento in cui decido di aggiornare i dati, il frame dovrebbe rimanere "bloccato" per il tempo che viene eseguita l'operazione, per evitare di fare altre operazioni che possano andare in conflitto.

Ma i tuoi download stanno tenendo occupato il EDT (=interfaccia utente "congelata") e il controllo al framework torna solo quando il tuo run() nel doInBackground() termina!
Se in mezzo a quei download facessi dei es. unaLabel.setText("Downloading blabla ....") non li vedi.

forse per come è concepito SwingWorker non fa al caso mio.

No, è quello che ti serve ma devi ancora capirne la filosofia e l'utilizzo.

[valia]

spet, se vuoi fare un upload allora quando è necessario fai comparire un jdialog in cui chiedi se vuole fare l'aggiornamento, perché fatto così non è bello che durante qualsiasi operazione si blocca per upload.
Devi anche gestire il caso in cui ti dice "NO" e lo avvia manualmente.

[fermat]

eh si lo so che EDT rimane bloccato.
ma il fatto è che il refresh della gui (ad esempio la jtable con i dati, o lo sblocco di una jtextfield) deve essere fatto dopo.

il programma è anche in grado di interagire con il db per modificare/aggiungere/cancellare i dati.
e questo ovviamente non deve avvenire in fase di download dei nuovi dati.

ecco perchè dico che in questo è giusto che EDT sia bloccato.
non posso permetere che in fase di scarico dei dati nuovi io aggiorni quelli vecchi.
non so se mi sono spiegato meglio!!

[andbin]

ecco perchè dico che in questo è giusto che EDT sia bloccato.

Che a te vada bene così è un conto ..... ma in generale non è una buona/bella cosa vedere una interfaccia utente "congelata". E congelata non vuol dire che l'utente non deve poter fare altro .....

Se tu volessi mettere nella dialog un pulsante di "annulla", così non lo gestisci. Se tu volessi mettere una label nella dialog per dire di tanto in tanto "Downloading abc..." "Downloading xyz..." ecc... non le vedi 'ste scritte!

[valia]

es. scenario

arrivo io e faccio N modifiche (e non ho ancora salvato tutto tutto). Ad un certo punto parte il tuo thread (che a quanto ho capito è un demone, ma vuoi bloccare per mantenere integrità) e non mi dici niente.
Io poi salvo, ma quello che salvo non esiste più su db...che is fa?
Io devo essere bloccata e tu devi dirmi che stai per fare, quindi il concetto di asincrono non funziona.
Funziona che asincronicamente proponi un aggiornamento (è diverso), ma sono sempre io utente a darti l'ok per il download, quindi rientri nel caso d'uso perfetto.
E come ti ha detto andbin, lo swing worker è perfetto