Pandarine
Les capteurs marchent. Il leur faut leur propre build
La promesse, c'est un compagnon qui grandit selon la façon dont on se sert vraiment de son téléphone, pas selon le nombre de fois qu'on le tapote. Cette partie-là est faite. Le podomètre alimente l'expérience toute la journée ; on incline le téléphone, il se penche avec ; on le pose à plat, il s'allonge ; on le secoue fort, on déclenche un tremblement de terre. On branche le chargeur, son confort monte tant que le câble reste en place. On passe du Wi-Fi aux données mobiles, il en déduit qu'on est sorti.
Rien de tout cela ne demande de compte, d'identifiant ni de position.
La limite que personne n'affiche
Expo Go — l'application bac à sable qui fait tourner un projet sur un vrai téléphone en quelques secondes — ne laisse ces capteurs fonctionner qu'au premier plan. On ferme l'application, les relevés s'arrêtent. Le compagnon continue de vivre, puisque la décroissance se calcule à partir d'horodatages, mais il n'apprend plus rien sur nous. La fonction phare marche exactement tant qu'on la regarde.
La sortie, c'est un build de développement sur mesure, et sa configuration est arrivée cette semaine : expo-dev-client, un eas.json, et la clé iOS d'usage des données de mouvement que la plateforme exige avant de livrer le nombre de pas.
Pourquoi c'est de la plomberie, pas de la chirurgie
Tout ce qui agit sur le compagnon est un stimulus : un ensemble d'effets et un peu d'expérience. Un appui sur un bouton et un nombre de pas, c'est la même chose pour le moteur.
La décision date du premier jour, avant qu'il y ait quoi que ce soit à quoi l'appliquer. C'est pour ça que passer des soins tapotés à l'entrée capteur change d'où viennent les nombres, et rien d'autre : le moteur n'apprend jamais ce qu'est un podomètre.