Le glisser en temps réel sur un appareil réel (pas seulement un début et une fin)

Il y a deux choses très différentes que l'on appelle « un balayage ».

La première est un geste synthétisé : appuyer au point A, relâcher au point B, et laisser l'OS interpoler ce qui s'est passé entre les deux. La seconde est un flux continu d'événements de pointeur — chaque position intermédiaire, à la vitesse réelle du doigt.

La plupart des applications se comportent de façon identique dans les deux cas. Les intéressantes, non.

Pourquoi la différence apparaît

Un balayage synthétisé remet à l'application un mouvement idéalisé : une ligne droite, une vitesse uniforme et, surtout, livré en grande partie après la fin de l'interaction. Tout ce qui réagit pendant que le doigt est encore posé n'est jamais sollicité.

Les fonctionnalités concernées :

• Réorganisation par glisser-déposer. La liste doit se redisposer sous l'élément pendant qu'il se déplace. Avec des événements de début et de fin seulement, l'élément se téléporte et la logique de redisposition n'est jamais exécutée.
• Curseurs et incrémenteurs. La valeur doit suivre le doigt en continu. Un geste en deux points teste la valeur finale et rien d'autre.
• Cartes. Le déplacement, l'inertie et le chargement des tuiles dépendent tous de la vitesse et de la direction dans le temps.
• Canevas et capture de signature. Une signature tracée en ligne droite de A à B n'est pas une signature.
• Tirer pour rafraîchir. Le seuil, l'effet élastique, l'indicateur qui apparaît à mi-course — autant d'états en cours de geste.
• Carrousels avec inertie. Qu'un mouvement rapide atterrisse sur la carte suivante dépend de sa vitesse au moment du relâchement, pas de son point de départ.

Si votre outil de test à distance n'envoie que le début et la fin, ce sont les bugs qui atteignent la production parce qu'ils n'ont jamais été réellement exercés.

Ce que l'événementiel en temps réel signifie ici

Sur RobotActions, faire glisser dans la vue de l'appareil diffuse les événements de pointeur au fur et à mesure du mouvement — comme une application de bureau reçoit les entrées de la souris. L'application voit un tracé continu au rythme réel, si bien que le comportement en cours de geste s'exécute exactement comme sous un vrai doigt. La latence compte aussi : un flux de gestes qui arrive en retard est un geste différent.

Il en va de même via l'API. Un agent IA qui pilote l'appareil par MCP peut effectuer un véritable glisser le long d'un tracé plutôt qu'une approximation en deux points : les tests exécutés par l'agent sollicitent donc les mêmes chemins de code qu'un humain.

Comment vérifier votre application

Choisissez les trois écrans les plus susceptibles de dépendre d'un état en cours de geste — une liste réorganisable, un curseur, et une carte ou un carrousel — et manipulez chacun lentement :

1. Appuyez et maintenez, puis déplacez progressivement. L'interface réagit-elle pendant le mouvement ?
2. Arrêtez-vous à mi-chemin et restez immobile. L'état intermédiaire est-il correct, ou a-t-on l'impression qu'il ne s'est encore rien passé ?
3. Inversez la direction sans relâcher. Beaucoup d'implémentations ne gèrent qu'un seul axe de déplacement une fois le geste classé.
4. Relâchez en pleine vitesse. L'inertie se prolonge-t-elle comme elle le devrait ?

L'étape 3 révèle un nombre surprenant de défauts, car les détecteurs de gestes se verrouillent souvent sur une direction au premier mouvement et ne se ravisent jamais.

Essayez sur du matériel

Le toucher réel est imprécis, rapide et continu. Le tester avec deux coordonnées et une interpolation revient à tester une entrée différente de celle dont disposent vos utilisateurs.

Faites glisser sur un appareil réel et regardez-le répondre en direct →