Pour compléter le site web Library, j'ai créé une application mobile. J'ai porté mon choix sur la technologie Xamarin, module officiel de Visual Studio et framework .NET / C# destiné à uniformiser le développement sur Android, iOS et Windows Phone.
Le code applicatif est donc commun, et fait un usage massif de requêtes REST sur le serveur Web. En effet, j'ai codé sur le serveur Web un module PHP qui implémente un WebService RESTful, donc la logique de persistance des données est centralisée sur le serveur Web, et une grande partie du code de ce service est commune avec le site pur web. L'application mobile n'a donc quasiment qu'à s'occuper de l'interface utilisateur et du lien entre cette interface et le WebService.
Bien que j'aie créé le projet de telle sorte que les 3 plateformes puissent être ciblées, je n'ai généré que l'application Android, n'ayant ni iPhone ni Windows Phone sous la main. Mais à priori finaliser les applications pour les deux plateformes restantes ne poserait pas de soucis particulier, tout au plus il faudrait ajuster quelques paramètres d'affichage et des ressources graphiques pour s'adapter au menues différences inhérentes aux plateformes.
Dans le cas de cette application, je ne m'appuie que très peu sur les composants natifs tels que les champs de saisie ou les boutons, qui sont le plus susceptibles de générer des décalages entre les plateformes.
L'essentiel de l'interface est géré par un composant de mise en page (LayoutView) personnalisé, basé sur l'exemple WrapLayout donné par l'équipe de Xamarin dans un tutoriel. Celui-ci calcule la disposition idéale d'une liste d'éléments (de même type en principe) en fonction de leur taille minimum respective et de la taille totale du conteneur.
L'exemple tel quel en est l'affichage de la liste des livres au centre de l'application. Pour les deux éléments en haut et en bas, qui représentent la liste des catégories et des séries, j'ai amélioré ce composant pour qu'il puisse optionnellement faire rentrer deux éléments dans l'espace d'un seul, à chaque fois que c'est possible. Cela permet d'optimiser l'utilisation de l'espace (et donc avoir moins de hauteur au final) sans pour autant perdre le look bien rangé que procure ce composant lorsqu'il aligne tous les éléments sur la taille du plus grand. Je trouve ce compromis très satisfaisant.
Comme ce composant gère parfaitement l'arrangement des éléments dans une zone qui lui est donnée, la seule chose qui restait à faire était d'arbitrer les tailles respectives des 3 listes pour éviter sur les petits écrans qu'aucune des listes ne soit démesurée par rapport aux autres qui seraient alors dans l'obligation de se réduire à peau de chagrin avec des barres de défilement.
J'ai résolu ce problème en rendant plus dynamique le menu des catégories, qui n'affiche que les catégories et sous-catégories les plus pertinentes par rapport à la catégorie actuellement affichée (le parent, les enfants et les frères de la catégorie en cours), sauf dans le cas de la page d'accueil qui affiche tout, n'ayant pas d'autres listes concurrentes. De fait, cette liste de catégories est toujours affichée entière, sans défilement, et a la priorité absolue sur la réservation d'espace.
Ensuite, la liste de livres se voit prioritaire sur la liste des séries, dans la limite d'un seul livre de haut plus quelques lignes, pour que l'on voit au moins une fiche livre dans sa totalité, et qu'on devine toujours la présence d'une autre fiche en haut ou en bas, quand on fait défiler.
La liste des séries peut donc s'étendre vers le haut jusqu'à cette limite d'une fiche (+ qq lignes), et s'il le faut elle est défilable comme la liste des livres (ce que l'on devine aussi en bas, il y a quelques pixels rouge clair de la ligne suivante qui ne sont pas cachés).
Si vous passez en revue les captures d'écran de tablette, vous constaterez que les préoccupations de répartition d'espace ne sont plus les même :). Le composant continue de bien agencer tous les éléments de l'interface, c'est propre.
Je me suis demandé s'il fallait que j'adapte la mise en page pour les très grandes surfaces & hautes résolutions comme c'est le cas ici (13"), afin d'aérer un peu. Mais non, l'essentiel c'est d'avoir le maximum de livres et de séries affichés en même temps, avec toujours la navigation compacte dans les catégories qui certes n'est pas tout le temps directe et oblige de repasser par un parent commun avant de changer de branche.
D'ailleurs, quand on passe la tablette en portrait, l'interface s'ajuste très bien et propose un agencement qui peut s'avérer plus espacé que dans le mode paysage. Difficile de déterminer quelle orientation je préfère, c'est un peu aléatoire, ça dépend du nombre de livres qu'il faut afficher et de la taille des deux listes de navigations. En tout cas, c'est sympa d'avoir le choix, et je ne toucherai probablement à rien pour essayer de customiser l'interface pour différentes form factor - sauf si je croise une "phablette" 8" et m'aperçois que c'est horrible, mais j'ai confiance dans les mécanismes en œuvre (autant ceux de Xamarin, que ceux que j'ai mis en place).

Si je devais conclure sur l'ensemble de l'expérience de développement avec Visual Studio / Xamarin / C# / Custom plateforme cible (ici, Android) , je dirais que j'ai parfois pesté sur des bugs de Visual Studio et la chaîne de compilation, sur des erreurs obscures à l'exécution dont il est parfois difficile de deviner la cause, car celle-ci se cache dans des fichiers de code, ou de ressources XML divers, qui sont passés par plusieurs moulinettes avant de finir en code Java compilé pour Android... Sans parler du temps horrible de compilation (sur mon RiZen 8 cœurs/16 threads, j'ai envie de pleurer) et de déploiement sur l'émulateur ou pire sur un téléphone physique. Ni de l'absence d'outils permettant de prévisualiser l'interface au moment du design. Bref on perd un temps fou pour mettre au point ce qui au final certes ne prends que 50 lignes de XML et un peu de code C#. Mais ce n'est quand même pas mal, et c'est sympa de se dire que s'il faut, on a l'appli pour iPhone et WinPhone à portée de clics (et sans doute quelques embrouilles de dernière minutes, mais bon ça c'est les joies de la technique). Vivement dans 2-3 ans quand tout cela sera à pleine maturité, et qu'on aura un moyen (gratuit) de prototyper l'interface sans passer par la case compilation/déploiement.