Comment Windows 8 Runtime (WinRT / applications Windows Store / Windows 10 Universal App) se compare-t-il à Silverlight et WPF? [fermé]

J'essaie de me familiariser avec le nouveau Windows 8 Runtime qui est utilisé pour créer des applications de style Metro . Je sais que vous pouvez l'utiliser avec XAML et il est basé sur .NET, donc C # et VB.NET peuvent être utilisés pour écrire les applications, mais il semble que cela ait quelque chose à voir avec HTML, CSS, DOM et JavaScript.

Quelqu'un peut-il expliquer ce que c'est en quelques paragraphes, en termes qu'un programmeur d'interface utilisateur .NET 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. continueront de fonctionner sous Windows 8 (et Windows 10) sur au moins les systèmes Intel, alors ne me le dites pas ...

Au niveau le plus bas, WinRT est un modèle objet défini au niveau ABI. Il utilise COM comme base (donc chaque objet WinRT implémente IUnknownet effectue le recomptage) et construit à partir de là. Il ajoute beaucoup de nouveaux concepts par rapport à COM des anciens, dont la plupart proviennent directement de .NET - par exemple, le modèle d'objet WinRT a des délégués, et les événements sont effectués de style .NET (avec des délégués et ajout / suppression d'abonné méthodes, une par événement) plutôt que l'ancien modèle COM de sources et récepteurs d'événements. Parmi d'autres choses notables, WinRT a également des interfaces paramétrées ("génériques").

Un autre grand changement est que tous les composants WinRT ont des métadonnées disponibles pour eux, tout comme les assemblys .NET. Dans COM, vous en aviez en quelque sorte avec les listes de types, mais tous les composants COM n'en avaient pas. Pour WinRT, les métadonnées sont contenues dans des fichiers .winmd - regardez à l'intérieur de "C: \ Program Files (x86) \ Windows Kits \ 8.0 \ Windows Metadata \" dans Developer Preview. Si vous fouillez, vous verrez que ce sont en fait des assemblys CLI sans code, juste des tables de métadonnées. Vous pouvez les ouvrir avec ILDASM, en fait. Remarque, cela ne signifie pas que WinRT lui-même est géré - il réutilise simplement le format de fichier.

Ensuite, il existe un certain nombre de bibliothèques implémentées en termes de ce modèle d'objet - définissant les interfaces et les classes WinRT. Encore une fois, regardez le dossier "Windows Metadata" mentionné ci-dessus pour voir ce qu'il y a; ou lancez simplement l'Explorateur d'objets dans VS et sélectionnez "Windows 8.0" dans le sélecteur de framework, pour voir ce qui est couvert. Il y a beaucoup de choses là-bas, 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 de l'interface utilisateur - la plupart du temps, il s'agirait de divers espaces de noms sous Windows.UIou Windows.UI.Xaml. Beaucoup d'entre eux sont très similaires aux espaces de noms WPF / Silverlight - par exemple, ils Windows.UI.Xaml.Controlscorrespondent étroitement System.Windows.Controls; idem pour Windows.UI.Xaml.Documentsetc.

Désormais, .NET a la possibilité de référencer directement les composants WinRT comme s'il s'agissait d'assemblages .NET. Cela fonctionne différemment de COM Interop - vous n'avez pas besoin d'artefacts intermédiaires tels que des assemblys d'interopérabilité, vous n'avez qu'un /rfichier .winmd, et tous les types et leurs membres dans ses métadonnées deviennent visibles pour vous comme s'il s'agissait d'objets .NET. Notez que les bibliothèques WinRT elles-mêmes sont entièrement natives (et donc les programmes C ++ natifs qui utilisent WinRT ne nécessitent pas du tout CLR) - la magie pour exposer tout ce qui est géré se trouve à l'intérieur du CLR lui-même, et est assez bas. Si vous identifiez un programme .NET qui fait référence à un .winmd, vous verrez qu'il ressemble en fait à une référence d'assembly externe - il n'y a aucun tour de passe-passe tel que l'incorporation de type.

Ce n'est pas non plus un mappage brutal - CLR essaie d'adapter les types WinRT à leurs équivalents, si possible. Ainsi, par exemple, les GUID, les dates et les URI deviennent respectivement System.Guid, System.DateTimeet System.Uri; Interfaces de collecte 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 le transmettez à WinRT, il le verra comme IIterable<T>.

En fin de compte, cela signifie que vos applications .NET Metro 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- ressemblent beaucoup à Silverlight, au niveau de l'API. Vous avez toujours XAML pour définir votre interface utilisateur, et vous traitez toujours 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 usingles nouveaux espaces de noms, et peaufiner 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é, de la même manière que cela est fait pour .NET. Vous n'avez pas besoin de gérer HTML / CSS / JS lorsque vous utilisez les bibliothèques d'interface utilisateur WinRT dans votre application .NET Metro (enfin, je suppose que si vous le voulez vraiment, vous pouvez héberger un WebViewcontrôle ...). Toutes vos compétences .NET et Silverlight restent très pertinentes dans ce modèle de programmation.

Extrait du discours d'ouverture de Build :

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 désormais 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 par VB.NET, C # ou C ++. Ces trois options de langue peuvent utiliser XAML pour créer l'interface utilisateur. 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 système d'exploitation de téléphone mobile mis à l'échelle.
• 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 durée de vie de la batterie. Cela signifie que cela n'aura aucun sens pour de nombreuses applications de bureau existantes, qui effectuent un traitement en arrière-plan même lorsque l'utilisateur n'interagit pas avec elles, pour être portées sur Metro.
• La version ARM de Windows 8 ne prend pas en charge les applications de bureau. Donc, si vous souhaitez écrire une application et que vous souhaitez qu'elle 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ù se trouvent exactement les choses. L'un des ninjas Telerik a discuté avec l' équipe du CLR et a modifié l'image:

Ici, vous pouvez voir où se trouve le CLR. Le framework .NET a maintenant deux profils

1- Profil Metro .NET (CLR qui traite de l'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 Une mauvaise image vaut mille longues discussions. .

Beaucoup de détails de Microsoft ici .

Windows Runtime est exposé à l'aide de métadonnées API (fichiers .winmd). Il s'agit du même format utilisé par le framework .NET (Ecma-335). Le contrat binaire sous-jacent vous permet d'accéder facilement 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 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 disponible pour JavaScript / C # / VB / C ++. Chaque langue a été conçue pour les comprendre et pouvoir les appeler directement plutôt que d'avoir à passer par une couche de thunking.

Silverlight et WPF sont des versions de XAML qui s'exécutent sur le CLR. Entre autres fonctionnalités, Windows Runtime expose une version de XAML très similaire à Silverlight, mais le fait de manière native, pas via le CLR. Il est accessible depuis le CLR, mais aussi depuis C ++.