Pourquoi XAML? Pourquoi maintenant?

Le langage XAML a résisté à l'épreuve du temps et reste un langage de définition d'interface utilisateur flexible. Cet article explore les plates-formes d'applications que le XAML exploite aujourd'hui et envisage l'avenir de l'avenir.

XAML est mort. No wait – Longue vie à XAML. XAML (langage de balisage extensible d'application) a débuté sous la forme d'une simple couche de balisage d'interface utilisateur mince, mais son histoire est étonnamment riche en événements. Les développeurs de Microsoft ont assisté à l’essor phénoménal de XAML et à son instabilité sur le bord de la vie.

Il semble que XAML soit très apprécié ou détesté, mais qu’il a clairement résisté à l’épreuve du temps. Au fil des ans, aucune équipe de Microsoft n’a été propriétaire de XAML – c’était un langage d’interface utilisateur de balisage descriptif permettant de définir des arbres visuels pour les applications. Ainsi, plusieurs technologies ont adopté le XAML et lui ont donné du caractère et des dialectes uniques. Aujourd’hui, XAML se démarque par la puissance de ses diverses plates-formes d’application, son support en outillage riche en sports et son avenir prometteur. Cet article explore ce que le XAML peut faire aujourd'hui avec un œil ouvert sur l'avenir.

Bureau

Windows Presentation Foundation (WPF)

Le Saint Graal du développement de bureau sous Windows aujourd'hui est encore WPF – c'est là que XAML a commencé sa vie. Au fil des ans, XAML a toujours été la couche d'interface utilisateur pour les applications WPF et a bénéficié d'une prise en charge riche en outils. On pourrait soutenir qu'une grande partie de la richesse en fonctionnalités et de la facilité d'utilisation de XAML provient de WPF. Microsoft et la communauté des développeurs se sont mobilisés pour faire du développement XAML / C # une expérience merveilleuse pour les développeurs. Avec le code intellisense et des outils de conception tels que Blend, la couche de définition d'interface utilisateur pour les applications WPF reste la référence en matière de développement XAML.

Plateforme Windows universelle

À partir de Windows 8 et après plusieurs itérations, Microsoft a finalement atterri sur UWP – le moyen de facto de créer des applications prospectives pour Windows. Et bien sûr, la couche d'interface utilisateur est alimentée par XAML, bien que le dialecte soit légèrement différent de celui utilisé par WPF. XAML alimenter les applications UWP est un gros problème pour les développeurs habitués au langage de balisage, principalement en raison de la portée de UWP. UWP peut alimenter les applications sur tous les appareils Windows modernes, des tablettes, ordinateurs portables aux ordinateurs de bureau, en passant par les XBox, les Surface Hubs et les HoloLens. Les développeurs ont la possibilité de définir leur interface utilisateur en XAML, qui fonctionne simplement pour tous les facteurs de forme.

Bien que cela semble magique, la réalité demande un peu de travail pour ajuster les dispositions avec une interface utilisateur fluide pour différentes tailles de périphériques – mais tout est en XAML sous les couvertures. Et la flexibilité des périphériques UWP signifie des fonctionnalités riches en sports XAML telles que des dispositions réactives, une prise en charge tactile avancée et des fonctionnalités d'encrage.

Mobile

Xamarin.Forms

Pouvoir atteindre tous les périphériques Windows avec XAML était bien, mais personne vit dans un silo de plate-forme. Règle iOS / Android pour les facteurs de forme mobiles: les développeurs .NET avaient besoin d'un pont pour transférer leurs compétences sur plusieurs plateformes. Entrez Xamarin.Forms . Avec une couche d'interface utilisateur abstraite partagée, les développeurs peuvent partager non seulement la logique métier, mais également la définition de l'interface utilisateur, le tout dans le but de créer des applications multiplateformes véritablement natives. Et le choix de la définition abstraite de l'interface utilisateur? Oui, XAML – un dialecte spécial de ce logiciel a été conçu pour le développement d'applications mobiles.

Xamarin.Forms XAML a fait quelque chose de formidable – soulageant les développeurs .NET de la complexité inhérente à la plateforme native UI. Les développeurs ont la possibilité de définir l’arborescence visuelle de l’interface utilisateur en XAML et le moteur d’exécution s’en remet pour restituer les composants d’interface utilisateur natifs correspondants sur chaque plateforme. Le développement moderne de Xamarin.Forms fournit des outils sophistiqués pour le développement de XAML, tels que Forms Previewer, Inspector et Profiler.

Uno

Xamarin.Forms XAML n'est-il pas tout à fait votre tasse de thé? Il s'avère que quelques personnes intelligentes de Montréal au Canada sont avec vous et aiment UWP XAML. Entrez Uno – une bibliothèque d'abstraction d'interface utilisateur open source qui crée des ponts vers XIML pour iOS et Android. L'exécution d'application de Uno est gérée par Mono et Xamarin – les développeurs doivent simplement utiliser UWP XAML, au lieu de la tête Xamarin.Forms. Ce n'était pas un mince effort puisque l'interface utilisateur native correspondante est restituée sur chaque plate-forme. Tout cela en vaut la peine, juste pour l'amour d'UWP XAML.

NativeScript

De nombreuses entreprises disposant traditionnellement d'une pile de technologies .NET complète désormais leurs interfaces d'applications avec des infrastructures SPA, comme Angular, React ou Vue. La plupart des développeurs .NET modernes n'hésitent pas à écrire du code JavaScript, CSS et HTML. Et si les technologies Web alimentent vos applications, les applications JavaScript natives sont plutôt séduisantes en tant que stratégie mobile. Les développeurs ont la possibilité de réutiliser les technologies Web pour créer des applications mobiles multiplates-formes véritablement natives – et potentiellement partager le code entre le Web et le mobile.

NativeScript est un framework open source pour la construction de JS Native. application mobile. Les développeurs ont la possibilité d'écrire directement du code JavaScript ou TypeScript avec Angular pour la logique métier de l'application. Et la couche d'interface utilisateur abstraite est définie en XML – un pont JS restitue l'interface utilisateur native correspondante au moment de l'exécution. Alors qu'officiellement XML, examinons les définitions d'interface utilisateur standard dans NativeScript – vous avez l'air familier? Oui, c'est presque le XAML, et les développeurs .NET ayant une expérience quelconque du XAML seront parfaitement à l'aise ici.

Web

Les applications XAML sur le navigateur Web ont connu un passé en damier. Il va de soi que les développeurs .NET qui ont utilisé Silverlight sont toujours blessés – ce n’est jamais une bonne situation que les technologies meurent et réduisent leurs investissements. Le Web s'est simplement éloigné du modèle Plugins et Silverlight a vu l'écriture sur le mur. Cependant, les personnes qui ont développé Silverlight étaient passionnées par l’expérience des développeurs – XAML / C # était magnifique dans le navigateur et la richesse des outils l’a aidé. Il est peut-être désireux de voir le XAML revenir sur le Web, mais avec une meilleure architecture.

WebAssembly

Entrez WebAssembly – format d'instruction de bas niveau que les navigateurs persistants modernes peuvent exécuter de manière native, tout comme les moteurs JavaScript exécutent du code JS. En tant que norme Web ouverte, WebAssembly bénéficie du soutien de grands constructeurs de navigateurs, avec des promesses de sécurité et de vitesses d’exécution natives. Le plus gros avantage de WebAssembly est la promesse de compiler du code écrit en langages de niveau supérieur en instructions empilées que les navigateurs exécutent en mode natif – cette ouvre de nombreuses portes .

Mono

Mono existe depuis les débuts du .NET Framework, en tant que port populaire d'API .NET pour les plates-formes en dehors de Windows. Au fil des ans, Mono a mûri pour fournir une grande surface de surface API et des mappages d'API .NET sur d'autres plates-formes telles que Mac / Linux, permettant ainsi aux applications .NET de sortir de Windows. Mono continue d'alimenter tout Xamarin – il s'agit clairement du moyen le plus simple de prendre du code .NET et de le faire fonctionner sur iOS / Android.

Il s'avère que les gens de Mono sont très intelligents et que des travaux sont en cours pour amener Mono à la plate-forme WebAssembly . Cela a le formidable potentiel de compiler du code C # dans WebAssembly, que les navigateurs peuvent exécuter de manière native, Hallelujah! C’est exactement ce qui fait fonctionner Blazor – le framework Web expérimental ASP.NET qui promet d’apporter C # au navigateur avec la syntaxe Razor. Bien que le support actuel de WebAssembly puisse être utilisé via l'interpréteur Mono IL pour exécuter du code géré à l'exécution, la prise en charge de la compilation AOT (Ahead Of Time) statique complète n'est pas encore très éloignée. Cela devrait donner d’excellentes performances du code C # sur le navigateur.

Avec C # venant en mode natif sur le navigateur, il n’a pas fallu beaucoup de temps aux amateurs de XAML pour exiger le retour de la couche d’abstraction d’UI – cette fois, c’est fait. via WebAssembly au lieu d’utiliser un plugin. Bien qu’il soit expérimental, il s'avère que Xamarin.Forms et UWP ont déjà accès aux applications Web du navigateur via WebAssembly.

Meet Ooui – une petite bibliothèque d’interface utilisateur multiplate-forme qui apporte la simplicité d'une interface utilisateur native. développement sur le web . Ooui.Forms fournit aux moteurs de rendu Xamarin.Forms pour le Web un DOM DOM qui alimente l’application frontale. Il peut être hébergé seul ou dans le cadre de ASP.NET Core. Il existe plusieurs échantillons en ligne pour jouer et voir le plaisir de retrouver XAML dans le navigateur. De plus, Ooui.Wasm permet de conditionner les applications Xamarin.Forms avec le balisage XAML UI dans un environnement d'exécution WebAssembly. Il est agréable de voir une application Xamarin.Forms, compilée de manière statique et hébergée sur Amazon S3, fonctionnant sous le nom WebAssembly sur le navigateur .

À ne pas laisser de côté, UWP XAML retrouve également son chemin le navigateur – grâce à Uno. Le support expérimental de WebAssembly semble parfait, en particulier lorsque vous essayez des choses dans de WebAssembly Playground . Écrire, éditer et voir le XAML fonctionner nativement dans le navigateur – quelle magie.

Looking Ahead

Frameworks MVVM

Les outils riches sont une des raisons pour lesquelles les développeurs .NET s'intéressent au développement XAML et facilité de maintenance de grandes bases de code. Model-View-ViewModel (MVVM) est un modèle de conception qui fonctionne vraiment bien pour le développement XAML / C # et l'aide est abondante à cet égard. De nombreux frameworks MVVM ont évolué au fil des années pour prendre en charge le développement de plates-formes WPF / UWP. Ils ont maintenant été personnalisés pour fonctionner également pour Xamarin.Forms. La communauté de développeurs .NET open source se démarque vraiment avec ces frameworks MVVM – beaucoup d'efforts ont été consacrés à la création de richesse de fonctionnalités et de modèles Visual Studio pour chacun des frameworks. Les plus populaires sont MVVM Light Prism et MVVM Cross .

Xamarin.Forms Heads

Un intéressant ensemble de développements pour les développeurs XAML, le nombre croissant de têtes / moteurs pour Xamarin.Forms – cela augmente simplement le nombre de plates-formes prises en charge et prend de la place pour votre code. Xamarin.Forms est open source et la communauté des développeurs est intelligente. Le résultat est de nouvelles têtes Xamarin.Forms telles que MacOS, GTK Linux, WPF, Tizen et même le Web – les applications Xamarin.Forms commencent maintenant à prendre en charge autant de plates-formes que le mobile. Et la couche d'interface utilisateur abstraite est votre XAML bien-aimé.

Marzipan

Apple a eu un problème d'écart d'application: la plupart des développeurs construisent pour iOS, mais pas beaucoup pour Mac AppStore. Leur remède est un projet interne portant le nom de code & lsquo; Marzipan & rsquo; – vise à être concrétisé dans le courant de 2019. L'objectif consiste à faire fonctionner les applications iOS sur le bureau Mac via un mashup d'UIKit et d'AppleKit – et plusieurs démonstrations déjà présentées par Apple. Maintenant, cela doit évidemment être fait avec précaution – il y a des implications lorsque nous ramenons les applications tactiles au bureau avec la souris / le clavier.

Alors pourquoi les développeurs .NET / XAML devraient-ils s'intéresser au massepain? Il s'avère que nous parlons d'applications iOS fonctionnant sur le bureau Mac avec des modifications minimes. Et les applications iOS peuvent être écrites dans Xamarin.Forms ou Uno – cela signifie que XAML peut officiellement alimenter les applications de bureau sur Mac. Étant donné la richesse de XAML pour la gestion de mises en page réactives, on peut affirmer que les développeurs XAML devraient pouvoir transférer leurs applications iOS assez facilement sur Mac.

Interface utilisateur polie

Le riche écosystème est une autre raison d'aimer le développement de XAML / C #. La plupart des applications professionnelles nécessitent une interface utilisateur performante complexe et les développeurs n'ont pas besoin de réinventer la roue – il y a beaucoup d'aide. Entrez Progress Telerik – votre bien-aimé outil .NET sur le Web, les ordinateurs de bureau et les appareils mobiles.

Telerik propose plusieurs suites d’interface utilisateur prenant en charge différentes plates-formes pour les développeurs XAML. Les commandes courantes de l'interface utilisateur riches en fonctionnalités, la prise en charge complète du MVVM, des API cohérentes et des thèmes professionnels pour le style. Les efforts d'ingénierie à la base de chaque composant de l'interface utilisateur se traduisent par des performances et un rendu au pixel près – les développeurs aiment les interfaces utilisateur complexes qui leur permettent simplement d'éclairer des applications. Les contrôles populaires incluent Grilles, ListViews, divers graphiques, calendriers, SideDrawers et d'innombrables autres interfaces utilisateur difficiles à créer manuellement.

Alors que Telerik UI for WPF fournit une interface utilisateur puissante pour les applications de bureau, L'interface utilisateur Telerik pour Xamarin alimente les applications mobiles sur toutes les plateformes – et oui, toutes avec XAML comme pile d'interface utilisateur.

Alors que le Web moderne s'est peut-être éloigné du modèle Plugins, de nombreuses entreprises Les applications Silverlight restent le flux de travail du secteur d'activité. À cette fin, l’interface utilisateur de Telerik pour Silverlight est là pour vous aider et voit les investissements dans les fonctionnalités se poursuivre. Construire pour les appareils Windows? L’UI Telerik pour UWP est là pour vous aider avec une interface utilisateur performante et polie – et une source entièrement libre et ouverte.

Norme XAML

Comme indiqué précédemment, nous avons quelques versions de XAML – WPF, UWP et Xamarin.Forms parlent chacun un dialecte légèrement différent. Cela conduit à une certaine fragmentation et à une certaine frustration pour les développeurs, principalement à cause de petites différences gênantes et de la modification des espaces de noms XAML. Ce ne serait pas bien si toutes les plateformes parlent le même XAML?

C’est exactement ce que XAML Standard vise à faire: uniformiser tous les dialectes XAML en un langage commun entre WPF, UWP et Xamarin.Forms . Les spécifications de la norme XAML sont en cours de préparation au grand public avec les réactions de la communauté des développeurs et les efforts initiaux visant à créer des pseudonymes pour lisser les différences entre les plates-formes XAML. Cependant, XAML Standard pose un problème particulièrement difficile: le XAML sur différentes plates-formes est souvent trop centré sur ses spécificités. La route à parcourir est rude pour le standard XAML, pour le moins qu'on puisse dire.

Unified UI Stack

Si clairement, XAML en tant que couche d'interface utilisateur est très apprécié et a résisté à l'épreuve du temps. Aujourd'hui, XAML gère plusieurs plates-formes d'applications pour ordinateurs de bureau et mobiles, et des efforts expérimentaux sont en cours pour ramener XAML au navigateur Web. Les développeurs bénéficient d'outils sophistiqués pour le développement XAML et une communauté dynamique fournit un soutien.

Cependant, on peut également soutenir qu'il existe des messages contradictoires autour du XAML. Il existe de nombreuses façons de créer la pile d'interface utilisateur XAML pour mobile / ordinateur de bureau. De véritables solutions multi-plateformes nécessitent beaucoup de travail. & Nbsp; Pourrait-il y avoir un filet d'argent à l'horizon?

Il s'avère que les mises à jour .NET Core sont arrivées dans les vagues. .NET Core 1.x consistait à utiliser le CLR sur plusieurs plates-formes afin que les applications .NET puissent sortir de Windows. .NET Core 2.x a stabilisé le navire: la plupart des API manquantes ont été rétablies et les outils de développement Web ont atteint leur maturité. .NET Core 3 consistera à tirer parti des avantages de .NET Core sur le bureau pour les applications WPF / WinForms. La vague .NET Core 4.0 pourrait-elle traiter l’histoire de l’interface utilisateur multiplate-forme?

Ne serait-il pas agréable de disposer d’une couche d’interface utilisateur uniforme, cohérente et fonctionnant sur plusieurs plates-formes Web / bureau / mobile? Nous pouvons conjecturer sur l'avenir, mais le XAML est probablement le candidat le plus évident pour réussir le braquage. Croisons les doigts et acclamons l'avenir!

Source link