Asynchronous Updates

Ouvrir dans ChatGPT

25.02 Expérimental

Java API

L'API Environment.runLater() fournit un mécanisme pour mettre à jour l'interface utilisateur en toute sécurité depuis des 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.

Fonctionnalité expérimentale

Cette fonctionnalité est expérimentale et peut changer ou être supprimée dans une future version.

AI skill available

The webforj-handling-timers-and-async skill can schedule timers, debouncers, and async work safely on the UI thread. After installing the webforJ AI plugin, ask your assistant:

• "Refresh this dashboard every 30 seconds."
• "Add a search-as-you-type debouncer."
• "Run this CPU-heavy work in the background and update the progress bar."

Compréhension du modèle de thread

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

1. Contraintes de l'API webforJ : L'API webforJ sous-jacente est liée au thread qui a créé la session.
2. Affinité des threads de composants : Les composants de l'interface utilisateur maintiennent un état qui n'est pas sûr pour les threads.
3. Dispatching d'événements : Tous les événements de l'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 de l'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 renvoie une valeur
public static <T> PendingResult<T> runLater(Supplier<T> supplier)

Les deux méthodes renvoient un PendingResult qui suit l'achèvement de la tâche et donne accès au résultat ou à toute exception qui s'est produite.

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 enfants héritent automatiquement de la capacité à utiliser runLater().

Comment fonctionne l'héritage

Tout thread créé à partir d'un thread Environment a automatiquement accès à cet Environment. Cet héritage se produit automatiquement, donc vous n'avez 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 un contexte Environment

    // Les threads enfants héritent automatiquement du contexte
    executor.submit(() -> {
      String data = fetchRemoteData();

      // Peut utiliser runLater car le contexte a été hérité
      Environment.runLater(() -> {
        dataLabel.setText(data);
        loadingSpinner.setVisible(false);
      });
    });
  }
}

Threads sans contexte

Les threads créés en dehors 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 minuterie 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 de l'interface utilisateur

Lorsqu'il est appelé depuis le thread Environment lui-même, les tâches s'exécutent de manière synchrone et immédiate :

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 des gestionnaires d'événements sont appliquées immédiatement et n'encourent aucun coût supplémentaire de mise en file d'attente.

Depuis des threads d'arrière-plan

Lorsqu'il est 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(() -> {
    // Ceci s'exécute sur le thread ForkJoinPool
    System.out.println("Arrière-plan : " + Thread.currentThread().getName());

    PendingResult<Void> result = Environment.runLater(() -> {
      // Ceci s'exécute sur le thread Environment
      System.out.println("Mise à jour de l'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 depuis plusieurs threads en même temps. Avec cette garantie d'ordre, les mises à jour de l'interface utilisateur sont appliquées exactement dans l'ordre où elles ont été soumises. Ainsi, si le thread A soumet la tâche 1, puis le thread B soumet la tâche 2, la tâche 1 s'exécutera toujours avant la tâche 2 sur le thread de l'interface utilisateur. Le traitement des tâches dans l'ordre FIFO empêche les incohérences dans l'interface utilisateur.

Annulation de tâches

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 sont plus nécessaires.

Annulation basique

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 éventuelle annulation
        pendingUpdates.add(update);

        Thread.sleep(100);
      }
    });
  }

  public void cancelTask() {
    isCancelled = true;

    // Annuler toutes les mises à jour d'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 minuteries système et les initialisateurs statiques ne peuvent pas utiliser cette API.

2. Prévention des fuites de mémoire : Suivez et annulez toujours les objets PendingResult dans les méthodes de cycle de vie des composants. Les lambdas mises en file d'attente capturent des références aux composants de l'interface utilisateur, empêchant la collecte des ordures 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 de l'annulation : L'annulation empêche seulement l'exécution des tâches mises en file d'attente. Les tâches déjà en cours d'exécution s'achèveront normalement.

Étude de cas complète : LongTaskView

La suite est une implémentation complète, prête pour la production, démontrant toutes les meilleures pratiques pour des mises à jour d'interface utilisateur asynchrones :

LongTaskView.java

  startButton.setEnabled(false);
  cancelButton.setEnabled(true);
  statusField.setValue("Démarrage de la tâche en 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) interrompra le thread, ce qui provoquera
  // InterruptedException dans Thread.sleep()
  currentTask = CompletableFuture.runAsync(() -> {
    double result = 0;

    // Simuler une longue tâche 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 - sortie immédiate
        Thread.currentThread().interrupt(); // Restaurer l'état 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 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 en arrière-plan est terminée !", Theme.SUCCESS);
      });
      pendingUIUpdates.add(finalUpdate);
    }
  }, executor);
}

Analyse de l'étude de cas

Cette implémentation démontre plusieurs modèles 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 daemon qui n'empêcheront 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 supplémentaires de l'UI.

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 d'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'UI est réactive !", Theme.GRAY);
});

Démontre que le thread de l'interface utilisateur reste réactif pendant les opérations en arrière-plan.