Xamarin et ses déclinaisons Android, iOS et Xamarin.Forms est-ce du “vrai” natif ou un bricolage plus ou moins savant ?
Natif ou pas ?
On lit et on entend tout et souvent n’importe quoi, sur tous les sujets d’ailleurs et pas seulement sur celui-ci ! Alors comment se faire une idée dans ce flot de désinformation, d’approximations, de novlangue, voire de pensée unique et d’auto-censure ?
Dot.Blog n’est qu’un bloc technique et je ne me lancerai pas dans un long discours philosophique sur ce que doit être la recherche de la Vérité, le contrôle des sources, le recoupement de l’information et encore moins sur le terrain brulant de la manipulation des masses par la politique et les médias, d’autres blogs traitent ces sujets. Mon truc à moi ici c’est la technique.
Mais tout de même, voici un bel exemple de ce grand méli-mélo des idées balancées sans aucun contrôle. Et comme nous recevons trop de ces informations nous finissons par ne plus rien filtrer. En bout de course : une pensée nourrie d’approximations, de contre-vérités, d’intox et parfois de quelques vraies infos. Difficile ensuite de raisonner clairement quand il faudrait déjà une bonne heure de réflexion personnelle avant d’ouvrir sa bouche pour faire d’abord le ménage dans tout ce garbage qui encombre nos neurones et enfin formuler un avis censé et véritablement personnel.
Dans notre petit monde de la technique les mêmes processus de désinformation sont à l’œuvre. Leurs conséquences sont aussi malsaines qu’ailleurs même si elles sont moins graves que lorsqu’il s’agit de gérer un pays ou de choisir un prochain président. Restons humbles, un programme mal écrit, une langage mal choisi, une plateforme mal sélectionnée, cela ne changera pas la face du monde.
Mais tout de même… Par exemple ne pas adopter Xamarin parce qu’on “pense” que ce n’est pas du “vrai” natif, c’est malgré tout s’interdire d’utiliser la solution la plus intelligente du moment, et c’est au minimum bien dommage !
Alors natif ou pas ?
Le mieux est de comparer à ce qui l’est de façon pure et sans discussion possible, le “natif-natif” c’est à dire un développement utilisant les langages de la plateforme ainsi que son propre tooling.
Le Natif Pur
La natif pur c’est par exemple utiliser Swift sous XCode sur Mac pour développer une App destinée à iOS. Utiliser Android Studio et son langage Java avec tout le SDK Android revient au même mais comme il faut utiliser un Mac ou un PC à défaut de machines de bureau Google, on quitte déjà le “pur très pur” du monde bien verrouillé d’Apple. Restons sur l’exemple Apple donc. Du natif absolument pur garanti sans aucun ADN étranger dans sa lignée.
Un constat qu’il faut d’ailleurs éviter à tout prix (celui d’un Mac Pro ?) de transposer au monde réel et à l’actualité sinon on classerait Apple très, très, à droite, à l’extrême ! D’autant que la traduction de “native” en français c’est aussi “indigène”. Pourtant le mythe du produit de souche pure non “pollué” par des “apports extérieur” tout autant qu’il s’interdit tout rapprochement avec “les autres” fait pourtant bien parti intégrante de la stratégie Apple. Il y aurait beaucoup à dire sur les fantasmes que véhiculent cette informatique de “race pure” … Mais pas de politique ni de philosophie j’ai dit !
Bref si vous prenez Swift ou Objective-C sous XCode sur un Mac pour créer une appli iOS, personne ne viendra discutailler si c’est natif ou pas, c’est même peut-être le seul cas au monde où la chose est absolument impossible à contester. C’est la fermeture du monde Apple sur lui-même qui veut ça, by design.
Si parallèlement vous désirez faire une version Android la plus native possible, vous la programmerez en Java sous Android Studio ou Eclipse.
Au bout du compte vous obtiendrez deux applications parfaitement natives sans doute possible.
Mais aussi deux codes totalement différents. Java et Swift ou Objective-C ne permettent pas d’écrire un code commun. Encore moins les approches natives pour coder les UI de ces environnements.
Le prix à payer est élevé puisqu’il vous faudra maintenir deux équipes de spécialistes, deux codes fonctionnels, deux codes d’UI, acheter des contrôles spécifiques, etc.
Et je ne vous dis pas si en plus vous désirez produire la même application pour PC et Surface tablette ou le prochain Surface phone !
Mais c’est natif, c’est sûr.
Cela donne une bonne base pour réfléchir au caractère natif de Xamarin. On sait maintenant ce qu’est une vraie application native à 100%. Sans un point fixe de référence on risque de dire n’importe quoi.
Xamarin
Xamarin est la seule autre approche pour créer de vraies applications natives, sans avoir à utiliser les EDI ou les langages des plateformes.
Originellement il s’agit du framework .NET dans sa déclinaison “Mono” elle-même adaptée à Android (MonoDroid) et iOS (MonoTouch). Les Xamarin.Forms ne sont qu’une couche de traduction de l’UI vers les UI natives et exploitent Xamarin.Droid et Xamarin.iOS (les nouveaux noms de MonoDroid et MonoTouch).
Mais j’affirme, or il faut prouver…
Xamarin peut se diviser en deux parties dont la première est une collection de “one-to-one bindings” pour les OS cibles (Android, iOS, Mac OSX).
Mais qu’est-ce que c’est que ces “liaisons 1 à 1” ?
One-to-one bindings
Il faut bien s’imaginer que Xamarin ne s’est pas amusé à retro-analyser tous les OS pour les reproduire… Ils ont tout simplement (mais quel travail !) exposé les API natives au langage C#.
Sous Xamarin.Forms il est assez rare d’y accéder directement (bien que cela soit possible et même souhaitable parfois) puisque c’est tout leur intérêt, masquer les nuances par une surcouche.
Mais en Xamarin de base (Xamarin.Droid ou Xamarin.iOS sur lesquels s’appuient les XForms) bien qu’en C# on travaille directement avec les API natives grâce à ces “liaisons 1 à 1”. Et lorsqu’on appelle une API native depuis C# on appelle exactement la même API que depuis un environnement de développement natif.
Il est essentiel de bien comprendre que ce premier volet de Xamarin donne accès aux mêmes API, aux même librairies natives qu’un code produit en utilisant Swift, Objective-C ou Android Studio.
Techniquement tout ce qu’on peut faire en natif avec les environnements natifs Android et iOS peut être réalisé avec Xamarin en C# sans aucune limitation.
Les “one-to-one bindings” couvrent 100% des API publiques que Apple ou Google exposent aux développeurs utilisant leur environnements natifs pour développer.
Pour être encore plus clair : il est possible, même si cela est fastidieux, de reprendre une application native Objective-C Apple ou Java Android et de remplacer la syntaxe C# par C ou Java tout en gardant les mêmes variables, les mêmes appels aux librairies, etc. Vous obtiendrez au final exactement la même application ayant les mêmes performances, la même UI, tout à l’identique.
D’ailleurs si on s’en tient à cette premier partie qui constitue Xamarin on pourrait même dire que Xamarin n’est pas cross-plateforme mais “multi-environnement” car le code pour Android ou iOS n’est pas du tout partageable puisqu’ils sont natifs et utilisent les API natives !
Et c’est vrai !
En tout cas partiellement.
Car il y a la seconde partie de Xamarin, l’autre facette qu’il faut aborder : Mono et C#.
Mono et C#
Le choix d’avoir utiliser C# et non Java par exemple n’est pas anodin pour nous qui évoluons dans le monde Microsoft. Il est lié à l’histoire même de Xamarin qui repose sur Mono.
Mono c’est une implémentation de .NET pour Linux, Mac, Android et iOS qui se fonde sur les spécifications libres et ouvertes de .NET et de C#.
L’avantage de posséder une couche Mono dans Xamarin c’est de pouvoir réutiliser le savoir-faire du développeur Microsoft. Même framework, même langage (C# ou même F#).
Mais on le comprend bien cette partie là de Xamarin s’appuie sur la première présentée plus haut, donc sur l’ensemble des API natives publiques de chaque plateforme.
Ni simulation ni indirection ni bricolage.
.NET apporte souvent des services de haut niveau qui se placent eux-mêmes au-dessus des API de l’OS, c’est d’ailleurs son intérêt même sous Windows. Ce même intérêt subsiste sous iOS ou Android. .NET est une couche plus intelligente que les API natives brutes de fonderie, sur tous les OS. Cela ne rend pas .NET “non natif” sous Windows par exemple. C’est identique sur les autres OS.
Natif ou pas ?
Xamarin utilise les mêmes API publiques natives de chaque plateforme que les environnements de développement natif.
La couche .NET enrobe les API natives de la même façon sous iOS ou Android qu’elle le fait sous Windows où il ne viendrait à personne l’idée de dire que .NET n’est pas natif…
Les langages proposés par Xamarin ne sont que des conventions pour le développeurs, ils sont bien compilés en binaires de la plateforme cible, comme Objective-C sur Apple et Java sous Android.
Bref, mêmes API, même code binaire… à vous de voir si c’est natif ou pas. Mais personnellement j’ai mon idée sur la chose !
Et les Xamarin.Forms ?
Comme je le disais il ne s’agit que d’une couche qui utilise à l’exécution les contrôles natifs de chaque plateforme.
Il n’y a pas par exemple une classe Button “portable” comme on le voit dans d’autres environnements “cross-plateforme” qui donne une UI identique partout violant d’ailleurs les codes visuels des plateformes au passage. Non. Sous Xamarin.Forms il y a ce qui ressemble à une classe Button mais qui n’est qu’une sorte d’interface voire un proxy vers le vrai Button natif de chaque plateforme et ce quel que soit son nom réel.
Au final c’est bien un bouton iOS qui s’affichera sur iOS ou un bouton Android sur Android (idem sous UWP).
Là encore c’est du natif qui tournera, pas une librairie portable qui a le même aspect partout. Du vrai natif, avec ses différences ce qui d’ailleurs rend le travail de Xamarin encore plus valeureux (jongler avec les dénominateurs communs tout en laissant la totale liberté de personnaliser).
Tout cela est donc natif, par nature.
Les solutions Hybrides
Rien que leur nom fait comprendre qu’elles ne sont pas natives… Mais il faut les évoquer pour comparer Xamarin à tout ce qui se fait dans le monde cross-plateforme d’autant que l’hybride a eu un certain succès. A eu car bien vite les développeurs se sont rendus compte que ces framework réellement réécrits pour être uniques sur toutes les plateformes n’offraient pas les performances du natif.
Il y a bien eu des améliorations comme la “compilation en natif” de solutions hybrides. D’une part il s’agit pour beaucoup de “pseudo compilation” ne produisant pas un vrai code binaire natif, mais même pour ceux qui ont poussé les choses jusque là il existe une barrière infranchissable : le fameux framework unique totalement réécrit.
Au mieux peut-il couvrir peut-être 60% des API natives. Il est donc possible de compiler ce code en vrai natif. Mais au final on obtiendra un produit ne pouvant exploiter que … 60% des API natives.
Par exemple pour faire des animations sous iOS ou Android il faut utiliser absolument les API standard fournies par les OS. Sans un accès à 100% de ces API les solutions hybrides vont proposer des “enrobages” partiels mais pas la totale liberté d’un vrai code natif. Et cela est vrai partout où il faudra accéder à des spécificités propre à chaque plateforme. L’interposition entre les API natives et le code du développeur de ce fameux framework tout-en-un interdit purement et simplement l’accès à 100% des possibilités de chaque OS.
Xamarin le permet, même sous les Xamarin.Forms. Comme Objective-C ou le Java Android.
Les solutions Web
Elles aussi se veulent parfois portables et cross-plateformes “par nature même” puisqu’on passe par un browser et du HTML/JS/CSS.
C’est là que se dirigent souvent les déçus de l’hybride. Forcément quand on manipule JavaScript il semble plus facile de continuer à en faire plutôt que de coder en C ou en C# ou même en vrai Java. Et puis l’argument d’universalité de HTML n’est pas idiot au départ. Au départ seulement.
Il est tout aussi vrai qu’il y a une place bien réelle sur le marché pour des applications Web bien faites et supportant les mobiles. Mais n’appelons pas cela une “application mobile”, encore moins native qui est notre sujet ici. Même si la page peut utiliser l’appareil photo, elle reste une page Web. Ce n’est ni mal ni bien, ce n’est tout simplement pas une application native avec tout ce que cela veut dire.
Conclusion
Il n’y a que deux façons de développer une application native : utiliser de bout en bout toute la chaîne native proposée par l’OS qu’on cible, ou bien utiliser Xamarin.
Le reste ne peut prétendre être natif. Ce n’est ni bien ni mal de ne pas être natif. C’est juste que ce n’est pas natif avec toutes les implications qui vont avec.
Xamarin et plus encore la couche Xamarin.Forms permettent d’écrire des applications natives, en C# et en XAML sous .NET. Un seul code, une seule UI. Autant d’applications natives qu’il y a de cibles dans la solution Visual Studio… Au 100% natif s’ajoute ici l’avantage du cross-plateforme.
Etre native ou pas compte pour une application (performances notamment) mais aussi pour le développeur (accès à 100% des API natives).
Pourquoi s’égarer sur des chemins de traverses quand on peut aller directement au but ?
Xamarin produit des applications natives. Et cela répond à la question que nous nous posions en introduction !
Stay Tuned !