Comment Windows Runtime (WinRT / applications Windows Store / Windows 10 Universal App) se compare-t-il à Silverlight et WPF?
J'essaie de comprendre le nouveau Windows 8 Runtime utilisé pour créer des applications de style Metro . Je sais que vous pouvez l'utiliser avec XAML et qu'il est basé sur .NET, vous pouvez donc utiliser C # et VB.NET pour écrire les applications, mais cela semble alors avoir quelque chose à voir avec HTML, CSS, DOM et JavaScript.
Quelqu'un peut-il expliquer ce que sont en quelques paragraphes, en termes qu'un programmeur .NET UI peut comprendre? (Il me manque quelque chose de "clé" qui est nécessaire pour le comprendre.)
Nous savons tous que WPF, Silverlight , Windows Forms , etc. continuera à fonctionner sous Windows 8 (et Windows 10) au moins sur les systèmes Intel, merci de ne pas dis moi ça...
Au niveau le plus bas, WinRT est un modèle objet défini au niveau ABI. Il utilise COM comme base (chaque objet WinRT implémente donc IUnknown et effectue le décompte) et construit à partir de là. Il ajoute beaucoup de nouveaux concepts par rapport aux anciens COM, dont la plupart proviennent directement de .NET - par exemple, le modèle objet WinRT a des délégués, et les événements sont réalisés de type .NET (avec des délégués et ajouter/supprimer des abonnés). méthodes, une par événement) plutôt que l’ancien modèle COM des sources et des puits d’événements. WinRT possède également des interfaces paramétrées ("génériques").
Un autre grand changement est que tous les composants WinRT disposent de métadonnées, tout comme les assemblys .NET. Dans COM, vous en avez un peu affaire avec les bibliothèques de types, mais tous les composants COM ne les possédaient pas. Pour WinRT, les métadonnées sont contenues dans les fichiers .winmd. Recherchez dans "C:\Fichiers de programme (x86)\Windows Kits\8.0\Métadonnées Windows" dans l’aperçu du développeur. Si vous fouillez, vous verrez que ce sont en réalité des assemblages CLI sans code, mais uniquement des tables de métadonnées. Vous pouvez les ouvrir avec ILDASM, en fait. Notez que cela ne signifie pas que WinRT est lui-même géré - il réutilise simplement le format de fichier.
Ensuite, un certain nombre de bibliothèques sont implémentées en fonction de ce modèle d'objet - définissant des interfaces et des classes WinRT. Encore une fois, examinez le dossier "Métadonnées Windows" mentionné ci-dessus pour voir ce qu'il y a là; ou lancez simplement Object Browser dans VS et sélectionnez "Windows 8.0" dans le sélecteur de structure pour voir ce qui est couvert. Il y en a beaucoup, et cela ne concerne pas uniquement l'interface utilisateur - vous obtenez également des espaces de noms tels que Windows.Data.Json ou Windows.Graphics.Printing ou Windows.Networking.Sockets.
Ensuite, vous obtenez plusieurs bibliothèques, qui traitent spécifiquement d’UI - la plupart du temps, il s’agit de divers espaces de noms sous Windows.UI ou Windows.UI.Xaml. Beaucoup d’entre eux sont très similaires aux espaces de noms WPF/Silverlight - par exemple. Windows.UI.Xaml.Controls correspond étroitement à System.Windows.Controls; idem pour Windows.UI.Xaml.Documents etc.
Désormais, .NET peut référencer directement les composants WinRT comme s’ils étaient des assemblys .NET. Cela fonctionne différemment de COM Interop - vous n'avez pas besoin d'artefacts intermédiaires tels que des assemblages d'interopérabilité, vous devez simplement /r un fichier .winmd, et tous les types et leurs membres dans ses métadonnées deviennent visibles comme s'ils l'étaient. Objets NET. Notez que les bibliothèques WinRT elles-mêmes sont entièrement natives (et que les programmes C++ natifs qui utilisent WinRT ne requièrent pas du tout de CLR) - la magie pour exposer tout ce qui est géré est à l'intérieur du CLR lui-même et est de niveau assez bas. Si vous utilisez un programme .NET faisant référence à un fichier .winmd, vous verrez qu'il ressemble en réalité à une référence d'assembly externe - il n'y a pas de supercherie comme le type qui y est incorporé.
Ce n'est pas non plus un mappage brutal - CLR tente d'adapter les types WinRT à leurs équivalents, dans la mesure du possible. Donc, par exemple Les GUID, les dates et les URI deviennent System.Guid, System.DateTime et System.Uri, respectivement; Les interfaces de collection WinRT telles que IIterable<T> et IVector<T> deviennent IEnumerable<T> et IList<T>; etc. Cela va dans les deux sens - si vous avez un objet .NET qui implémente IEnumerable<T> et que vous le renvoyez à WinRT, il le verra comme IIterable<T>.
En fin de compte, cela signifie que vos applications Metro .NET ont accès à un sous-ensemble des bibliothèques .NET standard existantes, ainsi qu'à des bibliothèques WinRT (natives), dont certaines, en particulier Windows.UI, sont très similaires à Silverlight. , API-sage. Vous avez toujours XAML pour définir votre interface utilisateur, et vous continuez à utiliser les mêmes concepts de base que dans Silverlight - liaisons de données, ressources, styles, modèles, etc. Dans de nombreux cas, il est possible de porter une application Silverlight simplement par using les nouveaux espaces de noms et ajustement de quelques endroits dans le code où l'API a été ajustée.
WinRT lui-même n’a rien à voir avec HTML et CSS, et il n’a de relation avec JavaScript que dans le sens où il y est également exposé, comme cela se fait pour .NET. Vous n'avez pas besoin de traiter avec HTML/CSS/JS lorsque vous utilisez des bibliothèques d'interface utilisateur WinRT dans votre application .NET Metro (et bien, si vous le voulez vraiment, vous pouvez héberger un contrôle WebView ... ). Toutes vos compétences .NET et Silverlight restent très pertinentes dans ce modèle de programmation.
De la Build keynote:
Ils fournissent des API communes aux applications HTML/CSS/JavaScript et aux applications C #/XAML. C # et XAML seront utilisés, mais ce ne sera pas exactement WPF ou Silverlight.
L'idée clé est qu'il existe maintenant deux pistes de développement - le bureau et le métro.
- Le bureau est l'endroit où vivent les anciennes applications.
- La nouvelle classe d'applications, les applications Metro, peut être construite de différentes manières, notamment avec VB.NET, C # ou C++. Ces trois options de langue peuvent utiliser XAML pour créer l’UI. L'alternative consiste à utiliser JavaScript/HTML5/CSS pour le développement de l'interface utilisateur et du code d'application.
Quelques points importants:
- Windows 8 ressemble un peu à un système d'exploitation de téléphone mobile haut de gamme.
- Dans Metro, il n'y a pas de fenêtres de niveau supérieur qui se chevauchent, tout comme il n'y en a pas sur un téléphone mobile. Si vous voulez une application de style MDI, vous devez rester sur le bureau.
- Les applications de style Metro sont automatiquement suspendues lorsqu'elles ne sont pas visibles. Cela a été fait pour prolonger la vie de la batterie. Cela signifie que cela n'a pas de sens que de nombreuses applications de bureau existantes, qui effectuent un traitement en arrière-plan même lorsque l'utilisateur n'interagit pas avec elles, soient portées sur Metro.
- La version ARM de Windows 8 ne prend pas en charge les applications de bureau. Donc, si vous voulez écrire une application et que vous voulez que cela fonctionne sur n'importe quelle version de Windows, il doit s'agir d'une application Metro.
Il existe une version modifiée de l'architecture qui vous aidera sûrement à comprendre où sont exactement les choses. L'un des ninjas de Telerik a discuté avec l'équipe CLR et a modifié la photo:
Ici vous pouvez voir où se trouve le CLR. Le framework .NET a maintenant deux profils
1- Profil Metro .NET (CLR traitant d’une application Metro)
2- Profil client .NET (runtime CLR pour les applications C # et VB.NET)
J'espère que cela vous donne une image plus claire. Lisez l'article complet dans ne mauvaise image vaut mille longues discussions..
Beaucoup de détails de Microsoft ici .
Le Windows Runtime est exposé à l'aide des métadonnées de l'API (fichiers .winmd). C'est le même format utilisé par le framework .NET (Ecma-335). Le contrat binaire sous-jacent facilite l'accès aux API Windows Runtime directement dans le langage de développement de votre choix. La forme et la structure des API Windows Runtime peuvent être comprises à la fois par les langages statiques tels que C # et les langages dynamiques tels que JavaScript. IntelliSense est disponible en JavaScript, C #, Visual Basic et C++.
En bref, Windows Runtime est un nouvel ensemble de bibliothèques exposant les fonctionnalités de Windows et disponibles pour JavaScript/C #/VB/C++. Chaque langue a été conçue pour comprendre et pouvoir les appeler directement plutôt que de devoir passer par une couche de parole.
Silverlight et WPF sont des versions de XAML exécutées sur le CLR. Parmi les autres fonctionnalités, Windows Runtime expose une version de XAML très similaire à Silverlight, mais le fait de manière native, et non via le CLR. On peut y accéder à partir du CLR, mais aussi à partir de C++.