Cette note de synthèse est le fruit de 6 jours de développement d’une petite application iOS et Android avec Xamarin Studio sous Mac OS X.
Les technologies mobiles évoluent vite. Aussi les fonctionnalités décrites ou bugs recensés dans cet article sont amenés à devenir obsolètes à court terme.
Un mot sur Mono et Xamarin
Mono est une implémentation open-source de la Common Language Infrastructure (CLI). C’est une alternative à la plateforme .NET de Microsoft. L’idée : pouvoir coder des applications multiplateforme (Windows, Mac, Linux) en C# en utilisant les API et classes existantes de la Base Class Library (BCL) de .NET.
Mono a été créée en 2003 par Miguel De Icaza.
La société Xamarin qui s’occupe désormais de développer Mono depuis 2011 a développé l’écosystème et porté ses efforts sur iOS et Android.
Elle a développé deux produits du même nom : Xamarin.Android (anciennement Mono for Android) et Xamarin.iOS (anciennement MonoTouch).
Via son éditeur gratuit Xamarin Studio, un environnement complet est mis à disposition des développeurs pour concevoir les applications. Il est également possible de développer sous Visual Studio.
Les versions gratuites de Xamarin.Android et Xamarin.iOS sont rapidement limitées (taille maximum pour les binaires générés, pas d’intégration Visual Studio). Au delà, l’achat d’une licence est indispensable. Le détail des prix est disponible ici.
Le mode ‘trial’ permet de bénéficier de 30 jours d’évaluation. Cependant les applications générées ne fonctionneront que pendant 24 heures après leur installation.
Les plateformes ciblées
Côté mobile, Xamarin permet de cibler Windows Phone, iOS et Android. Mac, Windows et Google Glass sont aussi de la partie. Bien évidemment, le développement s’effectue en C#.
En sortie de la compilation, nous obtenons un binaire natif pour chaque plateforme cible.
La philosophie de développement
Ici, Xamarin prend le contre-pied des autres technologies multiplateforme.
Le développeur commence par créer une base de code commune. Elle contient notamment la logique métier, le stockage en base de données, les appels réseaux, les éléments d’interface communs.
Ce projet peut être facilement encadré par des tests unitaires car son code est indépendant de tout système spécifique.
Ensuite, un projet est crée par plateforme cible. Il contient l’interface graphique, la navigation et les composants propres à chaque SDK.
Ainsi, on peut tirer parti des spécificités propres à Android ou iOS sans réduire l’expérience utilisateur au plus petit commun dénominateur.
Note
Avec le support des PCL (Portable Class Librairies), Xamarin va un cran plus loin dans la réutilisation de code. Une PCL regroupe une interface commune puis des implémentations propres à chaque plateforme. Par exemple, pour les bases de données SQLite on peut utiliser ISQLitePlatform (interface) dans le code commun puis instancier une SQLitePlatformAndroid ou SQLitePlatformIOS (implémentations) dans chaque projet.
Il est également possible d’ajouter un niveau d’architecture supplémentaire avec des projets de bibliothèques spécifiques à une plateforme.
Les points forts
Les outils
L’éditeur Xamarin Studio est gratuit et disponible sous Mac et Windows. Il est complet et il permet de programmer, tester, générer, profiler et faire les interfaces graphiques. C’est une version améliorée de MonoDevelop.
L’achat d’une license Xamarin autorise également l’intégration complète dans Visual Studio.
Le C#
C# est un langage évolué et depuis janvier 2013, la version 5 est supportée sur toutes les plateformes.
Voici quelques killers-features :
- les requêtes LINQ. Elles permettent d’écrire des requêtes complexes dans un même langage aussi facilement sur des collections que sur des bases de données.
- les mots-clés async et await. Ils permettent d’écrire du code asynchrone de façon lisible. C’est un point fort dans l’écosystème mobile où le thread principal ne doit pas être bloqué. Un exemple d’application : le téléchargement en arrière-plan de miniatures dans une liste ou un slideshow.
- le typage fort ou dynamique
Les plateformes
Xamarin cible les trois acteurs incontournables de l’écosystème mobile avec iOS, Android et Windows Phone.
La réutilisation de code et de bibliothèques
Xamarin permet l’inclusion de packages NuGET, de PCL ainsi que de composants depuis son store. Exemple RestSHARP pour les appels réseaux, SQLite.net & SQLite extensions pour la BDD.
Il est possible d’inclure directement des bibliothèques tierces en Java ou en C en écrivant des bindings. Certaines possèdent déjà leur portage dans les composants Xamarin (les support library Android par exemple).
Le découpage clair des projets
Le découpage en plusieurs projets avec le code commun d’un côté et l’interface / navigation de l’autre favorise la réutilisation du code. Tout au long de la vie du projet, des fonctionnements identiques dans les projets peuvent être identifiés puis factorisés. Cette pratique contribue à améliorer la qualité et la maintenabilité du code produit.
Les SDK recréés à l’identique
Chaque méthode d’un SDK (Android, iOS, Windows Phone) est encapsulée à l’identique en C#. Sur chaque plateforme toutes les fonctionnalités sont conservées.
Un développeur expérimenté en Android ou iOS s’y retrouve très rapidement car il écrit les mêmes noms de fonctions et utilise les mêmes classes.
Le code Java/Android suivant
TextView view = (TextView)this.findViewById(R.id.output_text) ;
se traduit en Xamarin.Android :
TextView view = this.FindViewById (Resource.Id.outputText) ;
Le code Objective-C suivant
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:cellIdentifier] ;
se traduit en Xamarin.iOS :
UITableViewCell cell = tableView.DequeueReusableCell (cellIdentifier) ;
La réutilisation des assets dans le cas d’un portage
Les assets graphiques et fichiers de conception d’interface restent spécifiques à chaque plateforme. C’est un avantage dans le cas d’un portage.
Pour un projet Android on peut réutiliser toutes les ressources du projet existant. Il suffit de copier / coller le dossier res.
En iOS ce sont les mêmes storyboards et .xib que ceux manipulés par XCode. Il faudra toutefois refaire les outlets.
La performance
Les applications produites en Xamarin sont très performantes. Et c’est d’ailleurs le slogan de la société !
Xamarin apps look and feel native because they are native.
Il suffit de programmer une petite appli soi-même ou lancer une application comme Rdio pour s’en rendre compte.
En Android, le code généré est exécuté par la machine virtuelle Mono. Cette dernière est aussi rapide que la machine Dalvik. Quelques articles((Voir les articles http://hexus.net/mobile/news/android/38789-google-android-ported-java-c-blazing/ et http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html)) traitent du sujet mais comme à chaque fois, rien ne vaut un test en conditions réelles.
Pour iOS, Apple empêche toute exécution de machine virtuelle. Aussi le code produit est directement du binaire natif par le biais d’une compilation AOT. Les performances sont naturellement excellentes.
La communauté et le support
La communauté est active. Entre la documentation exhaustive, le forum officiel et Stack Overflow, la majorité des questions trouvent réponse. Ce n’était pas forcément le cas il y a un an.
L’achat d’une licence permet d’avoir un support Xamarin par email.
Les nouveautés
Xamarin est une technologie jeune qui évolue rapidement. A chaque nouvelle version d’un SDK, la version Mono sort rapidement après, en quelques jours à peine.
L’équipe continue de faire évoluer l’IDE en ajoutant de nouvelles fonctionnalités.
Points faibles
L’apprentissage du C#
Un développeur natif Java Android ou Objective-C doit apprendre le C# pour utiliser Xamarin. Heureusement la courbe d’apprentissage est rapide. J’ai pu le constater ;)
La syntaxe C# est proche de Java sur de nombreux aspects.
L’achat des licences
Comme tout produit commercialisé, l’achat des licences doit être pris en compte.
Il y a d’abord la licence Xamarin qui est par plateforme et par poste de travail. Elle est utilisable à vie, mais bloque les mises à jour dès qu’elle est expirée. Le détail sur https://store.xamarin.com/.
Enfin, si le ou les programmeurs souhaitent utiliser Visual Studio, ce dernier est payant.
La nécessité de connaître les SDKs de chaque plateforme
Un développeur Android ou iOS s’y retrouve facilement dans les SDKs mis à disposition. Il conçoit ses écrans et sa navigation comme il a l’habitude de faire.
En revanche, un développeur sans expérience du mobile doit apprendre les subtilités propres à chaque plateforme cible.
Le temps pour écrire l’UI et la navigation
Lors de la conception d’une application mobile, le temps nécessaire à écrire l’UI et la navigation est important. D’ailleurs, beaucoup de retours utilisateurs concernent cette partie. Avec Xamarin, on a un projet par technologie. Il faut donc plus de temps pour concevoir cette partie. Sans outil spécifique, le temps de développement de la couche présentation est alors aussi élevé qu’en natif.
Depuis fin mai 2014, Xamarin.Forms a fait son apparition. Il s’agit d’une bibliothèque de composants graphiques multiplateforme. Plus de détails sur http://xamarin.com/forms.
Cette approche peut changer radicalement l’approche et le temps passé à la conception des UIs.
Un IDE capricieux !
L’IDE Xamarin studio comporte quelques bugs notamment lors de l’édition des storyboards. J’ai dû plusieurs fois redémarrer le logiciel pour que tout rentre dans l’ordre. Je conseille pour l’instant de passer par XCode pour l’UI iOS.
Côté Android, l’écriture des layouts est fastidieuse car pas de complétion…
Un maillon de plus dans la chaîne
Cette remarque est valable pour toute technologie cross-plateforme. Xamarin est une étape supplémentaire dans la conception d’application. Aussi tout bug sur cette technologie complexifie l’ensemble.
Mon impression
Chaque projet est différent. Tant par le public visé que sur les aspects techniques, métier, graphiques ou ergonomiques.
Xamarin est une technologie jeune qui fonctionne et qui fonctionne bien. Elle vous apporte tout l’écosystème .NET et le C# est un langage robuste et éprouvé. Sa courbe d’apprentissage est rapide.
J’ai pu en quelques jours créer un projet multiplateforme avec du code commun contenant webservices, base de données, règles métiers. Les bibliothèques existantes et la facilité d’écriture du C# permettent d’écrire un code allégé pour des parties habituellement complexes.
Et c’est là le point fort de Xamarin : capitaliser sur le métier, le code sensible.
En connaissant les SDKs de Google et d’Apple, l’écriture de l’UI et de la navigation est facilitée : toutes les fonctions qu’on connaît déjà ont leur équivalent. Il faut cependant réécrire un projet par système d’exploitation mobile visé.
On privilégiera Xamarin sur des projets prévus pour au moins deux systèmes d’exploitation et pour lesquels le métier est complexe et se doit d’être solide. Sur ces projets, la réutilisation de code et la capitalisation seront indéniables.
JRolandros
29 décembre 2014
très bonne analyse, elle est claire, concise, précise et bien organisée et avec une logique très simple.
merci pour ces informations !
Wabema
16 janvier 2015
Aperçu simple, clair et concis. Paragraphes très bien structurés.
Ca encourage à aborder le développement mobile
Bravo
Nico
10 mars 2015
Très bel article félicitation je tiens juste à rajouter une petite remarque au niveau des messages d’erreurs générés qui ne sont pas toujours explicites, notamment quand l’erreur provient de la couche présentation.
DPA
2 septembre 2015
Merci infiniment Benjamin. Voici un article clair, et en français. On perçoit de plus, que l’auteur sait bien de quoi il parle.
Je suis encouragé à attaquer le développement avec Xamarin.