Aplicaciones optimizadas para Continuum en dispositivos móviles

Con Windows 10 tienen la productividad de una PC en el bolsillo. Continuum para sus teléfonos les permite conectar un dispositivo móvil de Windows a cualquier pantalla externa con el nuevo Microsoft Display Dock, USB-C o Miracast. Una vez conectados, pueden interactuar con las aplicaciones de Windows 10 en esa pantalla mientras usan su dispositivo móvil. Para los desarrolladores esto significa la aplicación de la Plataforma Universal de Windows (UWP, por sus siglas en inglés) se puede utilizar en cualquier pantalla, en cualquier momento. Por defecto, todas las aplicaciones de Windows 10 UWP que se ejecutan en un dispositivo móvil de Windows se habilitarán para Continuum. Para garantizar la buena apariencia y funcionamiento en Continuum, consideren lo siguiente:

1. Construir aplicaciones con capacidad de respuesta

2. Elegir la correcta familia de dispositivos

3. Incluir activos a escala adicionales

4. Crear experiencias multi-pantalla

Construir aplicaciones con capacidad de respuesta

Usar técnicas con capacidad de respuesta asegurará que su aplicación funcione muy bien en cualquier tamaño de pantalla, independientemente de la familia de dispositivos de Windows. No hay APIs o herramientas específicas para Continuum, cuando su aplicación está activada o se mueve a la pantalla conectada, su aplicación simplemente recibirá un evento SizeChanged, algo  similar a cuando se cambia el tamaño de una ventana de escritorio. Cuando este sea el caso, asegúrense de que su aplicación se ajusta según sea necesario para optimizarse en el tamaño requerido. En general, los usuarios deben ver una interfaz de usuario optimizada para el teléfono al usar su aplicación en sus dispositivos móviles, y una interfaz de usuario de escritorio optimizada al utilizar Continuum para emplearla en la pantalla conectada. Ten en cuenta que los usuarios pueden interactuar con la pantalla conectada con un teclado y un ratón, o la aplicación touchpad Continuum en el dispositivo móvil (que imita a un touchpad de precisión).

Con el hardware de hoy en día, se da por hecho que su aplicación se ejecuta en una pantalla conectada si la resolución efectiva es mayor o igual a 800 × 600 de píxeles efectivos. Ve la publicación Diseño con capacidad de respuesta para principiantes en aplicaciones de la Plataforma Universal Windows para obtener detalles sobre los píxeles efectivos y técnicas de capacidad respuesta para todas las aplicaciones UWP.

Herramientas para aplicaciones XAML con capacidad de respuesta

Una gran cantidad de herramientas con capacidad de respuesta están disponibles para los desarrolladores de XAML. Lean “Hagan que su aplicación luzca increíble en cualquier tamaño de pantalla o ventana” para más detalles, sin embargo, aquí están algunas de las herramientas disponibles:

La clase RelativePanel les permite anclar elementos de interfaz de usuario respecto de otra y del recipiente, de tal manera que vuelvan a funcionar en cualquier tamaño de pantalla.

La clase WrapGrid  hace que sea fácil para envolver imágenes y texto en una cuadrícula de acuerdo con el tamaño de la ventana.

El tipo SplitView  se puede utilizar para crear una experiencia de navegación de nivel superior, ajustada de acuerdo con el tamaño de la ventana.

Por último, la clase VisualStateManager permite definir estados visuales que corresponden a ciertas condiciones, tales como tamaño de la ventana o adaptar lanzadores como el tipo de entrada.

API UserInteractionMod

La API UserInteractionMode API les da contexto sobre el factor de forma de la pantalla en la que su aplicación se está ejecutando. Devuelve “ratón” cuando la interfaz de usuario del dispositivo está optimizado para la entrada del ratón y “toque” cuando la interfaz de usuario del dispositivo está optimizado para la entrada táctil. Estos rendimientos no describen el método de entrada actual, sino más bien optimiza la ejecución y la protección de la aplicación.

Con Continuum, “toque” siempre será devuelto cuando su aplicación es en el dispositivo móvil, y “ratón” siempre será devuelto cuando su aplicación está con la pantalla conectada. UserInteractionMode sólo cambiará cuando se mueve su aplicación entre las pantallas. UserInteractionMode no envía eventos – necesitarán consultar esta API al recibir un evento SizeChanged. Tengan en cuenta que UserInteractionMode también se utiliza para informar a los desarrolladores cuando un dispositivo de escritorio es en modo tablet – Continuum no es el único caso de uso.

Aquí hay un ejemplo de cómo puede utilizar UserInteractionMode en C # para cambiar entre una vista móvil y una vista de escritorio para Continuum.

Nota: En Continuum, las aplicaciones son en única instancia –una app sólo puede ejecutarse en una pantalla a la vez (excepto con escenarios multi-pantalla como se describe a continuación). Estas ilustraciones de lado a lado muestran cómo la aplicación se adapta a través de las pantallas.

Familia de dispositivos móviles

Si bien se recomienda la familia de dispositivos universales en lo posible, entendemos que muchos desarrolladores provienen del desarrollo solo para dispositivos móviles. Si su aplicación sólo se dirige a la familia de dispositivos móviles, pueden incorporar técnicas con capacidad de respuesta y obtener algún comportamiento de re-direccionamiento básico de manera gratuita. Esto hará que su aplicación funcione mejor en una pantalla conectada.

Por ejemplo, la siguiente aplicación de fotos fue construida sólo parar la familia de dispositivos móviles. Sin embargo, debido a que el desarrollador aprovechó las clases RelativePanel y WrapGrid para definir cómo su aplicación responde a diferentes tamaños de teléfono y orientaciones, su contenido respondió de forma automática y se aprovechó de los tamaños más grandes de pantalla conectados.

Si quieres que su aplicación móvil se vea aún mejor en Continuum, pueden utilizar las técnicas de capacidad de respuesta descritas anteriormente para optimizar aún más el diseño de la pantalla grande de su aplicación. Si encuentran que la construcción de componentes de interfaz de usuario o que las vistas de aplicaciones son nuevas para Continuum, sugerimos dirigirlas a la familia de dispositivos universales para que se pueda visualizar en todos los dispositivos de Windows.

Consideraciones para paquetes móviles y de escritorio separado

Si son desarrolladores con paquetes separados dirigidos a las familias de dispositivos móviles y de escritorio, los usuarios sólo tendrán el comportamiento de su aplicación móvil cuando la usen en Continuum. Sin embargo, se puede mejorar la manera en que su aplicación funciona en Continuum aportando puntos de vista y/o activos de su aplicación de escritorio para la versión móvil, y visualizarla cuando sea apropiado.

Por ejemplo, el navegador de Microsoft Edge carga dinámicamente una vista de escritorio o vista móvil dependiendo de la pantalla en la que la aplicación se está ejecutando. Debido a que una vista de escritorio ya existía, Edge fue capaz de agregar componentes de interfaz de usuario deseados para la aplicación móvil, con el fin de que se use en la pantalla conectada en lugar de reconstruirla.

Pueden utilizar los desencadenantes como una resolución efectiva o UserInteractionMode para determinar cuando mostrar la vista de escritorio frente a la vista móvil. Vean el siguiente fragmento de código en la sección UserInteractionMode como para cambiar entre una vista móvil y de escritorio en caso de SizeChanged. También pueden hacer referencia a la clase VisualStateManager  para más información sobre la construcción de los factores desencadenantes.

La opción de la pantalla conectada

Si su aplicación móvil no está lista para Continuum de inmediato, no se preocupen. Sólo tienen que añadir las siguientes líneas a su manifiesto para bloquear su aplicación en la pantalla conectada. Realizar este cambio hará que su mosaico de la aplicación quede en gris en el menú Inicio de la pantalla conectada hasta que se activa. Si el usuario intenta lanzar su aplicación en la pantalla conectada mientras se está en gris, verán lo siguiente:

El espacio de nombre que se añade a la etiqueta de <Package>:

El dispositivo móvil generalmente tendrá una escala de 200 a 400. La pantalla conectada lo más probable es que tenga una escala de 100 (la mayoría de los monitores) o 150 (la mayoría de los televisores). Cuando el usuario descarga su aplicación desde la tienda, una única escala de activos se desplegará la pantalla del dispositivo móvil al dispositivo móvil de forma predeterminada. Después de esto, una actualización de la aplicación se activará cada vez que el usuario se conecta a un monitor externo con un nuevo factor de escala. Esta actualización se tira abajo los mejores activos para la nueva pantalla. Si los mejores activos ya están en el dispositivo móvil, entonces ninguna actualización es necesaria.

Por ejemplo, digamos que tienen un dispositivo móvil a escala-300 y la escala-100 en monitor. Cuando las aplicaciones se están ejecutando en el monitor, requieren utilizar la escala-100. La primera vez que el usuario se conecta a este monitor, ninguna de las apps tendrá activos a escala-100 disponibles porque estos no están desplegados para el dispositivo móvil por defecto, así que se usarán los siguientes mejores activos (escala-300). Tras la conexión, el sistema consultará todas las aplicaciones UWP descargadas por el usuario para ver cuáles tienen activos disponibles mejor escalados, y una actualización se activará para derribar esos activos. En algunos casos, esto puede significar que la escala-150 o la escala-200 se marcan si los activos escala-100 no están disponibles. Una actualización se activará para derribar esos activos. El sistema aplicará de forma automática los activos mejor escalados a cada pantalla de forma independiente. Para ahorrar espacio, se eliminan los activos de pantallas que están inactivos durante más de 30 días.

Adición y referencia de recursos a escala

Para apoyar más factores de escala, sólo se tiene que incluir más recursos escala en su solución de aplicación. Existen dos maneras de hacer esto.

1. Añadir nuevos recursos con la notación .scale-xxx en una carpeta de “Activos”.

 

 

 

 

 

 

 

 

 

 

2. Añadir nuevas carpetas de recursos escala, con los activos con nombres idénticos en cada carpeta.

 

 

 

 

 

 

 

 

 

 

 

Si utilizan una de estas dos opciones, pueden hacer referencia al recurso deseado con un URI (dejando de lado “xxx-scale”) y el sistema tomará el activo más reducido para una pantalla determinada. Por ejemplo: “ms-appx:///Assets/Logo.png” o “ms-appx:///desktop.png”. Una etiqueta en XAML podría tener este aspecto: <Image x:Name=“LogoImage” Source=“ms-appx:///Assets/Logo.png”/>.

Crear experiencias multi-pantalla

Con las APIs UWP, pueden tomar ventaja del dispositivo móvil y de la pantalla conectada simultáneamente.

Integración de medios

Puedes utilizar capacidad de inclusión incorporada del control MediaElement para mostrar un elemento multimedia en la pantalla conectada, mientras que su aplicación queda en la pantalla principal. Simplemente alimenta el elemento de soporte deseado al sistema y ​​Windows crea una vista y desempeña ese elemento multimedia en la pantalla conectada.

He aquí un ejemplo de cómo puede aprovechar el control MediaElement:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

//Create a casting picker CastingDevicePicker picker = new CastingDevicePicker();    //Filter it to only videos picker.Filter.SupportsVideo = true;   //Add the event listener for the device selected event. picker.CastingDeviceSelected += picker_DeviceSelected; async void button_Clicked(object sender, RoutedEventArgs args) {   //Show the selection UX when the button is pressed   await picker.Show(new Rect(0, 0, 5, 5), new Placement.Above); } void picker_DeviceSelected(CastingDevicePicker sender, CastingDeviceSelectedEventArgs args) {   //Get the selected device from the arguments   CastingDevice selectedDevice = args.SelectedDevice;                //use the casting device as desired   await selectedDevice.RequestStartCastingAsync(mediaElementVideo.GetAsCastingSource()); }

Clase ProjectionManager

La clase ProjectionManager te permite crear experiencias ricas y múltiples pantallas interactivas. Es fácil comenzar y terminar las sesiones de múltiples vistas, donde tienen control total sobre la vista en cada pantalla. Aquí hay algunas pautas adicionales. Porque no se puede garantizar que el usuario tiene un teclado y un ratón, deben asumir que la vista en el dispositivo móvil (vista interna) debe controlar totalmente la vista en la pantalla conectada (vista proyectada).

Como ejemplo, Microsoft PowerPoint aprovecha la clase ProjectionManager para crear una robusta experiencia de la presentación multi-pantalla, impulsado por un dispositivo móvil. La vista en el dispositivo móvil contiene una vista previa de diapositivas, notas y una herramienta de selección de diapositivas. Con este tipo de visualización, el usuario tiene el control completo de las diapositivas que muestra en la pantalla conectada.

Aquí está un ejemplo de cómo puede aprovechar ProjectionManager paracrear una experiencia multi-pantalla:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

private async void StartProjecting_Click(object sender, RoutedEventArgs e) {    //Check whether there is already active connection to an external display    if (ProjectionManager.DisPlayAvailable)    {       int thisViewId;       thisViewId = ApplicationView.GetForCurrentView().Id;         var thisDispatcher = Window.Current.Dispatcher;       await CoreApplication.CreateNewView().Dispatcher.RunAsync(CoreDispatcherPriority.Normal,()=>       {          // Display the page in the view. Not visible until “StartProjectionAsync” called          var rootFrame = new Frame();          rootFrame.Navigate(typeof(ProjectionViewPage), initData);          Window.Current.Content = rootFrame;          Window.Current.Activate();       });         // Show the view on a second display       await ProjectionManager.StartProjectingAsync(rootPage.Id, thisViewId);    } }   private async void StopProjecting_Click(object sender, RoutedEventArgs e) {    await ProjectionManager.StopProjectingAsync(rootPage.ProjectionViewPageControl.Id,thisViewId); }

Comienza a construir

La mayoría de los desarrolladores que crean aplicaciones UWP con capacidad de respuesta que se ejecutan en los dispositivos móviles no tendrán que hacer ningún trabajo para apoyar Continuum. Pero, por supuesto, cada aplicación es única por lo que recomendamos probar y validar el funcionamiento de su aplicación en este escenario.

He aquí un resumen de lo que debe considerar para Continuum, y algunos recursos adicionales.

1. Lo más importante, utilizar técnicas de capacidad de respuesta para garantizar su que su aplicación se ajusta maravillosamente a cualquier pantalla. Al alinearse a la familia de dispositivos universales se beneficiarán más de Continuum y en todos los dispositivos de Windows.

2. Recuerden que los usuarios probablemente interactúen más con su aplicación en la pantalla conectada al teclado y ratón. Consideren la posibilidad de implementar y probar la interfaz de usuario optimizada para el teclado y el ratón si su aplicación funciona principalmente al dar toques en la pantalla.

3. Incluyan los activos a escala adicionales en su paquete de aplicaciones para hacer perfecto el pixel de su aplicación en cualquier pantalla. La mayoría de las pantallas de un usuario pueden conectarse a escala-100 o escala-150.

4. Aprovechar APIs multi-pantalla para crear robustas, variadas e interactivas experiencias multi-pantalla.

Para aprender cómo configurar, echa un vistazo a Microsoft Display Dock y otro hardware en microsoft.com, el inalámbrico  Actiontec ScreenBeam Mini2 Continuum Edition y lean acerca de configuraciones Continuum para hardware de teléfonos.

¡Esperamos que ya estén usando sus aplicaciones en Continuum!

 

Escrito por Liz Threlkeld, gerente de programación en Windows