Leer en inglés

Compartir a través de


Migración de Windows Runtime 8.x a UWP para E/S, dispositivo y modelo de aplicación

El tema anterior era Portar XAML y la interfaz de usuario.

El código que se integra con el propio dispositivo y sus sensores implica la entrada y la salida al usuario. También puede implicar el procesamiento de datos. Sin embargo, este código no suele considerarse como la capa de interfaz de usuario o la capa de datos. Este código incluye la integración con el controlador de vibración, el acelerómetro, el giroscopio, el micrófono y el altavoz (que se intersecan con el reconocimiento de voz y la síntesis), la ubicación (geo)y las modalidades de entrada, como la entrada táctil, el mouse, el teclado y el lápiz.

Ciclo de vida de la aplicación (administración de la duración del proceso)

En el caso de una aplicación universal 8.1, hay una ventana de "desbounce" de dos segundos entre la aplicación que se vuelve inactiva y el sistema genera el evento de suspensión. El uso de esta ventana de desbounce como tiempo adicional para suspender el estado no es seguro y, para una aplicación de Plataforma universal de Windows (UWP), no hay ninguna ventana de desbounce en absoluto; el evento de suspensión se genera en cuanto una aplicación se vuelve inactiva.

Para obtener más información, consulta Ciclo de vida de la aplicación.

Audio en segundo plano

Para la propiedad MediaElement.AudioCategory , ForegroundOnlyMedia y BackgroundCapableMedia están en desuso para las aplicaciones de Windows 10. En su lugar, use el modelo de aplicación de Windows Phone Store. Para obtener más información, vea Audio en segundo plano.

Detección de la plataforma en la que se ejecuta la aplicación

La forma de concebir la selección de destinos de aplicación cambia con Windows 10. El nuevo modelo conceptual es que una aplicación tiene como destino el Plataforma universal de Windows (UWP) y se ejecuta en todos los dispositivos Windows. Después, puede optar por iluminar características exclusivas de familias de dispositivos particulares. Si es necesario, la aplicación también tiene la opción de limitarse a dirigirse específicamente a una o varias familias de dispositivos. Para obtener más información sobre qué son las familias de dispositivos y cómo decidir a qué familia de dispositivos dirigirse, consulta Guía para aplicaciones para UWP.

Si tiene código en la aplicación Universal 8.1 que detecta en qué sistema operativo se está ejecutando, es posible que tenga que cambiarlo en función del motivo de la lógica. Si la aplicación pasa el valor y no actúa en él, es posible que quiera seguir recopilando la información del sistema operativo.

Nota Se recomienda no usar el sistema operativo o la familia de dispositivos para detectar la presencia de características. La identificación del sistema operativo o la familia de dispositivos actual no suele ser la mejor manera de determinar si existe una característica de familia de dispositivos o sistema operativo determinado. En lugar de detectar el sistema operativo o la familia de dispositivos (y el número de versión), pruebe la presencia de la propia característica (consulte Compilación condicional y código adaptable). Si necesita un sistema operativo o familia de dispositivos determinado, asegúrese de usarlo como una versión mínima admitida, en lugar de diseñar la prueba para esa versión.

 

Para adaptar la interfaz de usuario de la aplicación a diferentes dispositivos, hay varias técnicas que recomendamos. Siga usando elementos de tamaño automático y paneles de diseño dinámicos como siempre lo tiene. En el marcado XAML, sigue usando tamaños en píxeles efectivos (anteriormente píxeles de vista) para que la interfaz de usuario se adapte a diferentes resoluciones y factores de escala (consulta Píxeles efectivos, distancia de visualización y factores de escala). Y usa los desencadenadores y establecedores adaptables de Visual State Manager para adaptar la interfaz de usuario al tamaño de la ventana (consulta Guía de aplicaciones para UWP).

Sin embargo, si tiene un escenario en el que es inevitable detectar la familia de dispositivos, puede hacerlo. En este ejemplo, usamos la clase AnalyticsVersionInfo para navegar a una página adaptada para la familia de dispositivos móviles cuando corresponda y nos aseguramos de revertir a una página predeterminada de lo contrario.

   if (Windows.System.Profile.AnalyticsInfo.VersionInfo.DeviceFamily == "Windows.Mobile")
        rootFrame.Navigate(typeof(MainPageMobile), e.Arguments);
    else
        rootFrame.Navigate(typeof(MainPage), e.Arguments);

La aplicación también puede determinar la familia de dispositivos en la que se ejecuta desde los factores de selección de recursos que están en vigor. En el ejemplo siguiente se muestra cómo hacerlo de forma imperativa y el tema ResourceContext.QualifierValues describe el caso de uso más típico para la clase en la carga de recursos específicos de la familia de dispositivos en función del factor de familia de dispositivos.

var qualifiers = Windows.ApplicationModel.Resources.Core.ResourceContext.GetForCurrentView().QualifierValues;
string deviceFamilyName;
bool isDeviceFamilyNameKnown = qualifiers.TryGetValue("DeviceFamily", out deviceFamilyName);

Además, consulte Compilación condicional y código adaptable.

Location

Cuando una aplicación que declara la funcionalidad Ubicación en su manifiesto de paquete de aplicación se ejecuta en Windows 10, el sistema solicitará al usuario final su consentimiento. Esto es cierto si la aplicación es una aplicación de Windows Phone Store o una aplicación de Windows 10. Por lo tanto, si la aplicación muestra su propio aviso de consentimiento personalizado, o si proporciona un botón de alternancia desactivado, querrá quitarlo para que el usuario final solo se le solicite una vez.