Charnière, simulateurs cloud et tests rejouables

Expo Hinge fournit un état d’interaction, pas une grille de layout

Expo Hinge pour SDK 58 (nouvelle fenêtre) expose l’angle en degrés et le statut de la charnière sur les pliables Android et iPhone Duo. useHinge() suit les changements ; l’API peut retourner null sur un appareil ou un système non pris en charge. Android ne renvoie jamais le statut closed : il faut déduire la fermeture d’un angle proche de 0. Le statut vaut unknown dans d’autres cas, par exemple sur l’écran externe d’un appareil fermé, mais l’angle reste disponible.

Le layout doit donc continuer à dépendre de l’espace disponible dans la fenêtre. L’angle est utile pour un effet ou une interaction, par exemple un panneau qui accompagne l’ouverture physique. Il ne remplace pas la largeur nécessaire à une liste et à son détail. La gestion explicite de null conserve aussi une expérience complète sur un téléphone sans charnière.

Argent Cloud déplace les simulateurs, avec les serveurs toujours à joindre

L’article Argent Cloud du 13 octobre (nouvelle fenêtre) décrit des simulateurs iOS déjà démarrés, des sessions isolées sur Mac dédié et des tunnels bidirectionnels vers les serveurs de développement. Il propose aussi une caméra virtuelle et une compatibilité avec de nombreuses commandes simctl.

Pour une app Expo, le tunnel ne sert pas seulement à afficher l’image du téléphone. L’application doit joindre Metro et son backend ; ces connexions font partie de la session. Un écran qui charge correctement son JavaScript mais n’accède pas aux données n’exerce pas le parcours attendu.

Le dimensionnement dépend du nombre de sessions réellement simultanées, de leur durée et du temps d’attente acceptable. Une formule fixe peut convenir à une forte utilisation ; elle ne prouve pas une économie pour tous les rythmes de CI.

Le retour incident.io (nouvelle fenêtre) insiste sur une autre condition : chaque agent dispose aussi de son backend et de sa base remplie de données de test. Le simulateur rejoint cet environnement par tunnel. Cette isolation permet de modifier une alerte ou une session sans perturber les autres runs. Le rapport lie ensuite chaque affirmation aux captures et au moment correspondant dans la vidéo ; la décision finale reste humaine.

e2e cache les actions et garde le jugement sur l’état présent

Le billet e2e avec agent-device (nouvelle fenêtre) distingue agent.act, les assertions déterministes et agent.assert. Après un parcours réussi et confirmé, les actions peuvent être mises en cache puis rejouées sans nouvel appel au modèle pour cette étape. Si le replay échoue après une modification de l’interface, l’agent peut retrouver un chemin et l’enregistrer à nouveau. Le jugement reste exécuté sur l’état courant.

Cette séparation évite de confondre « l’agent a déjà réussi ce chemin » et « la fonctionnalité fonctionne encore ». Pour une même donnée attendue, une assertion exacte conserve sa valeur même si la position des contrôles change. La vidéo et les snapshots d’accessibilité aident ensuite à comprendre si un échec vient du chemin ou du résultat métier.