Ordonnancement de tâches dans GWT avec la classe Scheduler

Ces deux méthodes permettent d'exécuter une tâche répétitive à intervalles fixes. ScheduleFixedDelay permet d'assurer un temps fixe entre la fin d'une tâche et le début d'une autre (exemple : si une tâche prend 30 ms pour s'exécuter et si un délai de 100 ms est fixé, la tâche suivante s'exécutera 130 ms après l'exécution de la première). ScheduleFixedPeriod permet, elle, d'assurer un temps fixe entre l'ensemble des invocations (exemple : si une tâche prend 30 ms pour s'exécuter et si un délai de 100 ms est fixé, la tâche suivante s'exécutera 100 ms après l'exécution de la première).

Remarque : ces deux méthodes prennent (en plus du délai/période fixé) un objet Scheduler.RepeatingCommand en paramètre qui est exécuté tant qu'il renvoie la valeur true en sortie.

Afin d'appréhender ces deux méthodes, il est nécessaire de comprendre les mécanismes de base de GWT de traitement des évènements natifs et applicatifs. Il faut tout d'abord savoir que l'ensemble des évènements du navigateur sont interceptés par GWT (mouse, keyboard, load, xhr, timer...) même si le développeur n'estime pas en avoir besoin (i.e. pas d'EventHandler associé).

Dès qu'un événement est intercepté, ce dernier est redispatché vers l'application. Le renvoi de l'évènement est "encadré" par une méthode $entry (méthode proxy). L'objectif principal de cette fonction est de "décorer" tout appel à du code GWT (handler, RPC, timer et load pour faire simple) afin d'assurer la gestion des tâches de type "entry" et "finally".

Premièrement, la méthode $entry dépile l'ensemble des commandes entry en cours et les exécute. Une fois cette étape terminée, $entry lance le code GWT cible. Finalement, $entry exécute l'ensemble des commandes finally en attente.

Pour résumer, une méthode créant des commandes "entry" et "finally" aura pour conséquence l'exécution : - des commandes finally une fois le code GWT en cours exécuté - des commandes entry lors du prochain évènement natif ou applicatif.

Exemple : dans l'application suivante, nous détectons les mouvements effectués sur le label principal. Dès que la souris entre sur le composant, le label est modifié et une commande entry est enregistrée. On constate qu'au premier mouvement, la zone est modifiée mais que le popup d'alerte lui n'apparaît pas. Pour ce faire, il suffit de déclencher un évènement quelconque (autre mouvement de souris ou appui sur une touche du clavier par exemple).

public void onModuleLoad() {
       final Label label = new Label("MOVE AREA");
       label.setStyleName("label");
       RootPanel.get().add(label);
 
       label.addMouseMoveHandler(new MouseMoveHandler() {
 
               public void onMouseMove(MouseMoveEvent event) {
                       label.setText("MOVE DETECTED");
                       label.setStyleName("move");
 
                       Scheduler.get().scheduleEntry(new ScheduledCommand() {
                               public void execute() {
                                       Window.alert("ENTRY EXECUTED");
                               }
                       });
               }
       });
}

On comprend mieux maintenant pourquoi la Javadoc indique que les commandes entry permettent d'effectuer une action "dès qu'il se passequelque chose" (sic).

Nous avons tous déjà connu cette situation qui consiste à attendre pendant plusieurs secondes l'affichage d'une liste de données volumineuse. En effet, le fonctionnement monothreadé du JavaScript fait qu'il ne peut pas gérer simultanément la construction de l'arbre et son affichage (layout & paint event).

ScheduleIncremental permet de répondre au besoin d'affichage "en temps réel". Le principe est relativement simple : ScheduleIncremental laisse "souffler" à intervalle régulier le moteur JavaScript pour lui permettre de gérer l'affichage de l'arbre en construction. En effet, une commande incrémentale doit, une fois le travail effectué, indiquer si elle doit être relancée ou pas. Si c'est le cas, un timer (i.e. setTimeout) est lancé 1ms plus tard.

1 ms est la période minimale autorisée par les moteurs JavaScript, c'est largement assez pour laisser le temps au navigateur de mettre à jour l'affichage : durant l'exécution de la commande, toute modification de l'arbre engendre une demande de mise à jour de l'affichage (layout event) qui est alors mise en file d'attente au niveau de l'event loop. L'événement timeout arrive donc après la mise à jour de l'affichage permettant ainsi d'alterner construction de l'arbre et mise à jour de l'affichage, comme dans l'exemple suivant :

public void onModuleLoad() {
       Scheduler.get().scheduleIncremental(new RepeatingCommand() {
               private int count = 0;
 
               public boolean execute() {
                       RootPanel.get().add(new Label("****"));
                       count++;
                       return count < 1000;
               }
       });
}

Dans l'outil de Google Speed Tracer, on peut voir l'alternance timer/affichage.

Remarque : pour chaque appel, deux timers sont en fait lancés  : Flusher et Rescuer. Le premier exécute la tâche, le deuxième relance éventuellement le flusher en cas d'échec de celui-ci.

L'objectif est d'assurer l'exécution d'une tâche une fois l'ensemble des évènements en attente traités alors que scheduleFinally exécute cette tâche avant. Par exemple, si vous voulez effectuer une tâche avant la mise à jour de l'affichage, vous utiliserez scheduleFinally et scheduleDeferred si vous voulez l'exécuter après la mise à jour de l'affichage (exemple : focus sur un champ donné).

Pour ce faire, l'implémentation est assez proche de scheduleIncremental : un timer de 1 ms est lancé permettant ainsi de mettre la tâche en file d'attente au sein de l'Event Loop et donc de lancer la commande une fois les évènements en attente traités.