wpf - vacia - proyectos uwp

¿Cómo se compara Windows 8 Runtime(aplicaciones WinRT/Windows Store/Windows 10 Universal) con Silverlight y WPF? (5)

Estoy tratando de entender el nuevo Windows 8 Runtime que se utiliza para crear aplicaciones de estilo Metro . Sé que puede usarlo con XAML y está basado en .NET, por lo que C # y VB.NET pueden usarse para escribir las aplicaciones, pero luego parece tener algo que ver con HTML, CSS, DOM y JavaScript.

¿Alguien puede explicar qué es en unos pocos párrafos, en términos que pueda entender un programador de interfaz de usuario .NET? (Me falta algo "clave" que es necesario para entenderlo.)

Todos sabemos que WPF, Silverlight , Windows Forms , etc. seguirán funcionando bajo Windows 8 (y Windows 10) en al menos los sistemas Intel, así que no me digan que ...

Desde la nota clave de Build :

Están proporcionando API comunes para aplicaciones HTML / CSS / JavaScript y aplicaciones C # / XAML. Se utilizarán C # y XAML, pero no serán exactamente WPF o Silverlight.

Hay una versión modificada de la arquitectura que seguramente te ayudará a entender dónde están exactamente las cosas. Uno de los ninjas de Telerik conversó con el equipo de CLR y modificó la imagen:

Aquí puedes ver dónde está el CLR. El .NET Framework ahora tiene dos perfiles.

1- Perfil de .NET Metro (CLR que trata con la aplicación de Metro)

2- Perfil de cliente .NET (tiempo de ejecución de CLR para aplicaciones C # y VB.NET)

Espero que esto te dé una imagen más clara. Lea el artículo completo en Una mala imagen vale más que mil largas discusiones. .

La idea clave es que ahora hay dos pistas de desarrollo: Desktop y Metro.

El escritorio es donde viven las aplicaciones antiguas.
La nueva clase de aplicaciones, las aplicaciones de Metro, se pueden construir de varias maneras, incluso mediante VB.NET, C # o C ++. Estas tres opciones de idioma pueden usar XAML para construir la interfaz de usuario. La alternativa es usar JavaScript / HTML5 / CSS para el desarrollo de la interfaz de usuario y el código de la aplicación.

Algunos puntos importantes:

Windows 8 se siente como un sistema operativo de teléfono móvil mejorado.
En Metro, no hay ventanas superpuestas de nivel superior, al igual que ninguna en un teléfono móvil. Si desea una aplicación de estilo MDI, debe permanecer en el escritorio.
Las aplicaciones estilo metro se suspenden automáticamente cuando no están visibles. Esto se hizo para prolongar la vida de la batería. Esto significa que no tendrá sentido que muchas aplicaciones de escritorio existentes, que realizan el procesamiento en segundo plano incluso cuando el usuario no está interactuando con ellas, se trasladen a Metro.
La versión ARM de Windows 8 no admite aplicaciones de escritorio. Entonces, si desea escribir una aplicación y quiere que funcione en cualquier versión de Windows, entonces tiene que ser una aplicación de Metro.

Un montón de detalles de Microsoft here .

El tiempo de ejecución de Windows se expone mediante los metadatos de la API (archivos .winmd). Este es el mismo formato usado por el framework .NET (Ecma-335). El contrato binario subyacente le facilita el acceso a las API de Windows Runtime directamente en el lenguaje de desarrollo de su elección. La forma y la estructura de las API de Windows Runtime se pueden entender mediante lenguajes estáticos como C # y lenguajes dinámicos como JavaScript. IntelliSense está disponible en JavaScript, C #, Visual Basic y C ++.

En resumen, Windows Runtime es un nuevo conjunto de bibliotecas que expone la funcionalidad de Windows y está disponible para JavaScript / C # / VB / C ++. Cada idioma se ha hecho para comprender y poder llamarlos directamente en lugar de tener que pasar por alguna capa de procesador.

Silverlight y WPF son versiones de XAML que se ejecutan en el CLR. Entre otras funciones, Windows Runtime expone una versión de XAML muy similar a Silverlight, pero lo hace de forma nativa, no a través del CLR. Se puede acceder desde CLR, pero también desde C ++.

En el nivel más bajo, WinRT es un modelo de objeto definido en el nivel ABI. Utiliza COM como base (por lo que cada objeto WinRT implementa IUnknown y hace refcounting), y se construye desde allí. Agrega muchos nuevos conceptos en comparación con COM de la antigüedad, la mayoría de los cuales provienen directamente de .NET; por ejemplo, el modelo de objetos WinRT tiene delegados y los eventos se realizan al estilo .NET (con delegados y agregar / eliminar suscriptores métodos, uno por evento) en lugar del antiguo modelo COM de orígenes y receptores de eventos. De otras cosas notables, WinRT también tiene interfaces parametrizadas ("genéricas").

Otro gran cambio es que todos los componentes de WinRT tienen metadatos disponibles para ellos, al igual que los ensamblados .NET. En COM, un poco sorta tenía eso con typelibs, pero no todos los componentes COM los tenían. Para WinRT, los metadatos están contenidos en los archivos .winmd. Mire dentro de "C: / Archivos de programa (x86) / Windows Kits / 8.0 / Windows Metadata /" en la Vista previa para desarrolladores. Si hurgas, verás que en realidad son ensamblajes CLI sin código, solo tablas de metadatos. Puedes abrirlos con ILDASM, de hecho. Tenga en cuenta que esto no significa que WinRT sea administrado, simplemente reutiliza el formato de archivo.

Luego hay una serie de bibliotecas implementadas en términos de ese modelo de objetos, que definen interfaces y clases de WinRT. De nuevo, mira la carpeta "Metadatos de Windows" mencionada anteriormente para ver qué hay allí; o simplemente inicie Object Browser en VS y seleccione "Windows 8.0" en el selector de marco, para ver qué está cubierto. Hay mucho allí, y no se ocupa solo de la interfaz de usuario, también obtiene espacios de nombres como Windows.Data.Json , o Windows.Graphics.Printing , o Windows.Networking.Sockets .

Luego obtiene varias bibliotecas, que tratan específicamente de la interfaz de usuario; en su mayoría, estos serían varios espacios de nombres en Windows.UI o Windows.UI.Xaml . Muchos de ellos son muy similares a los espacios de nombres WPF / Silverlight, por ejemplo, Windows.UI.Xaml.Controls es muy similar a System.Windows.Controls ; ídem para Windows.UI.Xaml.Documents etc.

Ahora, .NET tiene la capacidad de hacer referencia directa a los componentes de WinRT como si fueran ensamblajes de .NET. Esto funciona de manera diferente a la interoperabilidad COM: no necesita ningún artefacto intermedio, como ensamblajes interoperados, simplemente /r un archivo .winmd, y todos los tipos y sus miembros en sus metadatos se vuelven visibles para usted como si fueran objetos .NET. Tenga en cuenta que las bibliotecas WinRT en sí mismas son completamente nativas (y, por lo tanto, los programas C ++ nativos que usan WinRT no requieren CLR en absoluto): la magia para exponer todas esas cosas tal como se administran está dentro del propio CLR y es de un nivel bastante bajo. Si utiliza un programa .NET que hace referencia a un .winmd, verá que en realidad se parece a una referencia de ensamblaje externo: no hay trucos manuales como el incrustado de tipos allí.

Tampoco se trata de un mapeo contundente: CLR intenta adaptar los tipos de WinRT a sus equivalentes, siempre que sea posible. Entonces, por ejemplo, los GUID, las fechas y los URI se convierten en System.Guid , System.DateTime y System.Uri , respectivamente; Las interfaces de la colección WinRT como IIterable<T> y IVector<T> convierten en IEnumerable<T> e IList<T> ; y así. Esto va en ambos sentidos: si tiene un objeto .NET que implementa IEnumerable<T> y lo devuelve a WinRT, lo verá como IIterable<T> .

En última instancia, lo que esto significa es que sus aplicaciones .NET Metro obtienen acceso a un subconjunto de las bibliotecas .NET estándar existentes, y también a las bibliotecas WinRT (nativas), algunas de las cuales, particularmente Windows.UI , se parecen mucho a Silverlight, API -sabio. Aún tiene XAML para definir su UI, y aún trata con los mismos conceptos básicos que en Silverlight: enlaces de datos, recursos, estilos, plantillas, etc. En muchos casos, es posible migrar una aplicación de Silverlight simplemente using los nuevos espacios de nombres , y ajustar algunos lugares en el código donde se ajustó la API.

WinRT en sí no tiene nada que ver con HTML y CSS, y guarda relación con JavaScript solo en el sentido de que también está expuesto allí, de manera similar a como se hace con .NET. No necesita lidiar con HTML / CSS / JS cuando usa las bibliotecas de la interfaz de usuario de WinRT en su aplicación .NET Metro (bueno, supongo que si realmente quiere, puede alojar un control WebView ...). Todas sus habilidades de .NET y Silverlight siguen siendo muy relevantes en este modelo de programación.