Xamarin : un développement unique pour toutes les plateformes, vraiment ?

De Lionel Dangelo dans Technique

1 nov 2016

Présente depuis plusieurs années sur le marché des solutions de développement cross-plaform mobiles, Xamarin fait beaucoup parler, d’une part parce qu’elle permet à partir d’un seul et unique langage de programmation de générer des applications pour les principaux systèmes d’exploitation mobiles, mais surtout parce qu’elle compile ces dernières en natif, synonyme de performance.

Xamarin est-elle alors la solution cross-platform à adopter absolument et qui détrône toutes les autres ? Cette solution permet-elle vraiment d’écrire une seule application et de la déployer sur toutes les plateformes ?

Avant de pouvoir répondre à ces questions, voyons ce que nous propose la plateforme.

Xamarin, c’est quoi ?

Xamarin est un outil de développement cross-platform qui permet de générer des versions natives iOS, Android et Windows d’une même application en utilisant un seul langage de programmation (C# ou F#). La société qui développe cet outil, appelée elle aussi Xamarin, a été rachetée par Microsoft en 2016. Xamarin offre son propre IDE de développement sur Mac et PC, mais une extension est disponible sur Visual Studio.

Le concept de Xamarin se rapproche d’une solution telle que Appcelerator Titanium qui permet de générer des applications natives contrairement à Phonegap/Cordova qui encapsule au sein d’un conteneur natif des technologies HTML/JS.

 

Un seul développement, 3 applications natives ?

La principale fonctionnalité mise en avant par Xamarin est donc de pouvoir développer avec un seul langage, tout en mutualisant un maximum de code (75% à 100% d’après leur présentation) puis de générer des livrables natifs.

Mais qu’en est-il réellement ? Il faut tout d’abord présenter ce que l’outil Xamarin permet de mutualiser en matière de développement.

Le concept de base met en avant un coeur (couche métier et accès aux données) mutualisé. En revanche, les interfaces graphiques sont spécifiques et doivent être développées pour chaque plateforme.

 

A ce stade, nous sommes donc loin d’un développement purement cross-platform qui prône le 100% de code identique, car même si les couches métier et accès à la base de données peuvent être mutualisées, il restera à développer l’interface pour chaque OS, travail qui selon les applications peut s’avérer être la partie la plus chronophage.

Xamarin justifie d’ailleurs cela dans sa présentation, en appuyant sur le fait qu’il est utile de pouvoir se rapprocher des interfaces natives de chaque plateformes tout en mutualisant le reste :

“The phrase “write-once, run everywhere” is often used to extol the virtues of a single codebase that runs unmodified on multiple platforms. While it has the benefit of code re-use, that approach often leads to applications that have a lowest-common-denominator feature-set and a generic-looking user interface that does not fit nicely into any of the target platforms.
Xamarin is not just a “write-once, run everywhere” platform, because one of its strengths is the ability to implement native user interfaces specifically for each platform. However, with thoughtful design it’s still possible to share most of the non-user interface code and get the best of both worlds: write your data storage and business logic code once, and present native UIs on each platform.”
 
 

Comment le code est-il mutualisé ?

Il existe deux moyens pour partager un même code aux différentes plateformes : les Shared projects et les PCL (Portable Class Library). A noter que même à l’intérieur de ce code mutualisé, des subtilités peuvent exister, nécessitant des conditions et différentes implémentations selon les OS cibles.

  • Shared Asset Projects

Un shared project est un projet dans lequel il est possible de mutualiser du code, mais aussi d’y injecter des spécificités propres à chaque plateforme cible. Concrètement, dans un shared project, chaque fichier est compilé pour chaque plateforme cible. Le code spécifique se fait par des directives de compilation (#if).

 

  • Portable Class Libraries (PCL)

Contrairement au shared project, on ne peut pas rajouter de code spécifique dans une PCL. Cette dernière étant compilée indépendamment du projet principal, le compilateur n’a aucun moyen de connaitre la plateforme cible. Les fonctionnalités spécifiques à une plateforme sont mises en place par un système d’interfaces et d’injection de dépendances, contrairement aux directives de compilations #if des shared projects.

 

 

 

Les interfaces graphiques ne sont par défaut pas mutualisées. L’outil permet pour chaque plateforme et selon le projet cible (Xamarin.iOS, Xamarin.Android) de générer l’ensemble des contrôles utilisateurs, en reprenant le principe de Xcode et des storyboard (ou XIB) pour la plateforme iOS, le principe des fichiers XML pour Android en implémentant un format AXML, et le principe des fichiers XAML pour Windows.

 

 

Et si c’est natif, c’est très performant ?

Xamarin génère des livrables natifs, donc en théorie très performants. Est-ce vraiment le cas par rapport à une vraie application native ? Pour la cible iOS, le compilateur Xamarin produit directement du langage assembleur ARM. Pour la cible Android, le compilateur produit un langage intermédiaire (IL), qui est retraduit à la volée quand l’application tourne. Pour Windows, la question ne se pose pas vraiment puisqu’on est déjà en langage natif.

Le résultat assure normalement de bonnes performances. Mais dans certains cas, une vraie application native sera toujours plus performante, puisque le code généré par Xamarin, bien que compilé nativement, peut ne pas être optimisé ou traduit de la meilleure des manières, ce qui engendrera des lenteurs plus ou moins perceptibles par les utilisateurs. Cela dépendra aussi de l’optimisation du code qui sera faite et de la mise en place ou non des subtilités que peut offrir Xamarin pour gérer au mieux chaque plateforme.

C’est d’ailleurs pour cela qu’un développeur connaissant les langages et frameworks natifs aura plus de facilité à appréhender Xamarin, et saura quoi optimiser en fonction des cibles.

Voici par exemple quelques tests de performance : http://amellsoftware.com/2016/07/28/android-performance-java-vs-xamarin-vs-xamarin-forms/

 

Et si je ne veux développer qu’une seule fois les interfaces pour toutes les plateformes ?

Comme nous l’avons vu précédemment, nous n’avons pas tout à fait un code unique qui est exporté sur différentes plateformes, mais plutôt un coeur d’application mutualisé et chaque interface utilisateur re-développée, ce qui peut être très coûteux.

En effet, sur une application ayant très peu de code métier mais beaucoup d’interfaces, l’intérêt  est clairement réduit par rapport à développer ces projets nativement, ou d’utiliser d’autres solutions telles que Phonegap/Cordova, qui mutualisent beaucoup plus de choses au final (même si les applications ne sont pas vraiment natives à la sortie).

Pour éviter de devoir re-développer chaque interface, Xamarin a mis en place une surcouche nommée Xamarin.Forms qui permet à partir du langage XAML de produire des interfaces universelles compatibles sur tous les mobiles, en ne développant qu’une seule fois de la même manière pour toutes les cibles. Xamarin.Forms va même plus loin en prenant, par défaut, le look and feel de chaque plateforme cible. Ainsi une liste développée avec Xamarin.Forms aura un look différent sur iOS, Android et Windows, se rapprochant des ui natives.

 

Mais pourquoi ne pas se contenter de Xamarin.Forms ?

Nous pouvons donc être tentés d’abandonner les solutions Xamarin.iOS et Xamarin.Android où il faut multiplier les développements d’interfaces. En effet, Xamarin.Forms a l’air parfait sur le papier car c’est cette brique qui permettrait vraiment de se rapprocher d’un développement purement cross-platform, avec un code unique à la fois des couches métier et des couches graphiques. Mais il faut bien comprendre que la surcouche Xamarin.Forms, aussi pratique soit-elle, présente plusieurs inconvénients non négligeables.

Tout d’abord, tous les contrôles de chaque OS ne sont pas forcément présents, il faut donc passer du temps à les adapter ou à les développer. Ensuite, chaque personnalisation ou écart par rapport au rendu initial de Xamarin.Forms demandera un travail conséquent, voir très complexe selon les cas de figure. Enfin, Xamarin.Forms rajoute une couche qui peut emmener des lenteurs à l’application.

Beaucoup d’utilisateurs et même des personnes de la Team Xamarin remontent qu’il est préférable de se contenter de Xamarin.Forms pour démonstrations d’applications ou des applications très basiques sans personnalisation particulière, d’autant plus que beaucoup d’entre eux rencontrent des bugs à chaque nouvelle version de la plateforme. A noter que nous avons nous aussi rencontré ces problèmes.

Exemple de thread traitant de ce sujet : https://forums.xamarin.com/discussion/62525/xamarin-forms-vs-xamarin-android-xamarin-ios-which-one-is-suitable-for-my-project

 

Conclusion

Nous avons donc vu que tout ne pouvait pas forcément être mutualisé avec Xamarin et qu’il ne fallait pas voir cette solution comme simplement “un code unique pour trois plateformes”. Avant d’utiliser Xamarin, il faudra aussi choisir une stratégie d’implémentation d’interfaces et il est donc important de se poser les bonnes questions, à savoir :

- Sur combien de plateformes mon application doit-elle être disponible ?

- Quel niveau de performance et de réactivité est attendu ?

- Pourquoi je veux utiliser Xamarin : pour palier à un manque de connaissance de développement sur une autre plateforme ? ou pour bénéficier d’un maximum de code mutualisé et gérer des livrables pour plusieurs plateformes ?

- Mon application doit-elle être personnalisée graphiquement ? Est-elle destinée au grand public ou à une entreprise ? Puis-je me permettre d’utiliser Xamarin.Forms avec les avantages mais aussi inconvénients que cela apporte ?

- Et si ma couche métier ne représente que 10% de mon application et que 90% est de l’affichage, y’a-t-il un intérêt ? Si je choisis de mutualiser seulement ma couche métier, n’ai-je pas donc intérêt à faire 3 développements natifs plutôt qu’à re-développer ma couche graphique 3 fois ?

- Ai-je besoin de librairies natives qui ne seront peut-être pas disponibles ou facilement intégrables dans mon projet Xamarin ?

- La solution Xamarin est-elle assez pérenne par rapport à la durée de vie de mon application ?

Les réponses à ces questions vous convaincront peut-être d’utiliser Xamarin pour votre projet, ou vous pousseront au contraire à développer directement en natif. La part de code que vous pourrez mutualiser ou non selon votre typologie de projet pourrait peut-être même vous faire envisager l’utilisation d’un autre framework cross-platform !

 

Commentaire

6 × = six

iMDEO recrute !

REJOIGNEZ-NOUS

A la recherche de nouveaux talents (développeurs web et mobile, chefs de projet,...)

Voir les annonces