Parlez de fixer des 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 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. Il faut beaucoup de temps et de connaissances 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 une multiplateforme application mobile 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

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

Du côté des applications, il y a eu de nombreuses tentatives pour diriger ce marché multiplateforme au fil des ans. Beaucoup ont échoué et se sont perdus dans l'abîme, mais quelques-uns survivent encore après plusieurs années. Parmi ceux-ci, Xamarin, la seule solution .NET offrant une prise en charge pour les trois plates-formes mobiles.

Autochtone ou pas, me voici

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

La guerre se déroule principalement 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 il est très à la mode. La vérité est que personne n'est d'accord sur ce que cela signifie réellement.

Lors de la sélection d'un cadre multiplateforme, toutes les options «natives» ne sont pas égales, alors faites attention, vous comparez peut-être 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 / de l'interface utilisateur de la plate-forme, et souvent il s'agit simplement 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 profondément parce que c’est inutile. Pourquoi est-ce inutile? Eh bien, laissez-moi vous dire un fait difficile à avaler: vos utilisateurs finaux s'en moquent!

quel type d'attaque Web utilise les fonctions get et post d'un formulaire html ?

Oui, vous avez bien lu, seuls vos programmeurs s'en soucient. Votre utilisateur final ne choisira jamais votre application en raison 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 leur tient à cœur.

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

Avant de continuer, clarifions simplement les trois éléments qui composent notre solution au problème du 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. De nos jours, 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 propose 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 que votre concepteur dit «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 des 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 en pixels.

Le Saint-Esprit: MVVMCross

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

1. Le modèle: une représentation 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 séparer la vue 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 la plate-forme.

lequel des éléments suivants ne fait pas partie du plan de conception d'une base de données

Ce qui intéresse les utilisateurs finaux

Pour récapituler, il y a 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. Concentrons-nous donc sur le point numéro 2. Trois aspects principaux contribuent à la convivialité de votre application:

1. Familiarité
2. Performance
3. Unicité

Familiarité

La familiarité se rapporte à la facilité d'utilisation et à trouver rapidement votre chemin 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'apparence générale de la plate-forme afin qu'ils se sentent intuitivement à l'aise dans votre application.

Performance

Franchement, mentionner «natif» dans votre propagande marketing ne signifie rien. Prendre Jasonette à titre d'exemple qui est «natif sur HTTP». L'interface utilisateur est stockée sur un serveur web… bonjour les allers-retours et les ralentissements, on voit donc que le natif ne peut pas forcément être présumé impliquer de meilleures performances!

Donc, avec ce mythe écarté, lorsque l'on regarde les repères de la vie réelle, Xamarin se présente comme la solution la plus complète en termes de performances . Xamarin Forms, ne nécessitant pas beaucoup plus de commutateurs de contexte, offre performances comparables à celles des applications en langue native .

Ma conclusion est que vos choix d'implémentation sont ce qui peut ralentir votre application plutôt que Xamarin par rapport à la langue native. D'autres options sont clairement désavantagées en termes de performances.

Unicité

La possibilité pour vos concepteurs de créer une application d'apparence unique est également très importante à considérer si vous souhaitez offrir la meilleure expérience utilisateur possible et différencier votre application.

Plusieurs fois, 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 de graphiques vectoriels 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 ne peuvent offrir.

Ce que vous aimez en tant qu'entreprise

À ce stade, vous pensez probablement que le choix du cadre est également une décision commerciale. Outre les facteurs qui sortent du cadre 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 prendre en compte 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

Supprimons celui-ci. Depuis plus tôt cette année , Xamarin est gratuit pour les indépendants et les petites entreprises comme les startups (avec Édition communautaire Visual Studio ). 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 route .Net avec Xamarin vous permet de développer vos applications dans une seule langue du début à la fin. La plupart des autres solutions exigent que vos programmeurs connaissent différentes langues. Dans le cas de Cordoue , 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.

Calculateur de taux 1099 vs w2

La variété des langages utilisés entraîne plus de changements de contexte et plus d'outils à maîtriser, ce qui entraîne une diminution de l'efficacité. Xamarin, en revanche, est une solution tout-en-un: à partir de Visual Studio, vous créez, déployez et déboguez sur toutes les plates-formes.

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 le Solution .Net . À savoir, vous bénéficiez des fonctionnalités exceptionnelles de C # 4.5+, telles que le multi-threading facile avec async / await, les fermetures et la réflexion, qui ont toutes été montrées pour améliorer l'efficacité.

Réutilisation du code

Vous avez probablement pensé à la réutilisation du code et vous considérez probablement que toutes les solutions sont quelque peu équivalentes à cet égard. Désolé de dire mec, mais vous vous trompez!

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 une quantité maximale 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 de 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 temps de mise sur le marché et, souvent, cela réduira vos coûts en même temps.

Choisir Xamarin et MVVMCross vous offre deux options pour choisir des composants existants. Premièrement, de plus en plus de composants sont disponibles pour Xamarin avec ou sans formulaires. Xamarin dispose d'un magasin de composants intégré à Visual Studio dans lequel vous pouvez trouver diverses solutions aux problèmes d'applications courants et que d'autres entreprises 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 voudrez rechercher les packages Nuget car il y a de fortes chances 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 l'e-mail, le GPS ou la localisation.

Si vous êtes déjà familiarisé avec C #, vous disposez probablement de 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 si elles étaient fournies avec Xamarin, même dans Forms avec un peu d'aide des moteurs de rendu personnalisés.

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

Support et communauté

Enfin, l'accès au support et aux exemples est un facteur très important dans le choix d'un cadre. Xamarin existe depuis un certain temps, donc la communauté est d'une 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 leur site Web.

De plus, étant donné que Xamarin n'est en réalité qu'une liaison entre 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 en 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 a continué à s'améliorer, peut-être même à un rythme plus rapide!

L'avenir s'annonce prometteur pour Xamarin.

quels sont les principes du design graphique

Soyons prêts à gronder!

Je suis conscient du fait que je peux ouvrir une boîte de vers avec cet article. Ne vous méprenez pas, il existe d’autres options qui méritent 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 bien informé. Insister sur la création d'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 pouvez choisir pour votre prochaine application mobile.

En relation: Meilleures applications Android utilisant MVVM avec une architecture propre