Xamarin Natif ou Xamarin.Forms ? [OLD]

Au moment d'entamer le développement d’une application cross-platform avec Xamarin, la première question que l'on se pose est toujours la suivante : 

Faut-il choisir Xamarin.Forms ou Xamarin Natif ?

Pour beaucoup d’entreprises, la réponse semble évidente après quelques recherches sur le web nous informant que Xamarin.Forms propose un partage de code allant jusqu'à 100%.

Cependant la réalité est en général très différente, et le choix technique d'utiliser une forme ou une autre de Xamarin ne dépend pas vraiment de cette publicité annoncée par Xamarin/Microsoft. Un ensemble de critères et de conditions sont à connaître pour développer son projet avec la bonne technologie.

Il est d'abord important de savoir s’il s’agit d’une application pour le grand public. Une application de ce genre devra plutôt viser du Xamarin Natif pour éviter différents écueils qui pourraient survenir lors du développement cross-platform. Lors du développement d’une application de type Business to Business, l’emploi de Xamarin.Forms peut-être envisagé ici mais soumis à quelques conditions plus techniques ci-après détaillées. 

En second nous abordons le sujet qui porte sur la prédisposition de l’application à utiliser des fonctionnalités natives telles que l’appareil photo ou le GPS. Ce genre de fonctionnalité peut généralement nécessiter un développement plus important sur Xamarin.Forms si aucune solution tierce n’existe, il faut donc se renseigner sur les existants avant le début du projet. Cela peut également réduire l’expérience utilisateur suivant son implémentation et au pire des cas rencontrer des problèmes insolubles sur l’une des deux plateformes. Un exemple concret de ces limitations : avec deux téléphones, l’un Android, l’autre iOS, ils pourront tous les deux récupérer la liste des réseaux wifi à portée mais seul l’appareil Android pourra se connecter automatiquement à un réseau sans action de l’utilisateur. Sur une petite application comprenant seulement une ou deux fonctionnalités natives, cela ne posera pas forcément de difficultés mais sur un projet plus imposant, cela ne donnera pas quelque chose de facilement exploitable et une approche native sera davantage conseillée pour adapter le projet au cas par cas plutôt que de faire tout en même temps et perdre du temps sur ce qui n’est pas possible de réaliser.

Ensuite il faudra savoir si l’on désire avoir un design très similaire voire identique sur chaque plateforme. Contrairement aux pensées communes, il est beaucoup plus compliqué de faire un design similaire en Xamarin.Forms, cela inclura l’écriture de beaucoup de code lié au design et ceci sans utiliser les storyboards sur iOS ou les xml/axml sur android. Le rendu final est d’ailleurs différent sur chaque plateforme et il faudra rajouter des features comme celle de type "OnPlatform" pour forcer une application à avoir des contrôles aux mêmes endroits ou à la même taille. Il existe d'ailleurs de nombreuses techniques qui permettent de faire cela. On retrouve parmi elles les renderers, les effects et de nombreux autres qui agiront à des endroits différents du code ou du design pour permettre à celui de se transformer au bon moment, lors de la compilation, de l'exécution et sur certaines conditions. Sur ce genre de cas, cela ne servira donc à rien de choisir le développement sur Xamarin.Forms car tout sera à redévelopper.

Design de l'application "Flaty's" en Xamarin.Forms sur Windows Phone / iOS / Android

Enfin si votre application contient beaucoup de visuels spécifiques à l’application, on se retrouvera comme dans le précédent cas à redévelopper chaque contrôle et chaque design dans du code spécifique à chacune des plateformes sans le supports des designers natifs.

En somme, dans un projet qui dispose d'une très forte dépendance au design, dont le marché réside dans la masse d'utilisateur public ou qui doit s'appuyer sur de nombreuses fonctionnalités native, une application doit éviter l’utilisation de Xamarin.Forms. Pour les autres cas, celle-ci peut alors être envisagée mais là encore cela dépendra du projet et de l’équipe. Un gros projet se tournera ainsi naturellement vers du natif. Par ailleurs, une équipe inexpérimentée dans le développement mobile qui souhaiterai ne pas faire de développement Xamarin natif sera obligée d’apprendre iOS, Android et Xamarin.Forms pour espérer produire quelque chose de viable, de plus, la formation d’une telle équipe sera très couteuse au projet.

Les projets sont de bons exemples de choix. Sur trois projets, nous avons utilisé plusieurs manières de développer.

Le premier projet s’adresse au grand public, avec des contrôles créés avec les outils natifs (ObjectiveC/Java) et intégrés sous la forme d’un Framework. Notre application fonctionne en s’appuyant sur ce dernier. De plus, le design est toujours identique sur chaque plateforme tout en réalisant des livrables sur les deux en même temps. Avec autant de contraintes, le choix d'utiliser un développement Xamarin Natif a donc été largement adopté par l’équipe et l’application a pu ainsi être développée avec cette méthode. 

Dans un deuxième cas, un client a souhaité développer un projet se connectant à une caméra externe. Les contraintes de design n’existaient pas, le résultat devait être livré très rapidement par le développeur seul en charge du projet. Initialement, l’application devait pouvoir être déployée sur un Android et un iPhone, mais pas pour le grand public. En tant que POC (proof of concept), Xamarin.Forms s’est trouvé très pratique pour le développement du projet, et ce fut d’ailleurs un succès lors de sa livraison puisque celui-ci a pu délivrer tout ce qui était attendu. Le design lui-même a pu évoluer lors d’une reprise du projet. Et le résultat attendu n’étant pas d’une trop grande précision, l’avantage de la couche graphique partagée s’est encore une fois trouvé appréciable.

Le dernier projet que je peux citer est le cas d’une entreprise qui a souhaité créer une application pour ses clients. Tout d’abord, cette entreprise a souhaité investir dans un développement iOS mais avec une promesse de développer l’application Android par la suite. Dans cette optique, Xamarin représentait un cas avantageux pour gagner du temps sur le développement tout en gardant la même équipe projet lors de la conception du second produit. Cela permet également de mutualiser les tests unitaires de l'application sur toute la partie de code partagé, et ainsi obtenir à cet endroit une couverture du code supérieur à 85%.

Initialement, seul le design iOS était prévu, mais la pratique prouve que pour fidéliser ses utilisateurs, un design et une expérience se doivent d’être similaires pour éviter des déceptions lors d’un changement de smartphone. L'identité de la marque est ainsi toujours préservé en restant cohérent quelquesoit le support utilisé qu'il s'agisse d'un site web ou d'autre chose. Par ailleurs, l'application demandait quelques forts usages natifs que tous les téléphones n’avaient pas tel que le TouchID que ne dispose que les derniers iPhone et quelques Android récent qui disposent eux même d'une variante tout aussi efficace. Au final, les directives du projet ont amené le leader technique à imposer le choix de Xamarin natif pour rendre le développement de l’application plus simple et plus efficace. 

Sur tous les projets que vous pourriez engager, la prise en compte des besoins de l'application, de ses critères en terme d'ergonomie, de design, de la proportion de code que l'on souhaite partager, des tests que l'on souhaite mettre en place etc... est indispensable.

Chacun de ces critères vont permettre de décider quelle technologie utiliser mais ce ne seront pas les seules conditions. L'équipe et sa composition compte aussi beaucoup. En effet, si vous donnez votre projet à une équipe contenant des membres quelques membres expérimentés en mobilité, le choix de Xamarin.Forms reste un choix viable.

Dans le cas contraire, il faudra penser qu’un développeur devra être formé au développement iOS, Android et Xamarin.Forms. Cette phase d’apprentissage est longue, et nombreux sont les projets qui peuvent échouer par sa faute. Cependant dans une équipe avec viable, les bons ingénieurs pourront former les autres plus rapidement.

Pratiquer un développement natif dans un premier temps pourra permettre à un développeur de se former petit à petit sur chaque plateforme, et par la suite pourquoi pas, s’autoriser à développer du Xamarin.Forms, si bien sûr le projet le permet. C’est d’ailleurs souvent le cas de POCs qui peuvent servir à éprouver la technologie et connaître les limites et les possibilités. Quelques projets Business to Business se tourneront également vers cette approche, le design n'étant bien souvent pas une priorité, préférant se concentrer sur les fonctionnalités du produit et sur le temps de développement que cela peut faire gagner.