Voilà ce qui m’occupe depuis ce matin : trouver une solution au rejet par un Store que vous allez vite reconnaître d’une application qui marchait très bien avant et risque de perdre 4/5 de ses utilisateurs après. Mais avant d’entrer dans les détails, regardez cette vidéo…

Voilà de la Réalité Augmentée facile à comprendre. Une grille de Sudoku que vous devez terminer dans le train, des chiffres qui n’arrivent pas à se mettre en place, et un voisin qui vient de vous dire par dessus votre épaule : « non, c’est plutôt un 4, là ». Bref, vous sortez l’arme fatale car il y a sûrement une application pour ça aussi, vous filmez, et hop la grille se fait toute seule. Votre voisin s’incline, ainsi que le bilan carbone de cette petite manipulation.

Comment tout cela a-t-il été possible ? Y a-t-il un homoncule caché dans votre mobile et spécialiste des Sudoku ? Démontez-le, vous verrez.

Pour les moins hardis, la solution c’est que l’application pour ça aussi a accès à l’écran de votre mobile, voit tout ce qui s’y passe, repère une grille, repère des chiffres, les reconnaît, se dit bon sang mais c’est bien sûr c’est la grille Sudoku numéro 15467, active son petit algorithme de résolution des Sudoku (celui que vous cherchez depuis 3 ans chaque matin dans le train), résoud l’affaire, et affiche en surimpression sur l’écran la solution, sous les applaudissements de tout le compartiment.

Et là vous me dites, parce que vous suivez de près : « comment ça, a accès à l’écran de votre mobile ? Pourquoi pas plutôt à ce que la caméra filme ? ». Bonne question, très bonne question. Le hic, c’est que ce mobile-ci a depuis tout temps empêché les développeurs qui travaillent pour lui d’accéder à la dite caméra. Oh, on peut accéder à l’appareil photo et prendre une photo. Mais pas un flux continu.

Pourtant, c’est possible, on le voit dans cette vidéo Sudoku, on le voit quand on utilise une appli qui décode des codes barres et vous propose d’acheter sur Amazon le livre que vous tenez entre les mains, bon, bref, des trucs utiles.

C’est possible, parce que le « depuis tout temps » ci-dessus a fait son temps, et qu’en décembre dernier, le constructeur du mobile a autorisé les développeurs à utiliser une fonction qu’on appelera UIGetScreenImage parce que c’est son nom et que c’est comme ça que d’autres développeurs vont arriver sur ce billet. Cette fonction, autrefois privée (c’est-à-dire non documentée, enfin pas trop, enfin faut pas l’utiliser sinon votre appli sera rejetée du Store), est soudain devenue autorisée, à la grande joie des développeurs et des joueurs de Sudoku. Mais avec la mention, fort raisonnable suivante, que je n’ai pas complètement le droit de retranscrire texto, mais qui dit en substance : « Bientôt arrivera un nouvel ensemble de fonctions permettant d’accéder à la caméra, bien plus efficaces et mieux pensées, et ce Jour-là vous devrez abandonner UIGetScreenImage et utiliser ces nouvelles fonctions ».

Petit aparté : que fait cette fonction ? Elle capture ce qui se passe à l’écran ; comme ça, si vous filmez, elle capture ce que vous filmez. Elle capture aussi tout ce qu’il y a sur l’écran, comme par exemple d’autres éléments de l’interface de l’application, les boutons, du texte, le champ dans lequel vous allez mettre votre adresse perso…

Alors, reprenons à ce Jour-là. Ce Jour-là est arrivé récemment avec la sortie de la dernière version du système d’exploitation du mobile, qu’on dira être de version 4, pour fixer les idées. On dira qu’avant il y avait la version 3.1, 3.2 etc. . Avec la 4, le mobile devient très fort. On peut suivre ce qu’il filme, grâce à la nouvelle API et notamment une nouvelle fonction qui pourrait bien s’appeler AVCaptureSession, et il est tellement fort qu’il sait faire plusieurs choses à la fois (ou, en termes savants, du multitasking). À compter de ce Jour-là, les développeurs doivent abandonner l’ancienne fonction UIetc, et passer à la nouvelle AVetc. Dans les forums, certains estiment que la nouvelle protège l’utilisateur des applications qui tourneraient par en-dessous (multitasking, rappelez-vous) pour regarder ce qui se passe sur votre écran, sans que vous le sachiez. Si c’est une des raisons nécessitant de passer à AVetc. c’est une très bonne raison.

Mais alors, où est le problème ? Eh bien il est très simple. En obligeant les développeurs à soumettre les nouvelles versions de leur application avec la fonction AVetc, le constructeur de ce mobile oblige également à développer l’application selon la version 4 du système d’exploitation. En d’autres termes, nous aurions les choix suivants :

• ne toucher à rien, et ne plus faire évoluer nos applications, qui tourneront sur les systèmes 3.1, 3.2, 4…
• vouloir ajouter des fonctionnalités à nos applications, et dans ce cas être obligé de ne plus utiliser UIetc, et alors…
  • soit proposer une application qui sous version 4 est capable de capturer la caméra (ce qu’on appelle le mode Scan), et en version 3 oblige l’utilisateur à prendre une photo et agir sur cette photo (et donc renvoyer l’utilisateur à une expérience utilisateur d’il y a 6 mois)
  • soit ne plus toucher à son appli en version < 4 et proposer une toute nouvelle appli pour la version 4, et donc perdre le système de mise à jour des applications (et pour les applications payantes, refaire payer l'utilisateur)

Accessoirement, on oblige les utilisateurs à passer en version 4 s’ils veulent avoir l’expérience utilisateur la plus moderne, quel que soit la stratégie que l’on utilise. Tout ça parce qu’une API fermée au départ, puis ouverte, puis à nouveau fermée, ne permet pas aux développeurs d’avoir une vision cohérente de leur roadmap.

Au-delà des solutions techniques pour s’adapter à ce problème, qui commencent à émerger ici et là, je serai curieux de savoir ce qu’en pense la communauté francophone, assez discrète sur le sujet à l’heure où j’écris ces lignes.

Pour un plongeon direct dans ce problème vu par un développeur qui suit cela heures après heures, voir @drahtwerk.