À utiliser Platform.runLater(...)
pour des opérations rapides et simples et Task
pour des opérations complexes et importantes.
Exemple: Pourquoi ne pouvons-nous pas utiliser Platform.runLater(...)
pour de longs calculs (tirés de la référence ci-dessous).
Problème: thread d'arrière-plan qui ne compte que de 0 à 1 million et met à jour la barre de progression dans l'interface utilisateur.
Code utilisant Platform.runLater(...)
:
final ProgressBar bar = new ProgressBar();
new Thread(new Runnable() {
@Override public void run() {
for (int i = 1; i <= 1000000; i++) {
final int counter = i;
Platform.runLater(new Runnable() {
@Override public void run() {
bar.setProgress(counter / 1000000.0);
}
});
}
}).start();
C'est un morceau de code hideux, un crime contre la nature (et la programmation en général). Tout d'abord, vous perdrez des cellules cérébrales rien qu'en regardant cette double imbrication de Runnables. Deuxièmement, cela va submerger la file d'attente des événements avec de petits Runnables - un million d'entre eux en fait. De toute évidence, nous avions besoin d'une API pour faciliter l'écriture de travailleurs d'arrière-plan qui communiquent ensuite avec l'interface utilisateur.
Code utilisant la tâche:
Task task = new Task<Void>() {
@Override public Void call() {
static final int max = 1000000;
for (int i = 1; i <= max; i++) {
updateProgress(i, max);
}
return null;
}
};
ProgressBar bar = new ProgressBar();
bar.progressProperty().bind(task.progressProperty());
new Thread(task).start();
il ne souffre d'aucun des défauts présentés dans le code précédent
Référence:
Worker Threading dans JavaFX 2.0