Fermer

avril 3, 2019

Pourquoi Xamarin pour le développement mobile


Bien qu'il existe de nombreuses façons de créer des facteurs de forme mobiles, examinons leur intérêt pour les développeurs qui choisissent la pile technologique Xamarin.

Même après des années de construction pour la téléphonie mobile, les développeurs débattent encore du choix de la pile technologique. . Peut-être qu’il n’ya pas de solution miracle et que la stratégie mobile dépend vraiment de l’application, de l’expertise des développeurs, de la maintenance de la base de codes et de divers autres facteurs. Toutefois, si les développeurs souhaitent écrire .NET, Xamarin a essentiellement démocratisé le développement mobile multiplate-forme avec des outils perfectionnés et des intégrations de services. Pourquoi sommes-nous alors en train de nous deviner?

Il s'avère que le développement mobile ne se fait pas en silos et que toutes les plates-formes technologiques orientées vers les mobiles ont beaucoup évolué. Il est toujours logique de regarder quels autres développements se produisent autour de votre application – la pile choisie se prête-t-elle au partage de code? Les outils du commerce sont-ils accueillants pour les développeurs, quelle que soit leur plate-forme OS? Les piliers sous-jacents de la technologie choisie inspirent-ils confiance?

Examinons de plus près et justifions la pile de technologies Xamarin. Spoiler – vous ne serez pas déçu.

Cet article fait partie d'une longue série sur Chasing Success avec Xamarin Apps – Nous explorons la pile de technologies, les outils et les services Xamarin qui aident les développeurs à réussir. applications mobiles.

Stratégies mobiles

Bien qu'il existe différentes manières de créer des applications mobiles, les catégories suivantes sont présentées:

 MobileStrategy "title =" MobileStrategy "/><p data-recalc-dims= Heureusement, quelle que soit la technologie de pile mobile Les développeurs choisissent un outil sophistiqué et un accès facile aux API de la plate-forme mobile. Discutons toutefois des avantages et des inconvénients de chaque approche:

  • Native : Les applications natives pour iOS, Android et Windows constituent le moyen le plus simple de créer des applications mobiles. Les applications natives fonctionnent au plus près du métal et les développeurs peuvent utiliser des kits de développement logiciel (SDK) / langages / outils spécifiques à la plate-forme, bien que rapides et élégants, mais plutôt coûteux, nécessitant la maintenance de bases de code spécifiques à la plate-forme.

  • Mobile W eb / PWAs : Le Web mobile est souvent la solution la plus avantageuse pour passer de la plate-forme à la téléphonie mobile. Il existe de nombreux cadres permettant aux applications Web de fonctionner correctement sur les navigateurs mobiles. Les applications Web mobiles peuvent devenir extrêmement intelligentes grâce aux applications Web progressives – les applications Web commencent à se comporter comme des citoyens légitimes dans le monde des applications mobiles. Les utilisateurs peuvent épingler des applications Web sur leurs écrans d'accueil, laisser les techniciens de maintenance s'exécuter en arrière-plan et recevoir des notifications push. Il existe de nombreux outils utiles pour la création d'applications Web mobiles et de structures JavaScript JavaScript évoluées pour la création de PWA.

  • Hybrid : Cordova a popularisé l'idée de la création d'applications mobiles multiplates-formes avec technologies Web – HTML , CSS et JS réunis pour créer une application mobile. De telles applications hybrides fonctionnaient dans le shell du navigateur et l'utilisateur ne le remarquerait pas s'il le faisait bien. Alors que les applications hybrides bénéficient de bons outils et de cadres matures comme Ionic et la présence de l'App Store, le sandbox du navigateur entrave un peu leur vitesse d'exécution.

  • JS Native : Ces dernières années ont été témoins de la montée en puissance de la multiplate-forme applications mobiles écrites en JavaScript / Typescript – le problème est de savoir pourquoi passer à l'hybridation quand on peut passer en mode natif avec les mêmes technologies? Les applications JS Native bénéficient d'un accès complet à la plate-forme native et rendent l'interface utilisateur native, le tout à partir d'une base de code unique. Les applications JS Native bénéficient de cadres magnifiques tels que NativeScript NativeScript avec Angular / Intégration de Vue React Native et et de Flutter . .

  • X-Compiled : Si vous préférez écrire du code .NET et utiliser un outil familier tel que Visual Studio, la solution d'applications mobiles compilée de manière croisée est plutôt alléchante. L'astuce consiste à compiler du code de langage .NET de niveau supérieur en bits binaires pour chaque plate-forme mobile, tout en restituant l'interface utilisateur native. Xamarin a largement démocratisé l'espace compilé sur X, avec la plate-forme Uno prêtant un coup de main dernièrement.

Cet article préconise la pile technologique Xamarin, Le but de cette discussion sur la stratégie mobile est que vous n’avez pas toujours besoin de faire Xamarin pour atteindre le mobile multiplate-forme. Si vous êtes investi dans la pile Web et que vous écrivez bien JS / TS, le chemin Web permettant de passer aux facteurs de forme mobiles générera de riches dividendes et se prêtera mieux au partage de code.

Tous les .NETs

Avec la pile technologique Xamarin, il est souvent bénéfique de prendre du recul et de comprendre l’écosystème .NET – à quoi correspond Xamarin? Voici la grande histoire de l'image avec .NET:

 DotNets "title =" DotNets "/></p data-recalc-dims=

Comme les développeurs le savent bien, la pile .NET a beaucoup évolué au cours des deux dernières années. Il y en a plusieurs. NET pour différents types d’applications – à lire comme plusieurs bibliothèques de classes de base (BCL). Les trois plus populaires sont:

  • .NET Framework : C’est le Framework .NET complet qui a été le chouchou de Les développeurs sur la pile Microsoft depuis 17 ans maintenant. .NET Framework fournit un écosystème aussi riche que possible, ainsi que des outils, une assistance communautaire, une extensibilité et une exécution de premier ordre pour l'hébergement de diverses applications .NET. Cependant, le .NET Framework a montré des signes évidents de lourdeur et la nature monolithique du framework invite à la fragilité, ainsi que les maux de tête de la mise à niveau. Ne vous y méprenez pas, le .NET Framework ne meurt pas et reste une partie essentielle de Windows. peut ne pas voir les innovations sérieuses aller de l'avant – les applications existantes continueraient à fonctionner Très bien, mais tout nouveau développement devrait regarder d’avant les autres .NET.

  • .NET Core : Il s’agit du nouveau .NET, construit à partir de zéro pour répondre à certaines des préoccupations de .NET Framework. .NET Core est maigre, modulaire et offre, pour la première fois, une exécution multiplate-forme prenant les applications .NET sur MacOS / Linux. Bien que nouveau, .NET Core a connu des innovations rapides et des fonctionnalités API proches de celles comparables à celles du .NET Framework. La nature légère de .NET Core se prête naturellement à la création d’applications Web hautes performances, tandis que les outils de ligne de commande / multiplate-forme offrent aux développeurs des libertés. Les avantages des environnements d'exécution .NET côte à côte s'étendent sur le bureau avec .NET Core 3, tandis que .NET Core lui-même repousse les limites avec des technologies telles que ML.NET.

  • Mono : Depuis la création de. NET, il y avait un désir de prendre des applications .NET en dehors de Windows. Meet Mono – le port des API .NET vers d'autres plateformes aussi ancien que le .NET Framework lui-même. Mono est le moteur d'exécution de toutes les applications Xamarin et reste un moyen incroyablement polyvalent de prendre en charge .NET sur un nombre croissant de plateformes autres que Windows.

Il n'est pas difficile de voir comment cette variété de .NET dans l'écosystème offre une flexibilité – développeurs choisir le fichier .NET qui convient le mieux à leurs applications. Le fonctionnement de Xamarin sur Mono est une pièce très importante du puzzle de Microsoft – c’est ce qui confère à .NET une portée considérable sur la plate-forme. Avec tous les .NET, il existe très peu de périphériques / plates-formes que les développeurs .NET modernes ne peuvent atteindre.

Mono ou .NET Core

Mono a toujours été une solution naturelle pour l'exécution des applications Xamarin. Les développeurs écrivent du code .NET compilé en code IL (Generic Intermediate Language) générique, puis le pont / machine virtuelle Mono convertit .NET IL en code d'assemblage natif pour iOS / Android ou d'autres plates-formes. Ce n’est que récemment que la plus grande partie de .NET est devenue open source – auparavant, Mono fabriquait avec précaution du code .NET portable et exécutable sur d’autres plates-formes.

Cependant, il existe maintenant .NET Core, qui est moderne, polyvalent et multi-plateforme. Les développeurs de l’écosystème Xamarin se sont demandés récemment: le .NET Core pourrait-il remplacer Mono comme le runtime pour les applications Xamarin?

 MonoNetCore "title =" MonoNetCore "/><p data-recalc-dims= Alors qu’il est intéressant de tout attendre du début à la fin En réalité, l’âge vous rend sage et Mono, à ce jour, affiche une surface d’API plus grande que celle de .NET Core. Mono est également très performant pour les applications .NET fonctionnant sur iOS / Android – les deux Que ce soit par l’interprétation IL ou par une compilation statique, Mono est également en avance sur le jeu en ce qui concerne les implémentations .NET sur des plates-formes tournées vers l’avenir, telles que le très important WebAssembly.

L’autre question à prendre en compte est la fragmentation de .NET. Bien qu’avoir divers BCL .NET optimisés pour différentes plates-formes soit une bonne chose, l’état actuel de l’écosystème est-il une source de confusion pour les développeurs? pour Microsoft ou le communauté open source pour maintenir autant de .NET? Peut-être faut-il unifier les différentes durées d’exécution – seul le temps le dira.

Comment utiliser Xamarin

Les développeurs qui choisissent la pile technologique Xamarin pour créer des applications mobiles peuvent être assurés d’une exécution solide et d’une pléthore d’outils riches. Cela évite aux développeurs de se soucier de la logistique liée à la création d'une application et leur permet de se concentrer uniquement sur l'application elle-même. Au moment de démarrer avec Xamarin, deux grands choix s'offrent à vous:

Xamarin iOS / Android

Dès les débuts de Xamarin, l'objectif était d'écrire du code .NET pouvant être partagé sur plusieurs plates-formes mobiles. ce qu'on appelle Xamarin.iOS / Android. Souvent surnommé Xamarin Native, l'objectif est de disposer d'une couche de code partagé écrite en .NET et de projets spécifiques à la plate-forme pour la partie interface utilisateur des applications mobiles.

 XamarinNative "title =" XamarinNative "/></p data-recalc-dims=

L'objectif avec Xamarin.iOS / Android est de résumer autant de fonctionnalités que possible définies dans une bibliothèque de codes .NET – ceci est partagé entre Xamarin Native oblige les développeurs à créer seule la couche d'interface utilisateur de chaque plate-forme mobile prise en charge, ce qui signifie qu'ils ont besoin de savoir comment créer l'interface utilisateur de l'application pour iOS, Android et Windows de manière native. – Tous réunis dans un seul projet et faisant référence à la bibliothèque partagée.

Alors, quand les développeurs devraient-ils choisir de construire avec Xamarin iOS / Android? Xamarin Native est un bon choix en général lorsque les applications mobiles ont tendance à s’adapter fortement à une certaine plate-forme – Les jeux mobiles sont également bien servis avec Xamarin Native – en gros, Xamarin.iOS / Android est un bon choix partout où les développeurs souhaitent s'exécuter aussi près que possible du métal. Xamarin Native avantages à partir d'une couche de code .NET partagée, mais l'interface utilisateur est écrite de manière native pour chaque plate-forme mobile. De plus, Xamarin.Forms (voir ci-dessous) peut désormais être intégré à Xamarin Native, obtenant ainsi le meilleur des deux mondes.

Xamarin.Forms

Ce qui a commencé comme outil de prototypage pour les abstractions multi-plateformes s'est développé. ce que nous appelons Xamarin.Forms aujourd'hui. Outre le code .NET partagé, il existe une couche d'interface utilisateur partagée qui s'étend sur plusieurs plates-formes et restitue l'interface utilisateur native correspondante. Cette couche d'interface utilisateur partagée est une abstraction permettant aux développeurs d'écrire du code / balisage .NET, qui est ensuite traduit en interface utilisateur native sur chaque plate-forme à / avant l'exécution. Xamarin.Forms présente l’énorme avantage de permettre aux développeurs .NET de ne pas avoir à connaître à la main les subtilités de la construction d’UI iOS / Android.

 XamarinForms "title =" XamarinForms "/></p data-recalc-dims=

Gardez à l’esprit, Xamarin .Forms tente de résoudre un problème extrêmement complexe: une couche d’abstraction d’interface utilisateur cohérente qui restitue une interface utilisateur native sur des plates-formes totalement différentes. Tandis que Xamarin.Forms dispose d’une large gamme de contrôles, la communauté des développeurs et les écosystèmes partenaires comblent les lacunes Si les développeurs le souhaitent et que l'application le demande, ils peuvent toujours accéder à Xamarin.Forms depuis l'interface utilisateur native en écrivant des moteurs de rendu personnalisés pour les comportements spécifiques à la plate-forme ou en rendant les contrôles d'interface utilisateur natifs sur chaque plate-forme. 19659039] Alors, pourquoi encore Xamarin?

En résumé, nous sommes en 2019 et espérons que le mobile ne soit pas une réflexion après-coup. Une stratégie mobile légitime réduit la frustration des développeurs et permet la réutilisation du code. es, web mobile moderne, applications natives hybrides ou JS sont la voie à suivre – vous avez un outil riche et une pléthore d’accès aux API natives.

Si vous souhaitez toutefois utiliser l'option .NET, Xamarin est un choix facile. Voici quelques indicateurs qui vous aideront à décider si vous souhaitez choisir la pile technologique Xamarin:

  1. Vous souhaitez écrire du code C # / F #
  2. Vous êtes à l'aise avec le langage de balisage XAML
  3. pour une réutilisation maximale du code avec d'autres projets .NET
  4. Vous voulez rester dans le confort de Visual Studio
  5. Vous attendez un environnement d'exécution solide, des outils astucieux et un écosystème riche

Convaincu de Xamarin? Votre code est entre de bonnes mains et l’avenir est magnifique.


Les commentaires sont désactivés en mode aperçu.




Source link