Llevo utilizando la versión preview de Windows 8 desde su presentación en septiembre y durante este tiempo he podido introducirme en el nuevo mundo que se nos ha presentado con el desarrollo de aplicaciones Metro Style y Windows Runtime, el nuevo proveedor de servicios del sistema. Hace también unas semanas que estoy deseando escribir sobre mis experiencias y por fin me he decidido, así que en los próximos días iré compartiendo con todos vosotros una serie de entradas sobre el funcionamiento de Windows Runtimey sobre cómo desarrollar aplicaciones para la plataforma.

Para esta primera entrada he elegido un tema que se trató en unas de las charlas de la BUILD y que me resultó muy interesante porque a diferencia de otras charlas, en las que se mostraba cómo crear aplicaciones y en las que siempre veíamos WinRT como la API que podemos consumir desde cualquier lenguaje (Javascript, C++, C# y VB), Matt Merry (Program Manager del equipo de Windows Runtime Experience), en su charla, cambió el punto de vista y muestra cómo las aplicaciones trabajan con la infraestructura de Windows Runtime para ejecutarse. Sin duda, lo más interesante de esa presentación (que recomiendo que veáis) es la sesión de debug paso a paso que hace para ver cómo funciona el proceso de activación de una aplicación, pero eso lo dejaremos para más adelante, antes veamos qué es lo que sucede en el sistema cuando desplegamos nuestra aplicación.

Con Windows 8 tenemos un nuevo sistema de despliegue de paquetes mediante el cual podemos instalar o desinstalar aplicaciones de una forma simple, sin hacer cambios irreversibles en el sistema operativo y sin que haya una degradación del rendimiento del sistema. No vamos a entrar ahora en detalle sobre lo que contiene este paquete, pero basta decir de momento que es un contenedor que se utiliza para instalar nuestra aplicación en nuestra máquina local, en una para hacer pruebas o en el Windows Store. Sabiendo esto, tenemos por un lado el paquete que contiene nuestra aplicación y por otro lado tenemos el manifiesto del paquete (package manifest) que describe y contiene las propiedades para desplegar el paquete. Este fichero contiene información tan importante como el nombre de la aplicación a mostrar, el icono, las capacidades (características del sistema o dispositivos que la aplicación puede utilizar) o la página de inicio. Todos las aplicaciones Metro tienen este manifiesto, se trata de un fichero XML con el nombre Package.appxmanifest que podemos encontrar en el directorio raíz de nuestro proyecto.

Además Visual Studio 11 tiene un diseñador que nos permite ver todas las propiedades agrupadas en varias pestañas (Application UI, Capabilities, Declaration, Content URIs y Packaging).

Entrando en materia, para ver como una aplicación se instala necesitamos crear una antes, así que tenemos que crear un proyecto de aplicación JavaScript en blanco (al que llamaremos HelloWindows8). Una vez creado abrimos el package manifest y vamos a la última pestaña de todas (Package). Aquí vemos que tenemos varias propiedades, entre ellas aparecen Package Name, que por defecto tiene asigando un GUID, y Package Display Name, con el nombre del proyecto. Como he comentado antes, este fichero no es más que un fichero XML que podemos abrir, así que si pedimos ver el código, veremos algo como lo que aparece en la imagen. La propiedad Package Name se corresponde con el atributo Name del nodo Identity. También podemos ver un nodo llamado Application, describen el registro de la aplicación. Este nodo contiene un atributo Id. Para nuestra prueba, y para que sea más fácil identificar la aplicación, vamos a asignar el valor ‘HelloWindows8AppId’ al Id del nodo Application, ‘HelloWindows8’ al atributo Name del nodo Identity. Una vez guardados estos cambios y ejecutamos la solución, veremos que la aplicación se abre normalmente y que la aplicación ya aparece en el menu inicio, es decir, ya está registrada. ¿Pero qué es lo que ha sucedido?

Cada vez que ejecutamos mediante F5, Visual Studio compila y despliega la aplicación localmente. ¿Y que significa exactamente desplegar? Pues por muy sorprendente que pueda pareceder, al desplegar la aplicación se crean dos claves en el registro: un registro de extension y un registro de clase. Si abrimos el editor del registro y buscamos la clave HKEY_CURRENT_USERSoftwareClassesExtensionsContractId veremos toda la lista de contratos de Windows 8, y si expandimos el contrato Windows.Launch podremos ver toda la lista de aplicaciones registradas organizadas por PackageId (el valor de Identity junto con la versión), entre ellas la nuestra. Las aplicaciones Metro implementan contratos (Search, Share, PlayTo, etc.), que son como un tipo de acuerdo entre Windows y las aplicaciones Metro y que permite ejecutar diferentes acciones como compartir información entre aplicaciones, etc. Pues bien, estos registros de contrato son los registros de extensiones del sistema operativo que hemos visto y cuando hacemos clic en el Tile de nuestra aplicación estamos activando otro contrato, concretamente el contrato windows Launch. Si expandimos un nivel más veremos la clave ActivateClassId y dentro de esta clave tendremos HelloWindows8AppId.wwa (el Id que le asignamos en el nodo Application del manifiesto), que indica el registro de clase para esta extensión. Esta clase es el nombre de clase de Windows Runtime que el sistema operativo conoce sobre nuestra aplicación. Esta clase tiene otras propiedades (Description, DisplayName, Icon, Vendor), pero lo interesante es que, como dijimos antes, las clases está en otro clave.

Si abrimos la clave HKEY_CURRENT_USERSoftwareClassesActivatableClassesPackage, veremos todos los registros de clases también organizadas por el PackageId, y si abrimos el nuestro, veremos que hay una clave ActivatableClassId y dentro la clase de nuevo veremos el Id de aplicación (HelloWindows8AppId.wwa). Si miramos los valores veremos varios atributos que indican que tenemos ActivationType igual 1. Windows Runtime soporta dos tipo de activación: In Process y Out of process. ‘In Process’ indica que nosotros proveemos la DLL del proceso y ‘Out Of process’ indica que es el sistema quien la provee. El valor 1 indica que nuestra aplicación es ‘Out of process’ y, por lo tanto, necesitamos un servidor para hostear nuestra aplicación. Este servidor está registrado en la clave Server, si la abrimos veremos de nuevo el Id de Aplicación y tendremos todos los atributos necesarios para que el sistema pueda ejecutar nuestra aplicación: la clase a ejecutar, el path del EXE, los permisos, etc.

Todo esto lo veremos en una próxima entrada, donde veremos el proceso de activación de la aplicación. Hasta aquí este primer post sobre Windows Runtime en el que hemos visto, por un lado, como la instalación es declarativa y todas las aplicaciones tienen un manifiesto de paquete que contiene información para el despliegue. Y por otro lado tenemos el motor de despliegue (que en nuestro caso lo lanza Visual Studio) que despliega el catálogo de extensiones y el catálogo de clases y hemos visto como los registros de extensiones apuntan al registro de clases.

En próximas entradas veremos el siguiente paso, el debug de la activación, pero los más inquietos os podéis descargar una utilidad desde winrt.codeplex.com que os permitirá entre otras cosas ver la lista de aplicaciones instaladas y habilitar el debug de la activación del paquete.

Referencias:

Windows Runtime internals: understanding “Hello World”