Aller au contenu principal

Asynchronous Updates

Ouvrir dans ChatGPT
25.02 Experimental
Java API

L'API Environment.runLater() fournit un mécanisme pour mettre à jour en toute sécurité l'interface utilisateur à partir de threads d'arrière-plan dans les applications webforJ. Cette fonctionnalité expérimentale permet des opérations asynchrones tout en maintenant la sécurité des threads pour les modifications de l'interface utilisateur.

API expérimentale

Cette API est marquée comme expérimentale depuis 25.02 et peut changer dans les futures versions. La signature de l'API, le comportement et les caractéristiques de performance sont susceptibles d'être modifiés.

Comprendre le modèle de thread​

webforJ impose un modèle de threading strict où toutes les opérations d'interface utilisateur doivent se produire sur le thread Environment. Cette restriction existe en raison de :

  1. Contraintes de l'API webforJ : L'API sous-jacente webforJ est liée au thread qui a créé la session
  2. Affinité des threads aux composants : Les composants de l'interface utilisateur maintiennent un état qui n'est pas thread-safe
  3. Dispatch des événements : Tous les événements d'interface utilisateur sont traités séquentiellement sur un seul thread

Ce modèle à thread unique empêche les conditions de compétition et maintient un état cohérent pour tous les composants d'interface utilisateur, mais crée des défis lors de l'intégration avec des tâches de calcul asynchrones et de longue durée.

API RunLater​

L'API Environment.runLater() fournit deux méthodes pour planifier des mises à jour de l'interface utilisateur :

Environment.java
// Planifier une tâche sans valeur de retour
public static PendingResult<Void> runLater(Runnable task)

// Planifier une tâche qui retourne une valeur
public static <T> PendingResult<T> runLater(Supplier<T> supplier)

Les deux méthodes retournent un PendingResult qui suit l'achèvement de la tâche et donne accès au résultat ou aux exceptions qui se sont produites.

Héritage du contexte de thread​

L'héritage automatique du contexte est une fonctionnalité critique de Environment.runLater(). Lorsqu'un thread s'exécutant dans un Environment crée des threads enfants, ces derniers héritent automatiquement de la capacité à utiliser runLater().

Comment l'héritage fonctionne​

Tout thread créé à partir d'un thread Environment a automatiquement accès à cet Environment. Cet héritage se produit automatiquement, vous n'avez donc pas besoin de transmettre de contexte ou de configurer quoi que ce soit.

@Route
public class DataView extends Composite<Div> {
    private final ExecutorService executor = Executors.newCachedThreadPool();
    
    public DataView() {
        // Ce thread a le contexte Environment
        
        // Les threads enfants héritent automatiquement du contexte
        executor.submit(() -> {
            String data = fetchRemoteData();
            
            // Peut utiliser runLater parce que le contexte a été hérité
            Environment.runLater(() -> {
                dataLabel.setText(data);
                loadingSpinner.setVisible(false);
            });
        });
    }
}

Threads sans contexte​

Les threads créés hors du contexte Environment ne peuvent pas utiliser runLater() et lanceront une IllegalStateException :

// Initialiseur statique - pas de contexte Environment
static {
    new Thread(() -> {
        Environment.runLater(() -> {});  // Lance IllegalStateException
    }).start();
}

// Threads de minuteur système - pas de contexte Environment  
Timer timer = new Timer();
timer.schedule(new TimerTask() {
    public void run() {
        Environment.runLater(() -> {});  // Lance IllegalStateException
    }
}, 1000);

// Threads de bibliothèques externes - pas de contexte Environment
httpClient.sendAsync(request, responseHandler)
    .thenAccept(response -> {
        Environment.runLater(() -> {});  // Lance IllegalStateException
    });

Comportement d'exécution​

Le comportement d'exécution de runLater() dépend du thread qui l'appelle :

Depuis le thread UI​

Lorsque appelé depuis le thread Environment lui-même, les tâches s'exécutent synchroniquement et immédiatement :

button.onClick(e -> {
    System.out.println("Avant : " + Thread.currentThread().getName());
    
    PendingResult<String> result = Environment.runLater(() -> {
        System.out.println("À l'intérieur : " + Thread.currentThread().getName());
        return "terminé";
    });
    
    System.out.println("Après : " + result.isDone());  // true
});

Avec ce comportement synchrone, les mises à jour de l'interface utilisateur provenant des gestionnaires d'événements sont appliquées immédiatement et n'encourent aucun surcoût de mise en file d'attente inutile.

Depuis les threads d'arrière-plan​

Lorsque appelé depuis un thread d'arrière-plan, les tâches sont mis en file d'attente pour une exécution asynchrone :

@Override
public void onDidCreate() {
    CompletableFuture.runAsync(() -> {
        // Cela s'exécute sur le thread ForkJoinPool
        System.out.println("Arrière-plan : " + Thread.currentThread().getName());
        
        PendingResult<Void> result = Environment.runLater(() -> {
            // Cela s'exécute sur le thread Environment
            System.out.println("Mise à jour UI : " + Thread.currentThread().getName());
            statusLabel.setText("Traitement terminé");
        });
        
        // result.isDone() serait faux ici
        // La tâche est mise en file d'attente et s'exécutera de manière asynchrone
    });
}

webforJ traite les tâches soumises depuis des threads d'arrière-plan dans un ordre FIFO strict, préservant la séquence des opérations même lorsqu'elles sont soumises concurrentiellement depuis plusieurs threads. Avec cette garantie d'ordre, les mises à jour de l'interface utilisateur sont appliquées dans l'ordre exact dans lequel elles ont été soumises. Donc, si le thread A soumet la tâche 1, puis que le thread B soumet la tâche 2, la tâche 1 s'exécutera toujours avant la tâche 2 sur le thread UI. Le traitement des tâches dans l'ordre FIFO empêche les incohérences dans l'interface utilisateur.

Annulation de tâche​

Le PendingResult retourné par Environment.runLater() prend en charge l'annulation, vous permettant d'empêcher l'exécution des tâches mises en file d'attente. En annulant les tâches en attente, vous pouvez éviter les fuites de mémoire et empêcher les opérations de longue durée de mettre à jour l'interface utilisateur après qu'elles ne soient plus nécessaires.

Annulation de base​

PendingResult<Void> result = Environment.runLater(() -> {
    updateUI();
});

// Annuler si pas encore exécuté
if (!result.isDone()) {
    result.cancel();
}

Gestion de plusieurs mises à jour​

Lors de l'exécution d'opérations de longue durée avec des mises à jour fréquentes de l'interface utilisateur, suivez tous les résultats en attente :

public class LongRunningTask {
    private final List<PendingResult<?>> pendingUpdates = new ArrayList<>();
    private volatile boolean isCancelled = false;
    
    public void startTask() {
        CompletableFuture.runAsync(() -> {
            for (int i = 0; i <= 100; i++) {
                if (isCancelled) return;
                
                final int progress = i;
                PendingResult<Void> update = Environment.runLater(() -> {
                    progressBar.setValue(progress);
                });
                
                // Suivre pour une annulation potentielle
                pendingUpdates.add(update);
                
                Thread.sleep(100);
            }
        });
    }
    
    public void cancelTask() {
        isCancelled = true;
        
        // Annuler toutes les mises à jour UI en attente
        for (PendingResult<?> pending : pendingUpdates) {
            if (!pending.isDone()) {
                pending.cancel();
            }
        }
        pendingUpdates.clear();
    }
}

Gestion du cycle de vie des composants​

Lorsque des composants sont détruits (par exemple, lors de la navigation), annulez toutes les mises à jour en attente pour éviter les fuites de mémoire :

@Route
public class CleanupView extends Composite<Div> {
    private final List<PendingResult<?>> pendingUpdates = new ArrayList<>();
    
    @Override
    protected void onDestroy() {
        super.onDestroy();
        
        // Annuler toutes les mises à jour en attente pour éviter les fuites de mémoire
        for (PendingResult<?> pending : pendingUpdates) {
            if (!pending.isDone()) {
                pending.cancel();
            }
        }
        pendingUpdates.clear();
    }
}

Considérations de conception​

  1. Exigence de contexte : Les threads doivent avoir hérité d'un contexte Environment. Les threads de bibliothèques externes, les minuteurs système et les initialisateurs statiques ne peuvent pas utiliser cette API.

  2. Prévention des fuites de mémoire : Veillez toujours à suivre et à annuler les objets PendingResult dans les méthodes du cycle de vie des composants. Les lambdas en file d'attente capturent des références à des composants de l'interface utilisateur, empêchant la collecte de déchets si elles ne sont pas annulées.

  3. Exécution FIFO : Toutes les tâches s'exécutent dans un ordre FIFO strict, indépendamment de leur importance. Il n'y a pas de système de priorité.

  4. Limitations d'annulation : L'annulation empêche uniquement l'exécution des tâches mises en file d'attente. Les tâches déjà en cours d'exécution se termineront normalement.

Étude de cas complète : LongTaskView​

Voici une réalisation complète et prête pour la production démontrant toutes les meilleures pratiques pour des mises à jour UI asynchrones :

LongTaskView.java
    startButton.setEnabled(false);
    cancelButton.setEnabled(true);
    statusField.setValue("Démarrage de la tâche d'arrière-plan...");
    progressBar.setValue(0);
    resultField.setValue("");

    // Réinitialiser le drapeau annulé et effacer les mises à jour en attente précédentes
    isCancelled = false;
    pendingUIUpdates.clear();

    // Démarrer la tâche d'arrière-plan avec un exécuteur explicite
    // Remarque : cancel(true) interrompt le thread, ce qui fait que Thread.sleep() lance
    // InterruptedException
    currentTask = CompletableFuture.runAsync(() -> {
      double result = 0;

      // Simuler une tâche longue avec 100 étapes
      for (int i = 0; i <= 100; i++) {
        // Vérifier si annulé
        if (isCancelled) {
          PendingResult<Void> cancelUpdate = Environment.runLater(() -> {
            statusField.setValue("Tâche annulée !");
            progressBar.setValue(0);
            resultField.setValue("");
            startButton.setEnabled(true);
            cancelButton.setEnabled(false);
            showToast("La tâche a été annulée", Theme.GRAY);
          });
          pendingUIUpdates.add(cancelUpdate);
          return;
        }

        try {
          Thread.sleep(100); // 10 secondes au total
        } catch (InterruptedException e) {
          // Le thread a été interrompu - sortir immédiatement
          Thread.currentThread().interrupt(); // Rétablir le statut interrompu
          return;
        }

        // Effectuer un calcul (déterministe pour la démonstration)
        // Produit des valeurs entre 0 et 1
        result += Math.sin(i) * 0.5 + 0.5;

        // Mettre à jour la progression depuis le thread d'arrière-plan
        final int progress = i;
        PendingResult<Void> updateResult = Environment.runLater(() -> {
          progressBar.setValue(progress);
          statusField.setValue("Traitement... " + progress + "%");
        });
        pendingUIUpdates.add(updateResult);
      }

      // Mise à jour finale avec le résultat (ce code n'est atteint que si la tâche s'est terminée sans
      // annulation)
      if (!isCancelled) {
        final double finalResult = result;
        PendingResult<Void> finalUpdate = Environment.runLater(() -> {
          statusField.setValue("Tâche terminée !");
          resultField.setValue("Résultat : " + String.format("%.2f", finalResult));
          startButton.setEnabled(true);
          cancelButton.setEnabled(false);
          showToast("La tâche d'arrière-plan est terminée !", Theme.SUCCESS);
        });
        pendingUIUpdates.add(finalUpdate);
      }
    }, executor);
  }

Analyse de l'étude de cas​

Cette mise en œuvre démontre plusieurs schémas critiques :

1. Gestion du pool de threads​

private final ExecutorService executor = Executors.newSingleThreadExecutor(r -> {
    Thread t = new Thread(r, "LongTaskView-Worker");
    t.setDaemon(true);
    return t;
});
  • Utilise un exécuteur à thread unique pour éviter l'épuisement des ressources
  • Crée des threads de démon qui n'empêchent pas l'arrêt de la JVM

2. Suivi des mises à jour en attente​

private final List<PendingResult<?>> pendingUIUpdates = new ArrayList<>();

Chaque appel à Environment.runLater() est suivi pour permettre :

  • L'annulation lorsque l'utilisateur clique sur annuler
  • La prévention des fuites de mémoire dans onDestroy()
  • Un nettoyage approprié pendant le cycle de vie du composant

3. Annulation coopérative​

private volatile boolean isCancelled = false;

Le thread d'arrière-plan vérifie ce drapeau à chaque itération, permettant :

  • Une réponse immédiate à l'annulation
  • Une sortie propre de la boucle
  • La prévention de mises à jour d'UI supplémentaires

4. Gestion du cycle de vie​

@Override
protected void onDestroy() {
    super.onDestroy();
    cancelTask();  // Réutilise la logique d'annulation
    currentTask = null;
    executor.shutdown();
}

Critique pour prévenir les fuites de mémoire en :

  • Annulant toutes les mises à jour UI en attente
  • Interrompant les threads en cours d'exécution
  • Arrêtant l'exécuteur

5. Test de réactivité de l'UI​

testButton.onClick(e -> {
    int count = clickCount.incrementAndGet();
    showToast("Clic #" + count + " - L'interface utilisateur est réactive !", Theme.GRAY);
});

Démontre que le thread UI reste réactif pendant les opérations d'arrière-plan.