¿Qué es WinRT?
Introducción
WinRT es la abreviación de Windows Runtime, un modelo de programación implementado y presentado por Microsoft en el año 2011 y que facilita el desarrollo de aplicaciones Software con estilo Metro para su sistema operativo Windows 8.
Lenguajes de desarrollo soportados
WinRT soporta tanto C++, como lenguajes de código manejado como JavaScript o bajo el prisma de .NET, con lenguajes de programación bien conocidos por todos, como son VB.NET y C#.
La bondad de WinRT es que permite escribir aplicaciones tanto para el chip Intel como para el chip ARM que como todos sabemos, consume hoy día menos recursos y energía que el primero de ellos.
Pero lo realmente interesante es que el espectro que cubre XAML se ha ampliado, o lo que es lo mismo, que podemos utilizar XAML para crear aplicaciones en WPF, en Silverlight o con C++, y por otro lado está HTML y Javascript. Es decir, más opciones, más posibilidades.
¿Y cómo es WinRT?
WinRT es una API basada en COM (Component Object Model) que podría ser definida como la plataforma encargada de servir aplicaciones Metro.
De hecho, WinRT ha sido diseñada para trabajar únicamente en sistemas operativos Windows 8 (y futuros sistemas operativos Windows si Microsoft lo considera oportuno).
El único "pero" de WinRT con respecto al desarrollo .NET con el que estábamos trabajando desde hace poco más de 10 años es que WinRT es meramente un consumidor de Servicios Web, pero no actuará como proveedor de Servicios Web tal y como podíamos hacer con .NET.
WinRT y Metro para el desarrollador
WinRT puede beneficiarse del diseño de aplicaciones Metro manejando estas desde un punto de vista gestual. Lo bueno de Metro, es que no nos impide utilizar dispositivos externos, de hecho, podremos utilizar gestos, ratones y/o teclados de acuerdo a nuestras necesidades.
Respecto a HTML 5, Microsoft ha querido apoyar de forma decidida el uso de aplicaciones HTML 5 gracias a un navegador que lo soporte, aunque Microsoft hace distinción entre aplicaciones HTML 5 y aplicaciones nativas HTML 5. Las aplicaciones nativas HTML 5 están relacionadas de forma estrecha con Windows 8, por lo que sus aplicaciones son dependientes de la tecnología y su portabilidad es bastante compleja.
Otro aspecto a tener en cuenta respecto al desarrollo de aplicaciones Metro basadas en WinRT es que todas las aplicaciones son asíncronas. El tiempo de respuesta entre la aplicación y el usuario debe ser muy pequeño (prácticamente insignificante), y no cumplir incluso este detalle puede hacer que nuestra aplicación no pase la correspondiente certificación.
La ejecución de una aplicación Metro se hace por su parte en lo que se conoce como sandbox o arenero. Cada aplicación es responsable de "sus" recursos. Cada aplicación sólo puede acceder a su "parcela" de memoria, asignada para que esa aplicación se encargue de gestionarla de forma independiente al resto de memoria del sistema. De esta manera, cada aplicación se aísla y no interfiere en el resto de aplicaciones, y si por cualquier cosa ocurriera un error inesperado, sólo afectaría a esa aplicación y no al sistema ni a ninguna otra aplicación que se estuviera ejecutando en el sistema.
Por otro lado, las definiciones de las APIs y otros detalles como el formato de los metadatos, etc., relacionados con el CLI (Common Language Infrastructure) están expuestas en la quinta edición del ECMA 335 (Diciembre 2010).
WinRT y .NET
Querría hacer dos preguntas muy rápidas que todos nos podemos hacer a la hora de abordar o plantearnos la posibilidad de crear un proyecto Software para WinRT.
¿Es WinRT el reemplazo de Win32?. Esta es quizás y sin duda alguna, la primera pregunta que podríamos hacernos realmente cuando vamos a empezar a desarrollar Software para Windows 8 y en su caso, para WinRT.
Supongamos (sin todavía dar una respuesta concreta a la primera pregunta) que WinRT fuera el reemplazo de Win32… ¿podremos seguir desarrollando aplicaciones para Windows 8 basándonos en Win32?. Esta sería la segunda pregunta que podríamos hacernos de forma natural partiendo de la primera pregunta.
Ante la primera pregunta, la respuesta es muy sencilla.
WinRT no reemplaza a .NET.
WinRT no compite con .NET.
WinRT no es una amenaza para .NET.
Ante la segunda pregunta, la respuesta es evidente y pone de manifiesto que las respuestas dadas a la primera pregunta son las que son.
Win32 sigue vivo en Windows 8, sin embargo, con Windows 8, Microsoft ha decidido exponer un pequeño subconjunto de las APIs y dar vía libre a través de WinRT a otra forma o modo de desarrollar aplicaciones.
El problema es que para arquitecturas ARM, no hay implementación alguna de Win32. Es decir, en arquitecturas ARM, sólo habrá soporte para WinRT.
En otras palabras. Si desarrollamos aplicaciones para Metro, podemos hacerlo a través de WinRT. Si lo que queremos es desarrollar aplicaciones clásicas, estilo Windows tal y como las hemos conocido hasta ahora, deberemos utilizar las APIs de Win32.
¿Y qué se requiere para poder desarrollar aplicaciones para Windows 8 con estilo Metro y sobre WinRT?
Sólo existen tres ingredientes, tiempo, dedicación e interés, aderezados lógicamente de un cuarto ingrediente, conocimientos, ingrediente este último que podrá conseguirse una vez más con los tres primeros ingredientes… es lo que me aventuro a bautizar como el círculo vicioso del desarrollador.
Windows App Store
De la misma manera en la que Apple o Google crearon sus tiendas de aplicaciones, Microsoft ha creado la suya, la cuál quiere impulsar de forma evidente tal y como ha hecho con su tienda de aplicaciones para Windows Phone.
En la App Store, Microsoft espera poder contar con innumerables aplicaciones tanto gratuitas como de pago. Los desarrolladores por nuestra parte, tenemos varias formas de obtener beneficios con nuestras aplicaciones, y no sólo tenemos la posibilidad de hacer de pago nuestras aplicaciones, sino incluso monetizar las mismas.
Referencias
7 Responsesso far
Hola Jorge,
“El único “pero” de WinRT con respecto al desarrollo .NET con el que estábamos trabajando desde hace poco más de 10 años es que WinRT es meramente un consumidor de Servicios Web, pero no actuará como proveedor de Servicios Web tal y como podíamos hacer con .NET.”
yo a esto no le veo peros es más siempre lo he concebido como un cliente o para que está azure, para servirle a el y a quien quiera, fíjate en la coincidencia:). Empezamos a tomar piezas del puzzle y al final coinciden los blancos con los negros
Totalmente de acuerdo Pedro.
No es un “pero” pensando en Windows Azure y de hecho por ahí creo yo que van los tiros, por Azure y por ASP (http://en.wikipedia.org/wiki/Application_service_provider) que lleva ya muchos años encima de la mesa, pero por otro lado, si eres desarrollador independiente, igual esto no es lo que te gustaría que fuera, a no ser que Microsoft permitiera certificar tu aplicación Metro y permitiera que lo descargara gente con autorización a hacerlo.
No estás mal encaminado en lo que dices creo yo, pero el “pero” al que me refiero es a como lo ven muchos ISVs y a como estaban acostumbrados a hacerlo.
Tal y como decía entre el post anterior de Metro y este, hay que cambiar el chip, es otra forma de hacer las cosas. 🙂
No consigo decidirme entre qué me gusta más: que esté basando en COM o que use XAML 🙂
Lo del sandbox, ¿es sólo a nivel de memoria? Lo digo porque eso existe desde WinNT. ¿Afecta también al sistema de archivos y demás recursos, como pasa en Windows Phone?
>¿Afecta también al sistema de archivos y demás recursos, como pasa en Windows Phone?
Sí 🙂
Digamos que cada aplicación tan solo puede acceder a sus datos propios (Local App Data), además de a ciertas carpetas “comunes” como documentos (siempre que haya pedido permisos para ello).
Para más info: http://lunarfrog.com/blog/2012/05/21/winrt-folders-access/
Saludos!
Gracias, Eduard.
Va a ser entretenido ver cómo conviven en la vida real la filosofía móvil (aplicaciones cerradas, con permisos limitados, compradas en una tienda de aplicaciones) y la filosofía PC.
Introducción En la entrada previa, vimos como crear un proyecto de Windows 8 Metro desde Visual
Utilizando componentes C# o VB con HTML5 JS y WinRT