Windows 10
Introducción a la creación de aplicaciones Windows para dispositivos de Windows 10
Descargar el código de muestra
Ha vivido para verlo: un único SO Windows que se puede ejecutar en todos los tipos de dispositivos Windows. Tiene una plataforma de dispositivo único para habilitar a los verdaderos controladores de hardware universales y una única plataforma de aplicaciones para habilitar verdaderas aplicaciones Windows universales. Tras años de preparación, esto es un logro importante de ingeniería.
En el nivel de sistema operativo, esto significa una base de código única, fácil de mantener y ágil. Para los desarrolladores, proporciona una superficie de API unificada y confiable en todos los dispositivos de Windows, desde dispositivos del Internet de las cosas (IoT) como la Raspberry Pi hasta el teléfono, la Xbox, la tableta, el Surface Hub, el portátil, el PC, etc. (como Microsoft HoloLens). Como se muestra en la Figura 1, es una promesa de "crear una vez y ejecutar en cualquier lugar" entregada en Windows 10 con la plataforma de aplicaciones universales (UAP).
.png "La plataforma de aplicaciones universales permite las aplicaciones en todas las familias de dispositivos de Windows")
Figura 1 La plataforma de aplicaciones universales permite las aplicaciones en todas las familias de dispositivos de Windows
El viaje hacia Windows 10
La convergencia de Windows ha llevado mucho tiempo. En 2011 Microsoft tenía tres plataformas con tres sistemas operativos. El sistema operativo de servidor y PC era Windows, basado en código base de Windows NT. El sistema operativo de teléfono era Windows Phone, un derivado de Windows CE con similitudes de nivel de superficie con Windows NT, pero un código base diferente. El SO de la Xbox 360 era Windows NT, pero era una bifurcación de 10 años tan divergente que también era un código base distinto.
En ese momento, Microsoft trabajaba para llevar un Internet Explorer común a cada plataforma. No había Windows Core, ninguna plataforma Windows ni UAP. La implementación de Internet Explorer en estos tres sistemas operativos fue correcta, pero requería considerables malabares de ingeniería.
Con Windows Phone 8, el kernel del sistema operativo de Windows NT reemplazó a Windows CE en los teléfonos. Esta convergencia hizo avanzar las cosas hacia un código de base único. Windows, Windows Phone y Xbox 360 aprovecharon el mismo kernel, aunque cada uno de ellos todavía tenía bases de código únicas. En 2013, la Xbox One se lanzó al mercado y con ella un núcleo de SO compartido con Windows 8. Microsoft estaba tan cerca de una base de código única que hasta se podía percibir, pero todavía mantenía tres sistemas operativos distintos.
Windows 10 fue la oportunidad de reunirlos y de hacer converger los esfuerzos de ingeniería. Sin embargo, al mismo tiempo, las nuevas aplicaciones de tecnología exigían la adición de más destinos de Windows: IoT, Microsoft HoloLens, Surface Hub y futuros miembros de la familia de dispositivos de Windows. Windows 10 necesitaba ser un sistema operativo no solo para Windows Phone y Xbox, sino también para todas las plataformas futuras.
Microsoft lo ha logrado. Windows 10 se ha convertido en un sistema operativo de núcleo de superficie pequeña que se ejecuta en todas las familias de dispositivos. Esto no era tan sencillo como Archivo | Guardar como. Personas inteligentes trabajaron duro para ofrecer una maravilla de ingeniería en un plazo de tiempo increíble. Windows 10 es el único código de base necesario para habilitar la UAP. Todos los productos de Microsoft a partir de este momento en adelante se escribirán en el núcleo único que compone Windows 10.
Unidad, no uniformidad Unificar las bases de código a un solo sistema operativo de núcleo no implica una interfaz de usuario única en diferentes dispositivos. Windows Phone tiene una interfaz inteligente, muy apreciada y de una sola mano significativamente distintiva de la experiencia de Xbox de de 10 pies. Lo mismo ocurre con el Surface Hub, Microsoft HoloLens y la Raspberry Pi. Estos ofrecen la mayor parte de su valor a través de sus experiencias únicas. Aún así, el sistema operativo con sus bibliotecas, tiempo de ejecución y marcos, es el mismo. La plataforma de dispositivos y la plataforma de aplicaciones son los mismos. Sin embargo, la interfaz de usuario y las características de shell son distintas y adaptadas al modelo de uso correcto para cada dispositivo. Estas no son las mismas.
En teoría, alguien podría arrancar en este sistema operativo principal e incluso ejecutar aplicaciones, pero no lo hará nadie nunca porque simplemente es un bloque de creación. Para ser compatible adecuadamente con cada factor de forma, se agregan componentes de shell específicos de dispositivos al sistema operativo de núcleo, como el menú Inicio, la compatibilidad específica de HID y cualquier parte y elemento necesarios para habilitar las características específicas de dispositivos, como las aplicaciones de escritorio. Estos componentes adicionales se crean desde el sistema operativo básico para formar los diferentes SKU de sistema operativo que ves como productos de Microsoft, como Windows, Server, Xbox y HoloLens.
Plataforma de una aplicación Este es un juego divertido para jugar con tus amigos. Diles que vas a adoptar las últimas innovaciones de aplicaciones de Microsoft, pero que no tendrás como destino Windows 10. ¿Cómo? Las aplicaciones Windows de última generación no tendrán como destino el sistema operativo. En su lugar, tendrán como destino la plataforma de aplicación. En Windows, la UAP es un modelo de aplicación coherente y con la superficie de la API garantizada en todos los dispositivos de Windows.
UAP no es un tiempo de ejecución. Una aplicación Windows, incluso una escrita en un lenguaje administrado (como Visual Basic o C#) se compila hasta el final como cualquier otra aplicación. No se ejecuta dentro de un tiempo de ejecución. No requiere un tiempo de ejecución. UAP es una superficie de API común entre dispositivos, por lo que tener como objetivo la UAP es tener como objetivo una versión y conjunto específico de API.
Vale la pena señalar que crea juegos y aplicaciones Windows con las herramientas y tecnologías que ya conoce. Las aplicaciones Windows escritas en lenguajes administrados seguirán disfrutando de Microsoft .NET Framework, que a su vez es solo un conjunto de interfaces, clases base y métodos auxiliares. El subconjunto del .NET Framework completo que se usa en aplicaciones administradas que tienen como objetivo la UAP se denomina .NET Core. A modo de complemento, la mayoría de las API que utiliza en aplicaciones que tienen como destino la UAP se encuentran en Windows en tiempo de ejecución, que se proyecta en todos los idiomas, no solo en los lenguajes administrados.
No es solo XAML En este artículo se mostrará una aplicación XAML, pero las aplicaciones DirectX y JavaScript (aplicaciones web de Windows) también se admiten en la UAP, exactamente de la misma manera que en Windows 8. Dicho eso, resulta fascinante mirar el tema emergente de XAML. XAML es importante para muchas plataformas de Microsoft: Windows Presentation Foundation (WPF), Silverlight en el explorador y en Windows Phone, y ahora en la plataforma de la interfaz de usuario de Windows (que empezó con el nombre en código "Jupiter").
Microsoft Office 2016 es ahora una familia de aplicaciones UAP. ¿Qué tecnología de interfaz de usuario usa? XAML. Gracias a esta relación, la plataforma XAML está llena de características y controles que Microsoft y otros fabricantes, como usted, pueden usar en sus aplicaciones Windows.
El shell de escritorio de Windows presenta muchas características nuevas, como el menú Inicio y el centro de actividades. ¿Qué tecnología de interfaz de usuario usa? XAML. Gracias a esta relación, la plataforma XAML tiene un excelente rendimiento y ofrece capacidades de representación para obtener un segundo nivel de rendimiento si se aprovecha.
En lo referente a XAML, Microsoft está en todo. Muchas importantes aplicaciones de sistema operativo, como Fotos y aplicaciones MSN, como Salud y Bienestar, dependen de la plataforma de interfaz de usuario de XAML que ofrece las mismas características enriquecidas que todos los desarrolladores pueden aprovechar en sus aplicaciones Windows. Lo que ve en las aplicaciones Microsoft también lo puede hacer usted. No solo el área de superficie de la API es igual para todos los usuarios, también lo es la plataforma de interfaz de usuario de XAML.
Valor para los desarrolladores de software No es suficiente escribir una aplicación que se pueda ejecutar en todos los dispositivos. Para ofrecer un valor real a los usuarios, su aplicación Windows debe poder funcionar en diferentes dispositivos. Gracias a la extensibilidad de la UAP, puede incluir código específico del dispositivo en un archivo binario único que se ejecutará en todos los dispositivos.
Obtiene más de un único binario con la UAP; también obtendrá una Tienda para todo: para el teléfono, la tableta, el escritorio e incluso aplicaciones de Xbox. Se ha simplificado la experiencia y la monetización, así como las métricas para supervisar el éxito del mercado.
Esa única Tienda y la plataforma le permiten implementar activos de manera adecuada. Esto significa que los activos destinados a la experiencia de Xbox no se desplazarán al teléfono. Y la capacidad de Windows 8 para empaquetar activos que tienen como destino escala y soluciones específicas permanecerá en la UAP.
Como siempre, mantiene el control. Simplemente porque la UAP es compatible con todos los dispositivos Windows, no significa que tenga que hacerlo. Elija qué familia de dispositivos será compatible con la aplicación Windows. Si su aplicación Windows es solo para teléfono, solo para Xbox o solo para HoloLens, depende de usted. La Tienda Windows garantiza que la aplicación se entrega a las familias de dispositivos que seleccione.
El valor para usted no tiene simplemente un alcance mayor, sino que también es una experiencia global más sencilla. Hay un conjunto de herramientas, incluidas Visual Studio y Blend para Visual Studio, que ya conoce y de la que disfruta. Hay un conjunto conocido de lenguajes, incluidos JavaScript, .NET Framework (Visual Basic o C#) y C++ / CX. Al final, usted y su equipo crean aplicaciones Windows con lo que ya conoce.
Bastante que tener en cuenta
Un gran poder conlleva una gran responsabilidad. La UAP permite a las aplicaciones Windows ejecutarse en cada tipo de dispositivo de Windows. Esto es impresionante, pero viene con una salvedad: No todos los dispositivos proporcionan la misma experiencia de usuario. Esto significa que, aunque puede emplear muchas de las mismas técnicas de diseño web con capacidad de respuesta (RWD) que usa en sus aplicaciones web, debe considerar cómo se desarrolla el flujo de trabajo de aplicaciones Windows en diferentes tipos de dispositivos destinados para diferentes tipos de uso. La UAP solo puede habilitar la compatibilidad en diferentes dispositivos; depende del programador y del diseñador la creación de una experiencia de usuario que sea excelente en todos ellos.
Microsoft proporciona herramientas más amplias para ayudar a crear aplicaciones Windows con capacidad de respuesta y adaptables. Visual Studio puede simular la relación de aspecto, la escala y el tamaño durante el tiempo de diseño. Visual Studio puede simular también (y a veces emular) destinos de dispositivos específicos incluso si no posee el hardware. Esto le permite probar aplicaciones Windows y hacer más elegantes sus experiencias por el camino.
El cuadro de herramientas XAML tiene varias mejoras y controles para ayudarle a crear interfaces con capacidad de respuesta y adaptables que tienen un aspecto excelente en todos los dispositivos y en todos los tamaños de pantalla. Por ejemplo, el RelativePanel es nuevo para los desarrolladores de XAML. Hereda del Panel como cualquier otro control de diseño, como Grid y StackPanel, pero permite a los diseñadores y desarrolladores colocar elementos secundarios en relación con los demás elementos secundarios. El árbol visual de XAML resultante es más sencillo de representar y mucho más sencillo de manipular en respuesta a los cambios de diseño. Los estados visuales son otra mejora para los desarrolladores XAML, lo que facilita la respuesta a los cambios de diseño.
Esto es importante: La creación de una aplicación de Windows que tenga como destino varios dispositivos no implica la escritura en el mínimo común denominador. La interfaz de usuario es enriquecida, al igual que el conjunto de características. La comprobación en tiempo de ejecución (mediante el espacio de nombres Windows.Foundation.Metadata.ApiInformation) le permite incluir las capacidades específicas de dispositivo que refinan sus aplicaciones para lograr la mejor experiencia de usuario posible en cada dispositivo. Nuevas características y controles convergentes son los bloques de creación que necesita para soñar a lo grande.
Anatomía de una aplicación de Windows
Echemos ahora un vistazo a las técnicas esenciales para crear una aplicación Windows que se ejecutará en cualquier familia de dispositivos. Suponemos que está familiarizado con el desarrollo de aplicaciones XAML de Windows en tiempo de ejecución (WinRT) de Windows 8.1. Las aplicaciones Windows son la evolución de dichas aplicaciones. Encontrará muchos recursos de aprendizaje en Microsoft Virtual Academy, que puede encontrar en aka.ms/w8learn. En este artículo se centra en las nuevas características de la UAP: para ejecutar aplicaciones Windows a través de familias de dispositivos.
En Visual Studio 2015, el nodo Templates/Visual C#/Windows Universal del cuadro de diálogo Nuevo proyecto tiene varias plantillas de proyecto: la Aplicación vacía, la biblioteca de clases y el componente de Windows en tiempo de ejecución. Utilice la plantilla de Aplicación vacía para crear una aplicación Windows. Las plantillas de biblioteca de clases y el componente de Windows en tiempo de ejecución le permiten encapsular la interfaz de usuario y la lógica para su reutilización en otros proyectos. Una biblioteca de clases es compatible con aplicaciones que no son de UAP, pero se limita a lenguajes administrados; los componentes de Windows en tiempo de ejecución se pueden compartir entre lenguajes (que incluyen JavaScript y C++/CX), pero tienen reglas que restringen su superficie de la API pública.
Para este ejemplo, elija Aplicación vacía, como se muestra en la Figura 2.
.jpg "De forma predeterminada, las aplicaciones Windows usan ahora la plantilla en blanco")
Figura 2 De forma predeterminada, las aplicaciones Windows usan ahora la plantilla en blanco
¿Dónde están todas las demás plantillas? Piense en la plantilla de Aplicación Hub que se incluyó con Windows 8. Muchos desarrolladores la usan. Muchos desarrolladores la han copiado. Este aluvión de aplicaciones "y yo también" han creado coherencia visual dentro de la Tienda Windows, pero no han contribuido a la diversidad del ecosistema. Ahora, la plantilla Aplicación vacía se encuentra en el centro, animando a los desarrolladores a crear interfaces visualmente coherentes a la vez que distintivas en la plataforma. Muchas plantillas basadas en la comunidad ya han empezado a aparecer en la Galería de Visual Studio, incluida una, Template10, que escribieron los autores de este artículo.
Hello World! Ha creado su primera aplicación Windows. Aunque la interfaz de usuario está en blanco, ya se puede ejecutar en todos los dispositivos de Windows. El Explorador de soluciones de Visual Studio revela lo sencilla que es una aplicación básica de Windows: un proyecto único con un App.xaml y un archivo MainPage.xaml único para la interfaz de usuario inicial.
La solución incluye otros archivos de compatibilidad familiares. El Package.appxmanifest declara las capacidades que solicitará la aplicación de la máquina del usuario, como la ubicación del usuario; el acceso a la cámara; y el sistema de archivos. Se ha ampliado el esquema XML, pero es aproximadamente el mismo que el appxmanifest para aplicaciones universales de Windows 8.1.
¿Dónde están los dos extremos? Las aplicaciones universales de Windows 8 requieren tanto un proyecto principal de Windows como uno de Phone. La UAP no requiere varios extremos. En su lugar, adapta las interfaces para acomodarse a dondequiera que se esté ejecutando su aplicación Windows. Dicho eso, sin duda puede crear una solución de varios principales si se ajusta al flujo de trabajo de su equipo de desarrollo. Ambos enfoques se admiten por igual.
Contenido incluido Cuando abra MainPage.xaml, verá la experiencia mejorada de tiempo de diseño XAML de Visual Studio. El diseñador es más rico y más rápido; ha mejorado la capacidad de simular la relación de aspecto y la escala; y se expanden las propias herramientas. Ahora vamos a agregar un pequeño XAML, como se muestra en la Figura 3. (Gracias a nuestro colega David Crawford por este ejemplo).
Figura 3 El RelativePanel le permite diseñar la interfaz de una manera sencilla
<Grid Background="{StaticResource EggshellBrush}">
<RelativePanel x:Name="PromoArea">
<Image x:Name="BannerImage" HorizontalAlignment="Right"
Height="280" Stretch="UniformToFill"
Source="Assets/clouds.png"
RelativePanel.AlignRightWithPanel="True"/>
<Grid x:Name="BannerText" Margin="24"
Background="{StaticResource BlueBrush}">
<StackPanel Margin="12" HorizontalAlignment="Stretch">
<TextBlock x:Name="Headline" Text="Come fly with us"
Margin="0,-32,0,0" FontSize="48"
Foreground="{StaticResource EggshellBrush}"
FontFamily="{StaticResource LustScriptFont}" />
<TextBlock x:Name="Subtitle" FontSize="21.333"
Foreground="{StaticResource EggshellBrush}"
FontFamily="{StaticResource DomusTitlingFont}">
<Run Text="Fly return to London"/>
<LineBreak/>
<Run Text="For only $800"/>
</TextBlock>
</StackPanel>
</Grid>
</RelativePanel>
</Grid>
El código de la Figura 3 crea el encabezado de página para una aplicación sencilla para una compañía aérea ficticia. De manera específica, aprovecha el nuevo RelativePanel de XAML, que le permite reorganizar la interfaz de una manera sencilla. El RelativePanel colocará la imagen del banner a la derecha de la página e incluirá la cuadrícula con las ofertas especiales recientes de la compañía aérea.
Adición de algunos activos El XAML hace referencia a tres archivos que hemos agregado a la carpeta Assets: una imagen de archivo, Clouds.png, y dos fuentes personalizadas, DomusTitlingFont.ttf y LustScriptFont.ttf. Las fuentes y los recursos del pincel personalizados se declaran en App.xaml:
<Application.Resources>
<SolidColorBrush x:Key="BlueBrush" Color="#FF1C90D1"/>
<SolidColorBrush x:Key="EggshellBrush" Color="#FFFAFFF7"/>
<FontFamily x:Key="LustScriptFont">
Assets/Fonts/LustScriptDisplay.otf#Lust Script Display
</FontFamily>
<FontFamily x:Key="DomusTitlingFont">
Assets/Fonts/DomusTitling.otf#Domus Titling
</FontFamily>
</Application.Resources>
Estos archivos se incluyen en la descarga de código que se incluye con este artículo.
Tenga en cuenta que la imagen de mapa de bits está en una escala. Si desea admitir dispositivos con una resolución mayor, podría escalar sus activos y nombrarlos mediante el factor de escala adecuado para que cada usuario obtenga la mejor experiencia visual sin tener que descargar activos para otros factores de escala.
Ejecución en dispositivos Atrás en MainPage.xaml, la interfaz de usuario está tomando forma. Para ejecutar la aplicación, puede seleccionar el destino en la lista desplegable de destinos de dispositivos de Visual Studio. Observe que incluye el Simulador de Windows (para pruebas táctiles), el Equipo local, el Equipo remoto (para ARM de pruebas) y Dispositivo (hardware de teléfono real). Los emuladores de teléfono están en la misma lista. Elija y ejecute en el Equipo local y después en uno de los emuladores de teléfono para ver su aplicación de Windows ejecutándose en diferentes dispositivos sin compilaciones especiales.
Es posible que haya observado que la ejecución de una aplicación de Windows en el Equipo local, es decir, en el escritorio de su PC, es una experiencia con ventanas y no la experiencia de pantalla completa de Windows 8. Esto se debe a que está ejecutando la aplicación en el SKU de escritorio de Windows 10. El SKU móvil de Windows 10 todavía inicia la pantalla completa de aplicaciones de Windows para facilitar la navegación táctil. Sin embargo, el SKU de escritorio de Windows 10 también iniciará la pantalla completa de las aplicaciones de Windows si elige la experiencia táctil a través de la interfaz de Continuum en una tableta o un equipo portátil convertible.
Interfaces adaptables Aunque la aplicación de Windows se ejecuta en ambos dispositivos, tras un examen más detallado, la interfaz de usuario no es excelente en la pantalla más pequeña del teléfono. El texto del encabezado es demasiado grande para la pantalla pequeña y se trunca. Este es el principio de un viaje más largo para probar y mejorar la experiencia de usuario en la variedad de posibles dispositivos para esta aplicación de Windows.
Modificaremos el diseño del encabezado cuando detectemos la pantalla más estrecha del teléfono. Sin embargo, es importante reconocer que no es el teléfono lo que se detecta, sino el ancho de la pantalla. Esto permite una experiencia estrecha tanto en el escritorio como en el teléfono.
Tenga en cuenta que no hay ninguna API para detectar un teléfono. Sin embargo, si el diseño requiere una operación de una sola mano específica para el teléfono y las tabletas más pequeñas, puede comprobar el tamaño de la diagonal del dispositivo físico en un desencadenador de estado visual personalizado (del que no se habla en este artículo).
Los estados visuales no son nuevos para XAML. El Administrador de estados visuales permite a los desarrolladores y diseñadores definir diferentes estados visuales (es decir, distintos diseños de pantalla) y pasar de uno a otro en tiempo de ejecución. Los desencadenadores adaptables de estado visual son nuevos con la UAP. Acaban con el enfoque mediante programación para pasar de un estado visual a otro. En su lugar, declara cuando un estado visual debe estar visible en XAML y la plataforma subyacente se encarga del resto.
Ahora, modifique el código XAML en MainPage.XAML, como se muestra en la Figura 4.
Figura 4 XAML admite ahora la declaración de reglas para adaptar una interfaz
<Grid Background="{StaticResource EggshellBrush}">
<VisualStateManager.VisualStateGroups>
<VisualStateGroup x:Name="WindowStates">
<VisualState x:Name="NarrowState">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="1"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="BannerImage.Height" Value="120"/>
<Setter Target="BannerText.(RelativePanel.Below)"
Value="BannerImage"/>
<Setter Target="BannerText.Width" Value="660"/>
<Setter Target="BannerText.Margin" Value="0,0,0,24"/>
<Setter Target="Headline.FontSize" Value="28"/>
<Setter Target="Subtitle.FontSize" Value="12"/>
</VisualState.Setters>
</VisualState>
<VisualState x:Name="MediumState">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="660"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="BannerImage.Height" Value="180" />
<Setter Target="BannerText.(RelativePanel.AlignTopWith)"
Value="BannerImage"/>
<Setter Target="Headline.FontSize" Value="28"/>
<Setter Target="Subtitle.FontSize" Value="14"/>
</VisualState.Setters>
</VisualState>
<VisualState x:Name="WideState">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="1000"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="BannerText.(RelativePanel.AlignTopWith)"
Value="BannerImage"/>
</VisualState.Setters>
</VisualState>
</VisualStateGroup>
</VisualStateManager.VisualStateGroups>
<RelativePanel...
En la Figura 4, observe que hay tres estados visuales declarados: NarrowState, WideState y MediumState. Cada uno de estos estados visuales se corresponde con distintos intervalos de ancho de pantalla. Puede crear tantos o tan pocos estados visuales como sea necesario para admitir sus familias de dispositivos de destino. El nombre que use para cada estado visual no es importante.
El XAML también muestra los establecedores de estado visual, que son nuevos en la UAP y le permiten establecer un valor de propiedad discreto sin la sobrecarga de una animación de guión gráfico. En este caso, usamos establecedores para cambiar la posición relativa de los elementos secundarios en el RelativePanel estableciendo la propiedad adjunta RelativePanel en los elementos secundarios y cambiamos el alto de la BannerImage y el FontSize de los elementos de texto. Con los estados visuales implementados, la interfaz hace un gran trabajo al adaptarse a una pantalla más estrecha. Ejecútelo y verá.
En la Figura 5 se muestra la manera en que la interfaz de usuario se adapta a los cambios en el ancho de la pantalla. En la aplicación de Windows, puede aprovechar los desencadenadores de estado visual para ajustar los elementos de la mejor manera para los usuarios.
.jpg "Adaptación a los cambios de ancho de pantalla")
Figura 5 Adaptación a los cambios de ancho de pantalla
La versión completa de este ejemplo, que se incluye en la descarga de código que se incluye con este artículo, desarrolla aún más la interfaz de usuario y proporciona ejemplos adicionales del uso del RelativePanel y los desencadenadores de estado visual para implementar una interfaz de usuario adaptable.
Código adaptable La interfaz de usuario se adapta a diferentes pantallas, pero las diferencias de dispositivos se extienden a más de un tamaño de pantalla. Por ejemplo, los teléfonos tienen botones de hardware como Atrás y Cámara, que podrían no estar presentes en una plataforma diferente, como un PC. La UAP predeterminada tiene la mayoría de la superficie de la API que las aplicaciones de Windows necesitan, pero la funcionalidad específica del dispositivo se desbloquea con los SDK de extensión que se agregan a sus proyectos de la misma manera que los ensamblados externos, como se muestra en la Figura 6. Habilitan un conjunto más amplio de funciones específicas de dispositivos sin invalidar la capacidad de que su aplicación se ejecute en otros tipos de dispositivos.
.jpg "La adición de una extensión es tan sencillo como agregar una referencia de proyecto")
Figura 6 La adición de una extensión es tan sencillo como agregar una referencia de proyecto
Los dos SDK de plataforma más comunes son las extensiones de escritorio y móvil, que habilitan la funcionalidad exclusiva de su SKU de Windows respectivo. La extensión móvil, por ejemplo, permite a las API necesarias usar el botón de cámara de hardware.
La SKU de Windows Mobile se puede ejecutar en teléfonos y tabletas pequeñas. Sin embargo, no todas las tabletas (ni siquiera todos los teléfonos) tienen un botón de cámara de hardware. Los SDK de extensión habilitan la compatibilidad de botones, pero no coloque botones en el dispositivo. Como resultado, en tiempo de ejecución, debe probar las capacidades de dispositivo antes de invocar las capacidades en el SDK de extensión.
De la misma manera que los SDK de extensión como móvil y escritorio desbloquean las capacidades de dispositivos para las aplicaciones de Windows, los SDK de extensión personalizados agregan compatibilidad para componentes adicionales, como la Kinect para Windows o el hardware de terceros. Estos tampoco impiden que su aplicación se ejecute en otros tipos de dispositivos.
¿Cómo comprueba las capacidades de dispositivos? Aprovecha los métodos de la clase Windows.Foundation.Metadata.ApiInformation que devuelven un valor booleano simple si un tipo o método es compatible con el dispositivo actual. Puede habilitar su aplicación de Windows para usar el botón de cámara con código similar al siguiente:
if (Windows.Foundation.Metadata.ApiInformation.IsTypePresent(
"Windows.Phone.UI.Input.HardwareButtons"))
{
Windows.Phone.UI.Input.HardwareButtons.CameraPressed +=
HardwareButtons_CameraPressed;
}
Observe aquí cómo el código de Windows.Phone.UI.Input.HardwareButtons se puede ejecutar solo si el SDK de extensión está habilitado en el dispositivo. A diferencia de los condicionales de compilación, las pruebas de capacidades no producen varios binarios. Esto significa que puede mejorar o empeorar correctamente la experiencia de usuario en función de las capacidades del dispositivo actual. Se trata de un método eficaz para habilitar un solo binario; crea variabilidad ilimitada, lo que le permite sacar el máximo partido de sus aplicaciones de Windows en diferentes familias de dispositivos.
Resumen
Si se siente cómodo con el desarrollo de aplicaciones universales de Windows 8, la creación de aplicaciones de Windows que tienen como destino la UAP debería ser pan comido. Las aplicaciones de Windows no están destinadas a Windows 10; la UAP es el objetivo y no está desacoplada de la SKU de Windows. La UAP incrementa las versiones en una cadencia aparte de Windows. Esto significa que las aplicaciones de Windows no tendrán que redestinar su objeto cada vez que se revolucione el sistema operativo Windows. Las aplicaciones de Windows están destinadas a una o más versiones la UAP y se prueban para esas capacidades de la misma manera que se prueban para capacidades de dispositivos. Este enfoque flexible le ofrece una buena manera limpia de aprovechar las capacidades futuras.
Crear una aplicación de Windows significa que su aplicación se puede ejecutar en cualquier dispositivo de Windows. Este regalo viene con una advertencia del mundo real: La UAP solo puede ejecutar la aplicación, pero solo los desarrolladores y diseñadores pueden hacer que se adapte la interfaz de usuario y el código para ofrecer la mejor experiencia de usuario posible. Si desea crear binarios específicos de dispositivo independientes, puede hacerlo. Sin embargo, si decide crear una aplicación de Windows que admita varios tipos de dispositivo, todas las herramientas y la infraestructura están implementadas para que logre su objetivo.
Jerry Nixon es evangelizador desarrollador de Microsoft de Colorado. Nixon enseña y habla sobre el desarrolo para escritorio, teléfono y Windows. Su carrera profesional se inició con Microsoft SQL Server 6.5, ofreciendo soluciones centradas en datos cuando "desarrollador de bases de datos" era un término novedoso. Recibió una Mención Naval civil por el trabajo de seguridad, antes de empezar a trabajar en lo que después se convertiría en Microsoft CRM. Durante 15 años, Nixon creó soluciones móviles centradas en Microsoft. Actualmente, habla sobre XAML y la movilidad en eventos, comunidades y universidades y la mayor parte de su tiempo libre la dedica a enseñar a sus tres hijas las tramas de los episodios y los orígenes de los personajes de Star Trek.
Andy Wigley es desarrollador evangelizador de Microsoft del Reino Unido. Empezó a trabajar para Microsoft en 2012 y antes de eso trabajó como consultor y fue miembro destacado de la comunidad de desarrolladores de aplicaciones móviles. Se enorgullece de haber sido nombrado MVP (profesional más valioso de Microsoft) durante 10 años consecutivos. Wigley es muy conocido por los vídeos de Windows Phone JumpStart populares disponibles en channel9.msdn.com y está feliz de trabajar con Jerry Nixon en una serie de vídeos de seguimiento sobre el desarrollo de aplicaciones de Windows.