Je commence à m'intéresser à Android et je suis quand même effaré de ce que je découvre. D'abord l'éditeur principal pour faire du soft sur cette plateforme c'est Android Studio, et cette merde arrive à aplatir de souffrance un PC relativement costaud. Raison principale étant ce que cette merde est écrite en Java au lieu d'un langage natif, bref vous vous prenez dans la tronche tous les bagages et porte-bagages du runtime Java, avant même d'avoir écrit une ligne de code.

Deuxio ce qui sert à faire de l'UI est une merde comparé à ce qu'était l'éditeur d'UI dans Visual Studio il y a 25 ans ! Ca il faut le faire. Par exemple, si vous insérez un bouton et que vous double-cliquez dessus, cela ne génerera en rien le squelette de code pour gérer ce qui se passe lors d'un click. Et tout compte fait il y a peut-être une raison à cela, c'est qu'aujourd'hui l'event handling doit passer par un callback en plusieurs couches. Là encore ça me laisse bouche bée. C'est destiné à qui cette horreur ? Comment imaginer que les gens qu'on va mandater pour faire des UI vont faire autre chose que de récupérer des UI existantes sur internet, notamment sur Git Hub ? Inimiginable autrement. Et l'ironie de l'histoire c'est que l'IA générative va mettre ces gens au chomage.

Je continue.

Comme chacun sait, un appareil mobile peut être orienté en portrait ou en paysage, et de plus il y a de grands écrans, typiquement des tablettes. Et même là ce n'est pas clair si on compare la résolution d'écran d'un téléphone récent par rapport à celle d'un téléphone d'il y a 8 ans, et la résolution d'une tablette. Sans surprise, Android Studio encourage la création d'autant d'UI que de combinaisons. Dans n'importe quelle application qui cherche à afficher son UI correctement, il y aura 4 fichiers différents, téléphone/portrait, téléphone/paysage, tablette/portrait, tablette/paysage. Le moindre changement d'UI devra être reporté (et testé) dans 4 fichiers différents ! C'est ultra productif et pas du tout error prone ! Notez l'ironie.

Dernière chose en date, alors que je teste ma première app en réel, je constate que mon UI explose si l'utilisateur ne choisit pas un réglage standard de taille de police. Ce qui est son choix et il faut évidemment le respecter. Android Studio crée des bouts de texte en les dimensionnant par des "sp", scalable pixels, qui est une variante du "dp", device independent pixels. Mais ce "sp" casse tout en réalité car il permet que l'UI soit dimensionnée pour tenir compte de la résolution de l'écran de l'appareil de l'utilisateur. Ce qui est une bonne chose. Mais, pour répondre au souhait de l'utilisateur, les textes affichés sont aussi redimensionnés pour tenir compte à la fois de résolution de l'écran mais aussi du choix de taille de police de l'utilisateur, alors que le concepteur de l'UI ne le prévoit pas en ayant mis "sp". Bref, l'UI explose, le texte se retrouve tronqué, illisible, c'est terminé ! Au cas où ça ne serait pas clair, "dp" c'est spécifier des centimètres pour faire une UI, donc ne pas tenir compte de la taille de l'écran de l'utilisateur. Et d'ailleurs quand vous commencez à utiliser des centimètres, le meilleur pour faire ça c'est un bout de...papier !

La solution, en tout cas une solution c'est d'utiliser "dp" pour spécifier les tailles des polices lors de la conception des UI, c'est-à-dire de ne pas donner la possibilité à l'utilisateur d'imposer la taille des polices. Ainsi la maitrise du rendu de l'UI sur son appareil est conservée. L'UI n'explose pas et ainsi il y a une petite chance que l'utilisateur puisse l'utiliser, bien que ce soit sans la taille de police qu'il souhaite !
Android Studio, par le fait de mettre par défaut des "sp" partout pour les bouts de texte, favorise une mauvaise conception des UI. Ce qui est proposé par défaut compte énormément dans ce que font une majorité de développeurs.

C'est à peine croyable en 2023. Et encore, je m'arrête là car je n'en sais pas plus encore sur ce que je risque de découvrir. Ca fait peur.