Xamarin Forms, MVVMCross et SkiaSharp : la Sainte Trinité du développement d'applications multiplateformes

Parlez de l'établissement d'attentes élevées. La sainte trinité, rien de moins !

La vérité est que le développement d'applications mobiles est coûteux lorsque vous ciblez plusieurs plates-formes, car il n'y a pas de code partagé. Apple vous oblige à coder en Objective-C ou Swift, Android vous oblige à coder en Java et WinPhone vous oblige à développer en .NET, souvent en C#. Ajoutez à cela la pléthore de bibliothèques que chaque plate-forme fournit pour gérer les cartes, les dessins, les images ou le GPS - une quantité énorme de temps et de connaissances est nécessaire pour créer une seule application mobile.

Inutile de dire que la plupart des startups ne peuvent pas se permettre de tripler leurs dépenses, et même les entreprises établies peuvent avoir du mal à justifier le prix d'entrée dans l'espace mobile.

Dans cet article, vous apprendrez comment Xamarin Forms, en combinaison avec MVVMCross et SkiaSharp, peut être un moyen viable de créer des applications mobiles multiplateformes sans compromettre la familiarité, les performances et l'unicité. L'article passera en revue ces trois technologies et comment elles peuvent réduire les coûts de développement en permettant une réutilisation maximale du code sur plusieurs plates-formes mobiles.

Un problème important

La question du développement d'applications mobiles multiplateformes est réelle et, à ce titre, de nombreuses solutions différentes ont émergé au fil des années pour réduire les coûts de développement en partageant le code entre les plateformes. Dans l'industrie du jeu vidéo, par exemple, tous les principaux moteurs de jeu fournissent une solution multiplateforme, même Unreal et Unity ciblant les téléphones mobiles et les tablettes.

Sur le front des applications, il y a eu plusieurs tentatives pour diriger ce marché multiplateforme au fil des ans. Beaucoup ont échoué et ont été perdus dans les abysses, mais quelques-uns survivent encore après plusieurs années. Parmi celles-ci se trouve Xamarin, la seule solution .NET prenant en charge les trois plates-formes mobiles.

Natif ou pas, me voici

Il y a donc une guerre entre différentes solutions et qui dit guerre rime avec propagande !

La guerre se fait surtout sur le front du grand N : être natif ! Vous devez vous méfier du mot car il n'a pas de sens clair. C'est le mot le plus utilisé dans le monde du développement mobile de nos jours et c'est très tendance. La vérité est que personne n'est d'accord sur ce que cela signifie réellement.

Lors de la sélection d'un framework multiplateforme, toutes les options "natives" ne sont pas égales, alors faites attention, vous pourriez comparer des pommes à des oranges. Pour certains, il s'agit du langage de programmation, pour d'autres, il s'agit de pouvoir utiliser les fonctionnalités matérielles, d'autres pensent qu'il s'agit de l'utilisation des API/UI de la plate-forme, et souvent, il s'agit uniquement de ne pas être une application Web.

Il y a des arguments de chaque côté du débat et je ne vais pas creuser plus car c'est inutile. Pourquoi est-ce inutile ? Eh bien, laissez-moi vous dire un fait difficile à avaler : vos utilisateurs finaux s'en fichent !

Oui, vous avez bien lu, seuls vos programmeurs s'en soucient. Votre utilisateur final ne choisira jamais votre application à cause de la technologie sous-jacente : il choisira votre application car elle répond à son problème et offre une bonne expérience.

Ainsi, au lieu de nous battre pour la signification d'un mot, voyons comment Xamarin fournit un moyen efficace de donner à vos utilisateurs ce qui les intéresse.

Le Père, le Fils et le Saint-Esprit

Avant de poursuivre, clarifions simplement les trois éléments qui composent notre solution au problème de développement multiplateforme.

Le père : Xamarin

Comme mentionné précédemment, Xamarin est une solution .NET pour le développement d'applications mobiles et de bureau. Il a été acheté par Microsoft en 2016 mais daté d'il y a environ quatre ans avec le projet Mono. Aujourd'hui, il propose trois solutions : Xamarin.iOS, Xamarin.Android et Xamarin.Mac. Les autres plates-formes gèrent déjà les applications .NET par défaut, étant des solutions Microsoft. En bref, Xamarin offre un lien direct vers les API de plateforme dans .NET. Vous pouvez donc utiliser les fonctionnalités natives d'une application .NET. Il existe également un module d'extension pour Xamarin appelé Forms qui fournit une couche d'abstraction pour l'interface utilisateur.

Le fils : SkiaSharp

SkiaSharp est un wrapper .NET sur la bibliothèque de graphiques vectoriels Skia de Google. Skia est le moteur de rendu natif d'Android, Chrome, ChromeOS et Firefox. Avec SkiaSharp, vous pouvez utiliser la bibliothèque de votre application .NET pour la rendre multiplateforme. Cela signifie que l'ombre nette qui, selon votre concepteur, "rendra votre application tellement meilleure" ne peut être codée qu'une seule fois au lieu d'être répétée pour chaque plate-forme cible. Personnellement, je pense que sa meilleure caractéristique est la possibilité de rendre les graphiques SVG d'une manière qui vous permet d'éviter la duplication des différents facteurs de forme tout en conservant un rendu net et parfait au pixel près.

Le Saint-Esprit : MVVMCross

Pour garder tout bien séparé et faiblement couplé, notre solution sanctifiée s'appuiera sur MVVMCross. Ce framework implémente une infrastructure MVVM (Model-View-ViewModel) pour que tout reste indépendant. Sans devenir trop technique, les applications sont généralement divisées en trois parties :

1. Le modèle : une représentation en mémoire de nos données
2. La vue : notre interface utilisateur, présentant les données et les actions aux utilisateurs
3. Le ViewModel : la couche qui lie notre modèle à notre vue et vice-versa

En génie logiciel, nous nous efforçons toujours de garder la vue séparée du ViewModel afin que la logique de l'application (dans le ViewModel) puisse être réutilisée même si nous modifions la représentation visuelle. MVVMCross nous aide à atteindre cet objectif en gérant les liaisons de données et en fournissant des modèles et des outils pour l'abstraction de plate-forme.

Ce dont les utilisateurs finaux se soucient

Pour récapituler, il existe différentes choses qui différencient les applications réussies des mauvaises. Une application réussie :

1. Résout un problème réel
2. Offre une expérience agréable

Le point numéro 1 n'a évidemment rien à voir avec le cadre que vous choisissez. Alors concentrons-nous sur le point numéro 2. Il y a trois aspects majeurs qui contribuent à l'agrément de votre application :

1. Familiarité
2. Performance
3. Unicité

Familiarité

La familiarité est liée à la facilité d'utilisation et à la rapidité de navigation dans l'application.

En d'autres termes, il s'agit d'utiliser les différents paradigmes d'interface utilisateur de la plate-forme de manière cohérente à l'échelle du système. Par exemple, des éléments simples comme la position des boutons, les actions de contexte de liste ou la navigation contribuent tous à la familiarité de votre application.

La familiarité est le principal point faible des applications Web ou des frameworks basés sur une interface Web. Xamarin Forms, d'autre part, fournit des mappages multiplateformes aux éléments d'interface utilisateur fournis par le fournisseur.

Vos utilisateurs bénéficient ainsi d'une expérience conforme à l'aspect général de la plateforme afin qu'ils se sentent intuitivement à l'aise dans votre application.

Performance

Franchement, mentionner « natif » dans votre propagande marketing ne veut rien dire. Prenez Jasonette comme exemple qui est "natif sur HTTP". L'UI est stockée sur un serveur web… bonjour les allers-retours et les ralentissements, on voit donc que natif ne peut pas forcément être présumé impliquer de meilleures performances !

Donc, avec ce mythe à l'écart, lorsque l'on regarde les références de la vie réelle, Xamarin apparaît comme la solution la plus complète en termes de performances. Xamarin Forms, ne nécessitant pas beaucoup plus de changements de contexte, offre des performances comparables aux applications en langue maternelle.

Ma conclusion est que vos choix d'implémentation sont ce qui peut ralentir votre application plutôt que Xamarin par rapport au langage natif. D'autres options sont nettement désavantagées en termes de performances.

Unicité

La possibilité pour vos concepteurs de créer une application au look unique est également très importante à prendre en compte si vous souhaitez offrir la meilleure expérience utilisateur possible et différencier votre application.

Souvent, l'unicité implique la création de commandes, d'animations ou de gestes personnalisés. Lorsqu'il n'est pas facilement disponible dans Xamarin, vous pouvez utiliser SkiaSharp (un wrapper autour de la bibliothèque de rendu graphique vectoriel Skia de Google) et tirer parti du concept de rendu personnalisé de Xamarin Forms pour vous rapprocher le plus possible du matériel, tout en codant toujours en un seul langue, ce que les autres solutions sont incapables d'offrir.

Ce qui vous tient à cœur en tant qu'entreprise

À ce stade, vous pensez très probablement que le choix du framework est également une décision commerciale. Outre les facteurs hors de la portée de cet article, comme la disponibilité des ressources humaines, Xamarin a beaucoup à offrir, en particulier lorsqu'il est associé à MVVMCross. Je vais développer quatre aspects que vous voudrez considérer dans votre décision :

1. Prix ​​et frais de développement
2. Réutilisation du code
3. Disponibilité des composants
4. Soutien et communauté

Prix ​​et coûts de développement

Éliminons celui-ci. Depuis le début de cette année, Xamarin est gratuit pour les indépendants et les petites entreprises comme les startups (avec Visual Studio Community Edition). Pour les grandes organisations, il est fourni « gratuitement » avec une licence Visual Studio que vous possédez peut-être déjà. Xamarin Forms, MVVMCross et SkiaSharp sont également tous gratuits et open source pour couronner le tout !

Comme je l'ai déjà mentionné, suivre la voie .Net avec Xamarin vous permet de développer vos applications dans un seul langage du début à la fin. La plupart des autres solutions exigent que vos programmeurs connaissent différentes langues. Dans le cas de Cordova, par exemple, vous devez maîtriser non seulement HTML, Javascript, CSS, mais aussi éventuellement Objective-C, Java et/ou C# si vous avez besoin d'accéder à des API de fournisseurs qui n'ont pas de plugin disponible. .

La variété des langages utilisés entraîne plus de changements de contexte et plus d'outils à maîtriser, ce qui réduit l'efficacité. Xamarin, quant à lui, est une solution tout-en-un : à partir de Visual Studio, vous construisez, déployez et déboguez sur toutes les plateformes.

Bien qu'il ne soit pas directement lié à Xamarin, vous bénéficiez également de nombreuses fonctionnalités en C # qui accélèrent le développement en choisissant la solution .Net. À savoir, vous bénéficiez des fonctionnalités exceptionnelles de C# 4.5+, telles que le multithreading facile avec asynchrone/attente, les fermetures et la réflexion, qui ont toutes démontré leur efficacité.

Réutilisation du code

Vous avez probablement pensé à la réutilisation du code et vous considérez très probablement que toutes les solutions sont quelque peu équivalentes à cet égard. Désolé de dire mon pote, mais tu as tort!

Les programmeurs parmi vous se sont peut-être demandé pourquoi diable je proposerais l'utilisation de MVVMCross sur la couche MVVM intégrée à Forms ? Eh bien, voici quelque chose à considérer : créez-vous vraiment uniquement des applications mobiles ?

En isolant la logique de votre application avec MVVMCross et en utilisant l'inversion de contrôle qu'il fournit, vous pouvez réutiliser un maximum de code sur mobile, mais aussi sur Windows et Mac (car Xamarin.Mac est votre ami).

Non seulement cela vous fera économiser de l'argent, mais cela mettra également en avant de bonnes pratiques d'ingénierie qui réduiront vos coûts de maintenance du code.

Disponibilité des composants

Peut-être que vous n'êtes pas comme moi, mais je déteste réinventer la roue. Par conséquent, avoir accès à des composants existants que vous pouvez facilement intégrer dans votre application est crucial pour accélérer votre délai de mise sur le marché et cela réduira souvent vos coûts en même temps.

Choisir Xamarin et MVVMCross vous offre deux options pour choisir des composants existants. Tout d'abord, de plus en plus de composants sont disponibles pour Xamarin avec ou sans Forms. Xamarin a un magasin de composants intégré à Visual Studio où vous pouvez trouver diverses solutions aux problèmes d'application courants et d'autres sociétés vendent directement, alors assurez-vous de rechercher avant de commencer à écrire vos propres composants (ou envisagez de les vendre une fois qu'ils sont créés).

Deuxièmement, vous souhaiterez rechercher des packages Nuget, car il est probable que quelqu'un ait déjà écrit du code pour faire ce dont vous avez besoin. Parmi ces packages, vous trouverez une liste décente de plugins MVVMCross multiplateformes qui résoudront des problèmes courants tels que le courrier électronique, le GPS ou la localisation.

Si vous avez déjà de l'expérience avec C#, vous avez probablement vos composants préférés. Bien sûr, vous ne voulez pas les laisser partir, ils se sentent tellement à l'aise. Rassurez-vous, vous pouvez créer des liaisons C# pour les composants existants, puis les utiliser comme s'ils étaient fournis avec Xamarin, même dans Forms avec un peu d'aide de rendus personnalisés.

En parlant de cela, vous voudrez peut-être jeter un œil au référentiel Github des liaisons Xamarin avant de créer le vôtre.

Assistance et communauté

Enfin, l'accès au support et aux exemples est un facteur très important dans le choix d'un framework. Xamarin existe depuis un certain temps, donc la communauté est d'assez bonne taille aujourd'hui.

La recherche d'informations sur Google donne généralement un bon nombre de réponses (astuce : essayez également vos recherches sur monotouch et monodroid, les ancêtres de Xamarin) et Xamarin propose de nombreux exemples et une excellente documentation sur son site Web.

De plus, étant donné que Xamarin n'est en réalité qu'une liaison sur les API des fournisseurs, la documentation d'Apple et de Google est toujours pertinente et répondra à bon nombre de vos questions. Vous pouvez ensuite créer votre propre service MVVMCross pour extraire les API du fournisseur dans votre code partagé.

Quant à l'avenir de Xamarin, avec son acquisition en mars dernier par Microsoft, je parie qu'il ne va nulle part sauf vers l'avant. Depuis cette vente et le passage à un modèle gratuit, la communauté n'a fait que grandir, le support s'est amélioré et le produit n'a cessé de s'améliorer, peut-être même à un rythme plus rapide !

L'avenir s'annonce radieux pour Xamarin.

Soyons prêts à gronder!

Je suis conscient du fait que j'ouvre peut-être une boîte de Pandore avec cet article. Ne vous méprenez pas, il existe d'autres options qui valent la peine d'être envisagées et je vous invite à le faire, car mes préoccupations ne sont peut-être pas les mêmes que les vôtres.

Gardez à l'esprit que si vous avez un calendrier de six semaines et que quatre mois plus tard, vous n'avez toujours pas d'application prête, vous ne gagnez pas. Cela laisserait deux mois et demi et beaucoup d'argent pour former quelqu'un à l'interne ou pour embaucher quelqu'un de compétent. Insister pour créer une application "native" à ce stade peut être très préjudiciable au sort de votre projet.

Xamarin et ces technologies associées fournissent exactement ce qui intéresse vos utilisateurs et ce dont vous avez besoin. J'espère que cet article vous aidera à prendre une décision éclairée sur le cadre que vous pourrez choisir pour votre prochaine application mobile.