Síguenos en...
Síguenos en Twitter Síguenos en Facebook Sigue nuestro canal YouTube
Registrarse
Compartir
+ Responder tema
Resultados 1 al 1 de 1

Tema: Llamando al API de WinRT desde aplicaciones de escritorio normales en C#

  1. #1
    Avatar de rfog
    Fecha de ingreso
    04 feb, 13
    Ubicación
    Alicante
    Mensajes
    11

    Llamando al API de WinRT desde aplicaciones de escritorio normales en C#

    Llamando al API de WinRT desde aplicaciones de escritorio normales en C#



    ¿Hay necesidad de ello?
    Personalmente creo que sí, aunque no es válido para todas las situaciones. Supongamos por un momento que estamos haciendo una versión de escritorio clásico de nuestra aplicación. Supongamos también que dicha versión se ejecutará en Windows 8, tanto en un ordenador como en una tableta, ya sea de tipo x86/x64 (que no es más que un PC con forma de tableta) o de RT PRO. Y ahora suponed que queréis, por ejemplo, acceder al API de sensores que solo se encuentra disponible para las aplicaciones RT.

    Quizás en este momento actual no sea muy necesario, pero podría existir la posibilidad de que, en un futuro, Microsoft implementara más cosas para la parte RT que no estén en la Win32…

    Pero esperad un momento, que esto requiere algo más de explicación.

    ¿RT, Win32?
    Hasta Windows 7 sólo había un Amo del Calabozo, que se llama Win32. Ese es el API de desarrollo nativo para Windows desde su primera versión. Cualquier programa, librería de terceros o lo que fuera, terminaba llamando a esas funciones. Incluso .NET. De hecho, .NET es una capa asentada sobre Win32, y de hecho, en cualquier momento se podía acceder a dicho API desde la mayoría de bibliotecas de terceros, incluso desde cosas tan exóticas como Visual Basic, Delphi, C++ Builder o QT.

    Luego vino Windows RT y Windows 8 y Microsoft cambió las reglas del juego, pero sólo un poco. En principio ahora hay dos API diferentes, la de Win32 tradicional que sigue estando disponible para las aplicaciones de escritorio y sobre la que corre el .NET tradicional, y una nueva basada en componentes COM y escrita en C++/CX, sobre la que se asienta la parte .NET compatible con RT.

    Es decir, y sólo en teoría y a efectos prácticos, ahora tenemos dos API para generar aplicaciones Windows:

    • Escritorio clásico: Win32 con .NET Framework y cualquier otra librería.
    • Escritorio moderno: C++/CX, .NET 4.5 for RT y un pequeño subconjunto de Win32.


    El hecho de que la parte RT también esté basada en Win32 no nos interesa porque no podemos acceder a ella si queremos poner nuestra aplicación en la Tienda.

    Por lo tanto, ahora tenemos dos juegos de funcionalidades para programar. Dependiendo del que elijamos, nuestra aplicación será:

    • De escritorio clásico que todos conocemos que funcionan en Windows 8 x86/x64 y RT PRO (que no deja de ser un x86/x64).
    • RT: Ocupan toda la pantalla y sólo se ejecutan en las tabletas puras o RT.


    ¿Dónde está la prohibición?
    Para crear aplicaciones RT, tenemos el citado API C++/CX y .NET 4.5 para RT (que está encima del API anterior), y un pequeño subconjunto de funciones Win32. Y no podemos usar otra cosa.

    Para crear aplicaciones de escritorio tenemos Win32 y .NET y cualquier otra cosa que hayamos estado usando hasta ahora. Pero, de forma oficial, no el API de RT.

    ¿Es un impedimento serio? No, claro que no, casi todo (por no decir todo), está disponible en Win32, pero podríamos querer usar algo de ese API, ya sea porque es más fácil y rápido de implementar que andar haciendo varias docenas de llamadas a funciones Win32 cuando en RT es utilizar una clase y tres métodos.

    ¿Nos lo impide alguien? Tampoco. No tenemos que pasar ningún tipo de certificación (como sí en RT), ni en general nadie nos va a exigir cuentas salvo los usuarios finales si nuestra aplicación es una porquería o se chupa la batería en un cuarto de hora. Por lo demás, somos libres de usar lo que queramos.

    Por lo tanto, vamos a usar el API de RT en una aplicación Win32 pura.

    ¿Qué tengo que hacer?
    En primer lugar, cierra Visual Studio y localiza el fichero .CSPROJ que guarda tu proyecto. Como es una cosa no documentada ni oficialmente sancionada por Microsoft, el IDE es incapaz de hacerlo.

    Porque si intentamos añadir la referencia de Windows RT Core, vemos que no está:

    Clic en la imagen para ver su versión completa. 

Nombre: 1.png 
Visitas: 2 
Tamaño: 173.1 KB 
ID: 25423

    Por lo tanto, una vez cerrado el IDE, abrimos el fichero citado y metemos la siguiente línea de texto:
    <targetplatformversion>8.0</targetplatformversion>

    ¿Dónde? Pues en el primer <TargetGroup> que veamos, aquél en donde también aparece la línea:

    Guardamos el fichero editado y volvemos a abrir Visual Studio. También podemos hacerlo mediante (Load/Unload Project) del menú contextual de Visual Studio sin necesidad de cerrar el IDE. Descargamos el proyecto, editamos el CSPROJ y lo volvemos a cargar.

    Ahora sí, ahora sí que aparece la pestaña “Windows” de la store:

    Clic en la imagen para ver su versión completa. 

Nombre: 2.png 
Visitas: 2 
Tamaño: 54.8 KB 
ID: 25424

    Marcamos ese ensamblado y ya podemos editar los sensores en nuestro código:


    private void Window_Loaded(object sender, RoutedEventArgs e)
    {
    var light = LightSensor.GetDefault();
    if (light == null)
    return;

    var minReportInterval = light.MinimumReportInterval;
    var reportInterval = minReportInterval > 16 ? minReportInterval : 16;
    light.ReportInterval = reportInterval;

    light.ReadingChanged += (s, a) => Sensor.Dispatcher.BeginInvoke((Action)(() =>
    {
    Sensor.Text=String.Format("Luz: {0}", a.Reading.IlluminanceInLux);
    }));
    }
    Para completar el ejemplo, tenemos que añadir un control de texto dentro del Grid principal de nuestra aplicación:

    <Grid>
    <TextBlock Name="Sensor" VerticalAlignment="Center" HorizontalAlignment="Center" />
    </Grid>
    No obstante, si intentamos compilar ahora, nos dará un error diciéndonos que el evento no está soportado por el sistema. Simplemente nos falta añadir alguna referencia más: System.Runtime y System.Runtime.InteropServices.WindowsRuntime, que están en la carpeta C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5.

    Una vez añadidos, compilamos y ejecutamos sin problemas.

    Fijaos que hemos tenido que hacer muchas cosas a mano. Lo más complicado es saber qué referencias tenemos que añadir, pero al final lo hemos conseguido. Lanzad la aplicación y subid o bajad las persianas de la habitación, o encended la luz y veréis cómo aparecen los cambios en el centro de la ventana… siempre y cuando tengáis un sensor de luz en vuestro equipo. En mi caso, funciona perfectamente en mi iMac con BootCamp.

    ¿Y si no quiero usar todo esto?
    Pues fácil, tienes el equivalente de todo esto de forma nativa aquí: Sensor API (Windows). Dado que se tratan de varios interfaces COM puros y duros, quizás valga la pena hacerlo de la forma anterior, sobre todo si estás usando C#, VB.NET ó C++/CLI.


    Fuente: Rafa Ontiveros (nuestro compañero RFOG)
    .NET o no .NET, esa es la cuestión

    Temas Similares en HTCSpain:
  2. Cuatro aplicaciones para manejar documentos ofimáticos desde los móviles y tablets - [sakeator]
  3. jailbreak sin chevron desde el movil sin tener k usar aplicaciones! - [rubenperucha]
  4. Instalar aplicaciones desde la SD - [sarapaula]
  5. Escritorio Remoto desde PDA --> PC - [infernozeta]
  6. Llamando a Tierra - [Yabet]
  7. Última edición por rubensaf; 10/03/2013 a las 21:47

 

 
+ Responder tema

Nuestros visitantes llegarón a esta página buscando:

Nadie llego aun a esta pagina desde un buscador:
SEO Blog

Etiquetas para este tema