Migración Windows Phone XAML y la interfaz de usuario de Silverlight a UWP
El tema anterior era Solución de problemas.
La práctica de definir la interfaz de usuario en forma de marcado XAML declarativo se traduce muy bien de Windows Phone Silverlight a aplicaciones de Plataforma universal de Windows (UWP). Verá que las secciones grandes del marcado son compatibles una vez que ha actualizado las referencias de clave de recurso del sistema, ha cambiado algunos nombres de tipo de elemento y ha cambiado "clr-namespace" a "using". Gran parte del código imperativo de la capa de presentación (modelos de vista y código que manipula los elementos de la interfaz de usuario) también será sencillo de migrar.
Un primer vistazo al marcado XAML
En el tema anterior se muestra cómo copiar los archivos XAML y de código subyacente en el nuevo proyecto de Visual Studio de Windows 10. Uno de los primeros problemas que puedes observar resaltados en el diseñador XAML de Visual Studio es que el PhoneApplicationPage elemento en la raíz del archivo XAML no es válido para un proyecto de Plataforma universal de Windows (UWP). En el tema anterior, guardó una copia de los archivos XAML que Visual Studio generó al crear el proyecto de Windows 10. Si abres esa versión de MainPage.xaml, verás que en la raíz es el tipo Page, que se encuentra en el espacio de nombres Windows.UI.Xaml.Controls. Por lo tanto, puede cambiar todos los <phone:PhoneApplicationPage> elementos a <Page> (no olvide la sintaxis del elemento de propiedad) y puede eliminar la xmlns:phone declaración.
Para obtener un enfoque más general para buscar el tipo de UWP que corresponde a un tipo Windows Phone Silverlight, puedes hacer referencia a Namespace y asignaciones de clases.
Declaraciones de prefijo de espacio de nombres XAML
Si usas instancias de tipos personalizados en tus vistas (quizás una instancia de modelo de vista o un convertidor de valores), tendrás declaraciones de prefijo de espacio de nombres XAML en el marcado XAML. La sintaxis de estas diferencias entre Windows Phone Silverlight y UWP. Estos son algunos ejemplos:
xmlns:ContosoTradingCore="clr-namespace:ContosoTradingCore;assembly=ContosoTradingCore"
xmlns:ContosoTradingLocal="clr-namespace:ContosoTradingLocal"
Cambie "clr-namespace" a "using" y elimine cualquier token de ensamblado y punto y coma (se deducirá el ensamblado). El resultado tiene el aspecto siguiente:
xmlns:ContosoTradingCore="using:ContosoTradingCore"
xmlns:ContosoTradingLocal="using:ContosoTradingLocal"
Es posible que tenga un recurso cuyo tipo esté definido por el sistema:
xmlns:System="clr-namespace:System;assembly=mscorlib"
/* ... */
<System:Double x:Key="FontSizeLarge">40</System:Double>
En UWP, omita la declaración de prefijo "System" y use el prefijo "x" (ya declarado) en su lugar:
<x:Double x:Key="FontSizeLarge">40</x:Double>
Código imperativo
Los modelos de vista son un lugar donde hay código imperativo que hace referencia a los tipos de interfaz de usuario. Otro lugar es cualquier archivo de código subyacente que manipule directamente los elementos de la interfaz de usuario. Por ejemplo, es posible que encuentre que una línea de código como esta aún no se compila:
return new BitmapImage(new Uri(this.CoverImagePath, UriKind.Relative));
BitmapImage se encuentra en el espacio de nombres System.Windows.Media.Imaging en Windows Phone Silverlight y una directiva using en el mismo archivo permite usar BitmapImage sin calificación de espacio de nombres como en el fragmento de código anterior. En un caso como este, puede hacer clic con el botón derecho en el nombre de tipo (BitmapImage) en Visual Studio y usar el comando Resolver en el menú contextual para agregar una nueva directiva de espacio de nombres al archivo. En este caso, se agrega el espacio de nombres Windows.UI.Xaml.Media.Imaging , que es donde reside el tipo en UWP. Puede quitar la directiva using System.Windows.Media.Imaging y eso será todo lo que se necesita para portar código como el del fragmento de código anterior. Cuando haya terminado, habrá quitado todos los espacios de nombres de Silverlight Windows Phone.
En casos sencillos como este, donde va a asignar los tipos de un espacio de nombres antiguo a los mismos tipos de uno nuevo, puede usar el comando Buscar y reemplazar de Visual Studio para realizar cambios masivos en el código fuente. El comando Resolve es una excelente manera de detectar el nuevo espacio de nombres de un tipo. Como otro ejemplo, puedes reemplazar todas las "System.Windows" por "Windows.UI.Xaml". Básicamente, eso migrará todas las directivas using y todos los nombres de tipo completos que hacen referencia a ese espacio de nombres.
Una vez quitadas todas las directivas using antiguas y las nuevas agregadas, puede usar el comando Organizar usings de Visual Studio para ordenar las directivas y quitar las que no se usan.
A veces, la corrección del código imperativo será tan secundaria como cambiar el tipo de un parámetro. En otras ocasiones, tendrás que usar las API de Windows Runtime en lugar de las API de .NET para aplicaciones de Windows Runtime 8.x. Para identificar qué API se admiten, use el resto de esta guía de portabilidad en combinación con la introducción a las aplicaciones de .NET para Windows Runtime 8.x y la referencia de Windows Runtime.
Además, si solo desea llegar a la fase en la que se compila el proyecto, puede comentar o quitar código auxiliar de cualquier código no esencial. A continuación, itera un problema cada vez y consulte los temas siguientes de esta sección (y el tema anterior: Solución de problemas), hasta que se solucionen los problemas de compilación y tiempo de ejecución y se complete el puerto.
Interfaz de usuario adaptable/con capacidad de respuesta
Dado que la aplicación de Windows 10 puede ejecutarse en una gama potencialmente amplia de dispositivos ( cada uno con su propio tamaño y resolución de pantalla), querrás ir más allá de los pasos mínimos para migrar la aplicación y querrás adaptar tu interfaz de usuario para que se vea mejor en esos dispositivos. Puede usar la característica Visual State Manager adaptable para detectar dinámicamente el tamaño de la ventana y cambiar el diseño en respuesta, y un ejemplo de cómo hacerlo se muestra en la sección Interfaz de usuario adaptable del tema de caso práctico Bookstore2.
Alarmas y recordatorios
El código que usa las clases Alarm o Reminder debe migrarse para usar la clase BackgroundTaskBuilder para crear y registrar una tarea en segundo plano y mostrar una notificación del sistema en el momento pertinente. Consulte Procesamiento en segundo plano y notificaciones del sistema.
Animación
Como alternativa preferida a las animaciones de fotograma clave y de/a las animaciones, la biblioteca de animaciones para UWP está disponible para las aplicaciones para UWP. Estas animaciones se han diseñado y optimizado para ejecutarse sin problemas, para que parezcan excelentes y para que la aplicación aparezca tan integrada con Windows como lo hacen las aplicaciones integradas. Consulte Inicio rápido: Animación de la interfaz de usuario mediante animaciones de biblioteca.
Si usas animaciones de fotograma clave o de/a animaciones en tus aplicaciones para UWP, es posible que quieras comprender la distinción entre animaciones independientes y dependientes que ha introducido la nueva plataforma. Consulta Optimizar animaciones y medios. Las animaciones que se ejecutan en el subproceso de la interfaz de usuario (las que animan las propiedades de diseño, por ejemplo) se conocen como animaciones dependientes y, cuando se ejecutan en la nueva plataforma, no tendrán ningún efecto a menos que realice una de estas dos cosas. Puede volver a dirigirse a ellas para animar propiedades diferentes, como RenderTransform, lo que las convierte en independientes. O bien, puedes establecer EnableDependentAnimation="True" en el elemento de animación para confirmar tu intención de ejecutar una animación que no se pueda garantizar que se ejecute sin problemas. Si usas Blend para Visual Studio para crear nuevas animaciones, esa propiedad se establecerá para ti cuando sea necesario.
Control del botón Atrás
En una aplicación de Windows 10, puedes usar un enfoque único para controlar el botón Atrás y funcionará en todos los dispositivos. En los dispositivos móviles, el botón se proporciona para usted como un botón capacitivo en el dispositivo o como un botón en el shell. En un dispositivo de escritorio, agregas un botón al cromo de la aplicación siempre que la navegación hacia atrás sea posible dentro de la aplicación, y esto aparece en la barra de título de las aplicaciones con ventanas o en la barra de tareas para el modo Tableta (solo Windows 10). El evento de botón Atrás es un concepto universal en todas las familias de dispositivos y los botones implementados en hardware o en software generan el mismo evento BackRequested.
El ejemplo siguiente funciona para todas las familias de dispositivos y es bueno para los casos en los que el mismo procesamiento se aplica a todas las páginas y donde no necesita confirmar la navegación (por ejemplo, para advertir sobre los cambios no guardados).
// app.xaml.cs
protected override void OnLaunched(LaunchActivatedEventArgs e)
{
[...]
Windows.UI.Core.SystemNavigationManager.GetForCurrentView().BackRequested += App_BackRequested;
rootFrame.Navigated += RootFrame_Navigated;
}
private void RootFrame_Navigated(object sender, NavigationEventArgs e)
{
Frame rootFrame = Window.Current.Content as Frame;
// Note: On device families that have no title bar, setting AppViewBackButtonVisibility can safely execute
// but it will have no effect. Such device families provide a back button UI for you.
if (rootFrame.CanGoBack)
{
Windows.UI.Core.SystemNavigationManager.GetForCurrentView().AppViewBackButtonVisibility =
Windows.UI.Core.AppViewBackButtonVisibility.Visible;
}
else
{
Windows.UI.Core.SystemNavigationManager.GetForCurrentView().AppViewBackButtonVisibility =
Windows.UI.Core.AppViewBackButtonVisibility.Collapsed;
}
}
private void App_BackRequested(object sender, Windows.UI.Core.BackRequestedEventArgs e)
{
Frame rootFrame = Window.Current.Content as Frame;
if (rootFrame.CanGoBack)
{
rootFrame.GoBack();
}
}
También hay un enfoque único para todas las familias de dispositivos para salir mediante programación de la aplicación.
Windows.UI.Xaml.Application.Current.Exit();
Enlace y enlaces compilados con {x:Bind}
El tema de enlace incluye:
- Enlazar un elemento de interfaz de usuario a "datos" (es decir, a las propiedades y comandos de un modelo de vista)
- Enlace de un elemento de interfaz de usuario a otro elemento de interfaz de usuario
- Escribir un modelo de vista que sea observable (es decir, genera notificaciones cuando cambia un valor de propiedad y cuándo cambia la disponibilidad de un comando).
Todos estos aspectos siguen siendo compatibles en gran medida, pero hay diferencias de espacio de nombres. Por ejemplo, System.Windows.Data.Binding se asigna a Windows.UI.Xaml.Data.Binding, System.ComponentModel.INotifyPropertyChanged se asigna a Windows.UI.Xaml.Data.INotifyPropertyChanged y System.Collections.Specialized.INotifyPropertyChanged se asigna a Windows.UI.Xaml.Interop.INotifyCollectionChanged.
Windows Phone las barras de aplicaciones de Silverlight y los botones de la barra de aplicaciones no se pueden enlazar como en una aplicación para UWP. Es posible que tenga código imperativo que construya la barra de la aplicación y sus botones, los enlaza a propiedades y cadenas localizadas y controla sus eventos. Si es así, ahora tiene la opción de portar ese código imperativo reemplazando por marcado declarativo enlazado a propiedades y comandos, y con referencias de recursos estáticos, lo que hace que la aplicación sea incrementalmente más segura y fácil de mantener. Puedes usar Visual Studio o Blend para Visual Studio para enlazar y aplicar estilo a botones de barra de aplicaciones para UWP como cualquier otro elemento XAML. Ten en cuenta que en una aplicación para UWP los nombres de tipo que usas son CommandBar y AppBarButton.
Actualmente, las características relacionadas con el enlace de las aplicaciones para UWP tienen las siguientes limitaciones:
- No hay compatibilidad integrada con la validación de entrada de datos y las interfaces IDataErrorInfo e INotifyDataErrorInfo.
- La clase Binding no incluye las propiedades de formato extendidas disponibles en Windows Phone Silverlight. Sin embargo, todavía puede implementar IValueConverter para proporcionar formato personalizado.
- Los métodos IValueConverter toman cadenas de lenguaje como parámetros en lugar de objetos CultureInfo.
- La clase CollectionViewSource no proporciona compatibilidad integrada con la ordenación y el filtrado, y la agrupación funciona de forma diferente. Para obtener más información, consulte Enlace de datos en profundidad y el ejemplo enlace de datos.
Aunque todavía se admiten en gran medida las mismas características de enlace, Windows 10 ofrece la opción de un mecanismo de enlace nuevo y más eficaz denominado enlaces compilados, que usan la extensión de marcado {x:Bind}. Consulta Enlace de datos: mejora el rendimiento de tus aplicaciones a través de nuevas mejoras en el enlace de datos XAML y en el ejemplo x:Bind.
Enlazar una imagen a un modelo de vista
Puede enlazar la propiedad Image.Source a cualquier propiedad de un modelo de vista que sea de tipo ImageSource. Esta es una implementación típica de esta propiedad en una aplicación de Windows Phone Silverlight:
// this.BookCoverImagePath contains a path of the form "/Assets/CoverImages/one.png".
return new BitmapImage(new Uri(this.CoverImagePath, UriKind.Relative));
En una aplicación para UWP, usas el esquema de URI ms-appx. Para que pueda mantener el resto del código igual, puede usar una sobrecarga diferente del constructor System.Uri para colocar el esquema URI ms-appx en un URI base y anexar el resto de la ruta de acceso a ese. Por ejemplo:
// this.BookCoverImagePath contains a path of the form "/Assets/CoverImages/one.png".
return new BitmapImage(new Uri(new Uri("ms-appx://"), this.CoverImagePath));
De este modo, el resto del modelo de vista, los valores de ruta de acceso de la propiedad de ruta de acceso de la imagen y los enlaces del marcado XAML pueden permanecer exactamente iguales.
Controles y estilos o plantillas de control
Windows Phone aplicaciones de Silverlight usan controles definidos en el espacio de nombres Microsoft.Phone.Controls y el espacio de nombres System.Windows.Controls . Las aplicaciones para UWP XAML usan controles definidos en el espacio de nombres Windows.UI.Xaml.Controls. La arquitectura y el diseño de los controles XAML en UWP son prácticamente iguales que Windows Phone controles silverlight. Sin embargo, se han realizado algunos cambios para mejorar el conjunto de controles disponibles y para unificarlos con aplicaciones de Windows. Estos son ejemplos específicos.
| Nombre del control | Cambio |
|---|---|
| ApplicationBar | La propiedad Page.TopAppBar . |
| ApplicationBarIconButton | El equivalente de UWP es la propiedad Glyph . PrimaryCommands es la propiedad content de CommandBar. El analizador XAML interpreta el xml interno de un elemento como el valor de su propiedad de contenido. |
| ApplicationBarMenuItem | El equivalente de UWP es appBarButton.Label establecido en el texto del elemento de menú. |
| ContextMenu (en el kit de herramientas de Windows Phone) | Para un control flotante de selección única, use Control flotante. |
| Clase ControlTiltEffect.TiltEffect | Las animaciones de la biblioteca de animaciones para UWP están integradas en los estilos predeterminados de los controles comunes. Vea las acciones de animación del puntero. |
| LongListSelector con datos agrupados | El Windows Phone funciones LongListSelector de Silverlight de dos maneras, que se pueden usar en concierto. En primer lugar, puede mostrar los datos agrupados por una clave, por ejemplo, una lista de nombres agrupados por letra inicial. En segundo lugar, puede "acercar" entre dos vistas semánticas: la lista agrupada de elementos (por ejemplo, nombres) y una lista de solo las claves de grupo (por ejemplo, letras iniciales). Con UWP, puedes mostrar datos agrupados con los controles de lista y vista de cuadrícula. |
| LongListSelector con datos planos | Por motivos de rendimiento, en el caso de listas muy largas, se recomienda LongListSelector en lugar de un cuadro de lista Windows Phone Silverlight incluso para datos planos y no agrupados. En una aplicación para UWP, Se prefiere GridView para listas largas de elementos, tanto si los datos son accesibles para agruparlos como si no. |
| Panorama | El Windows Phone control Panorama de Silverlight se asigna a las Directrices para los controles de concentrador en aplicaciones y directrices de Windows Runtime 8.x para el control del concentrador. Tenga en cuenta que un control Panorama se ajusta desde la última sección hasta la primera, y su imagen de fondo se mueve en parallax con respecto a las secciones. Las secciones del concentrador no se ajustan y no se usa parallax. |
| Dinamización | El equivalente de UWP del control dinámico de Windows Phone Silverlight es Windows.UI.Xaml.Controls.Pivot. Está disponible para todas las familias de dispositivos. |
Nota El estado visual PointerOver es relevante en estilos o plantillas personalizados en aplicaciones de Windows 10, pero no en Windows Phone aplicaciones de Silverlight. Hay otras razones por las que es posible que tus estilos o plantillas personalizados existentes no sean adecuados para las aplicaciones de Windows 10, incluidas las claves de recursos del sistema que usas, los cambios en los conjuntos de estados visuales usados y las mejoras de rendimiento realizadas en los estilos o plantillas predeterminados de Windows 10. Le recomendamos que edite una nueva copia de la plantilla predeterminada de un control para Windows 10 y, a continuación, vuelva a aplicar su personalización de estilo y plantilla a esa.
Para obtener más información sobre los controles de UWP, consulta Controls by function, Controls list y Guidelines for controls.
Lenguaje de diseño en Windows 10
Hay algunas diferencias en el lenguaje de diseño entre Windows Phone aplicaciones de Silverlight y aplicaciones de Windows 10. Para obtener todos los detalles, consulte Diseño. A pesar de los cambios en el lenguaje de diseño, nuestros principios de diseño siguen siendo coherentes: sean atentos a los detalles, pero siempre se esfuerzan por simplificar a través de centrarse en el contenido no cromo, lo que reduce ferocmente los elementos visuales y permanecen auténticos en el dominio digital; usar jerarquía visual especialmente con tipografía; diseño en una cuadrícula; y llevar tus experiencias a la vida con animaciones fluidas.
Localización y globalización
En el caso de las cadenas localizadas, puedes volver a usar el archivo .resx desde tu proyecto de Silverlight de Windows Phone en tu proyecto de aplicación para UWP. Copie el archivo, agréguelo al proyecto y cámbielo a Resources.resw para que el mecanismo de búsqueda lo encuentre de forma predeterminada. Establezca Acción de compilación en PRIResource y Copiar en el directorio de salida en No copiar. A continuación, puedes usar las cadenas en el marcado especificando el atributo x:Uid en los elementos XAML. Consulte Inicio rápido: Uso de recursos de cadena.
Windows Phone aplicaciones de Silverlight usan la clase CultureInfo para ayudar a globalizar una aplicación. Las aplicaciones para UWP usan MRT (tecnología moderna de recursos), que permite la carga dinámica de recursos de la aplicación (localización, escala y tema) tanto en tiempo de ejecución como en la superficie de diseño de Visual Studio. Para obtener más información, consulte Directrices para archivos, datos y globalización.
En el tema ResourceContext.QualifierValues se describe cómo cargar recursos específicos de la familia de dispositivos en función del factor de selección de recursos de la familia de dispositivos.
Elementos multimedia y gráficos
A medida que leas sobre los elementos multimedia y gráficos de UWP, ten en cuenta que los principios de diseño de Windows fomentan una reducción feroz de cualquier cosa superflua, incluida la complejidad gráfica y el desorden. El diseño de Windows se escribe mediante objetos visuales limpios y claros, tipografía y movimiento. Si la aplicación sigue los mismos principios, parecerá más similar a las aplicaciones integradas.
Windows Phone Silverlight tiene un tipo RadialGradientBrush que no está presente en UWP, aunque otros tipos brush son. En algunos casos, podrá obtener un efecto similar con un mapa de bits. Ten en cuenta que puedes crear un pincel de degradado radial con Direct2D en un UWP de C++ de Microsoft DirectX y XAML.
Windows Phone Silverlight tiene la propiedad System.Windows.UIElement.OpacityMask, pero esa propiedad no es miembro del tipo UIElement de UWP. En algunos casos, podrá obtener un efecto similar con un mapa de bits. Y puedes crear una máscara de opacidad con Direct2D en una aplicación para UWP de Microsoft DirectX y XAML C++. Pero un caso de uso común para OpacityMask es usar un solo mapa de bits que se adapte a temas claros y oscuros. Para gráficos vectoriales, puede usar pinceles del sistema compatibles con temas (como los gráficos circulares que se muestran a continuación). Sin embargo, para crear un mapa de bits compatible con temas (como las marcas de verificación que se muestran a continuación), requiere un enfoque diferente.
En una aplicación de Windows Phone Silverlight, la técnica consiste en usar una máscara alfa (en forma de mapa de bits) como opacidadMask para un rectángulo rellenado con el pincel de primer plano:
<Rectangle Fill="{StaticResource PhoneForegroundBrush}" Width="26" Height="26">
<Rectangle.OpacityMask>
<ImageBrush ImageSource="/Assets/wpsl_check.png"/>
</Rectangle.OpacityMask>
</Rectangle>
La manera más sencilla de migrar esto a una aplicación para UWP es usar bitmapIcon, de la siguiente manera:
<BitmapIcon UriSource="Assets/winrt_check.png" Width="21" Height="21"/>
Aquí, winrt_check.png es una máscara alfa en forma de mapa de bits igual que wpsl_check.png es, y podría ser muy bien el mismo archivo. Sin embargo, es posible que desee proporcionar varios tamaños diferentes de winrt_check.png usarse para distintos factores de escalado. Para obtener más información sobre eso, y para obtener una explicación de los cambios en los valores Width y Height , vea Ver o efectivo píxeles, ver distancia y factores de escala en este tema.
Un enfoque más general, que es adecuado si hay diferencias entre la forma de tema claro y oscuro de un mapa de bits, es usar dos recursos de imagen: uno con un primer plano oscuro (para tema claro) y otro con un primer plano claro (para tema oscuro). Para obtener más información sobre cómo asignar un nombre a este conjunto de recursos de mapa de bits, consulte Personalización de los recursos para lenguaje, escala y otros calificadores. Una vez que un conjunto de archivos de imagen se denominan correctamente, puede hacer referencia a ellos en el resumen, con su nombre raíz, de la siguiente manera:
<Image Source="Assets/winrt_check.png" Stretch="None"/>
En Windows Phone Silverlight, la propiedad UIElement.Clip puede ser cualquier forma que pueda expresar con una geometría y normalmente se serializa en el marcado XAML en el mini-lenguaje StreamGeometry . En UWP, el tipo de la propiedad Clip es RectangleGeometry, por lo que solo puedes recortar una región rectangular. Permitir que se defina un rectángulo mediante mini-lenguaje sería demasiado permisivo. Por lo tanto, para portar una región de recorte en el marcado, reemplace la sintaxis del atributo Clip y consícela en la sintaxis del elemento de propiedad similar a la siguiente:
<UIElement.Clip>
<RectangleGeometry Rect="10 10 50 50"/>
</UIElement.Clip>
Ten en cuenta que puedes usar geometría arbitraria como máscara en una capa con Direct2D en una aplicación para UWP de C++ XAML y Microsoft DirectX .
Navegación
Al navegar a una página en una aplicación de Windows Phone Silverlight, se usa un esquema de direccionamiento de identificador uniforme de recursos (URI):
NavigationService.Navigate(new Uri("/AnotherPage.xaml", UriKind.Relative)/*, navigationState*/);
En una aplicación para UWP, llamas al método Frame.Navigate y especificas el tipo de la página de destino (tal como se define en el atributo x:Class de la definición de marcado XAML de la página):
// In a page:
this.Frame.Navigate(typeof(AnotherPage)/*, parameter*/);
// In a view model, perhaps inside an ICommand implementation:
var rootFrame = Windows.UI.Xaml.Window.Current.Content as Windows.UI.Xaml.Controls.Frame;
rootFrame.Navigate(typeof(AnotherPage)/*, parameter*/);
La página de inicio se define para una aplicación de Windows Phone Silverlight en WMAppManifest.xml:
<DefaultTask Name="_default" NavigationPage="MainPage.xaml" />
En una aplicación para UWP, usas código imperativo para definir la página de inicio. Este es un código de App.xaml.cs que ilustra cómo:
if (!rootFrame.Navigate(typeof(MainPage), e.Arguments))
La asignación de URI y la navegación por fragmentos son técnicas de navegación de URI, por lo que no son aplicables a la navegación de UWP, que no se basa en los URI. La asignación de URI existe en respuesta a la naturaleza débilmente tipada de identificar una página de destino con una cadena de URI, lo que conduce a problemas de fragilidad y mantenimiento si la página se mueve a una carpeta diferente y, por tanto, a una ruta de acceso relativa diferente. Las aplicaciones para UWP usan la navegación basada en tipos, que está fuertemente tipada y activada por el compilador, y no tiene el problema que soluciona la asignación de URI. El caso de uso de la navegación por fragmentos consiste en pasar algún contexto a la página de destino para que la página pueda hacer que un fragmento determinado de su contenido se desplácese hacia la vista o se muestre de otro modo. El mismo objetivo se puede lograr pasando un parámetro de navegación al llamar al método Navigate.
Para obtener más información, consulta Navegación.
Referencia de clave de recurso
El lenguaje de diseño ha evolucionado para Windows 10 y, por tanto, ciertos estilos del sistema han cambiado y se han quitado o cambiado el nombre de muchas claves de recursos del sistema. El editor de marcado XAML de Visual Studio resalta las referencias a las claves de recursos que no se pueden resolver. Por ejemplo, el editor de marcado XAML resaltará una referencia a la clave PhoneTextNormalStyle de estilo con un subrayado ondulado rojo. Si no se corrige, la aplicación finalizará inmediatamente cuando intente implementarla en el emulador o en el dispositivo. Por lo tanto, es importante asistir a la corrección del marcado XAML. Y encontrará que Visual Studio es una excelente herramienta para detectar estos problemas.
Vea también Texto, a continuación.
Barra de estado (bandeja del sistema)
La bandeja del sistema (establecida en marcado XAML con shell:SystemTray.IsVisible) ahora se denomina barra de estado y se muestra de forma predeterminada. Puedes controlar su visibilidad en código imperativo llamando a los métodos Windows.UI.ViewManagement.StatusBar.ShowAsync y HideAsync.
Texto
Texto (o tipografía) es un aspecto importante de una aplicación para UWP y, al migrar, es posible que quieras volver a visitar los diseños visuales de tus vistas para que estén en armonía con el nuevo lenguaje de diseño. Usa estas ilustraciones para buscar los estilos del sistema TextBlock para UWP que están disponibles. Busque los que corresponden a los estilos de Windows Phone Silverlight que usó. Como alternativa, puede crear sus propios estilos universales y copiar las propiedades de los estilos del sistema de Windows Phone Silverlight en ellos.
Estilos textBlock del sistema para aplicaciones de Windows 10
En una aplicación Windows Phone Silverlight, la familia de fuentes predeterminada es Segoe WP. En una aplicación de Windows 10, la familia de fuentes predeterminada es Segoe UI. Como resultado, las métricas de fuente de la aplicación pueden tener un aspecto diferente. Si desea reproducir el aspecto del texto de Windows Phone Silverlight, puede establecer sus propias métricas mediante propiedades como LineHeight y LineStackingStrategy. Para obtener más información, consulta Directrices para fuentes y Diseñar aplicaciones para UWP.
Cambios de tema
Para una aplicación Windows Phone Silverlight, el tema predeterminado es oscuro de forma predeterminada. En el caso de los dispositivos Windows 10, el tema predeterminado ha cambiado, pero puedes controlar el tema usado declarando un tema solicitado en App.xaml. Por ejemplo, para usar un tema oscuro en todos los dispositivos, agregue RequestedTheme="Dark" al elemento Application raíz.
Iconos
Los iconos para aplicaciones para UWP tienen comportamientos similares a los iconos dinámicos para Windows Phone aplicaciones de Silverlight, aunque hay algunas diferencias. Por ejemplo, el código que llama al método Microsoft.Phone.Shell.ShellTile.Create para crear iconos secundarios debe migrarse para llamar a SecondaryTile.RequestCreateAsync. Este es un ejemplo anterior y posterior, primero la versión de Windows Phone Silverlight:
var tileData = new IconicTileData()
{
Title = this.selectedBookSku.Title,
WideContent1 = this.selectedBookSku.Title,
WideContent2 = this.selectedBookSku.Author,
SmallIconImage = this.SmallIconImageAsUri,
IconImage = this.IconImageAsUri
};
ShellTile.Create(this.selectedBookSku.NavigationUri, tileData, true);
Y el equivalente de UWP:
var tile = new SecondaryTile(
this.selectedBookSku.Title.Replace(" ", string.Empty),
this.selectedBookSku.Title,
this.selectedBookSku.ArgumentString,
this.IconImageAsUri,
TileSize.Square150x150);
await tile.RequestCreateAsync();
El código que actualiza un icono con el método Microsoft.Phone.Shell.ShellTile.Update o la clase Microsoft.Phone.Shell.ShellTileSchedule, debe migrarse para usar las clases TileUpdateManager, TileUpdater, TileNotification o ScheduledTileNotification.
Para obtener más información sobre iconos, notificaciones del sistema, distintivos, banners y notificaciones, consulta Crear iconos y Trabajar con iconos, distintivos y notificaciones del sistema. Para obtener información específica sobre los tamaños de los recursos visuales usados para los iconos de UWP, consulta Icono y recursos visuales del sistema.
Tostadas
El código que muestra una notificación del sistema con la clase Microsoft.Phone.Shell.ShellToast debe migrarse para usar las clases ToastNotificationManager, ToastNotifier, ToastNotification o ScheduledToastNotification. Tenga en cuenta que en los dispositivos móviles, el término orientado al consumidor para "notificación del sistema" es "banner".
Consulte Trabajar con iconos, distintivos y notificaciones del sistema.
Vista o píxeles efectivos, distancia de visualización y factores de escala
Windows Phone aplicaciones de Silverlight y aplicaciones de Windows 10 difieren de la manera en que abstraen el tamaño y el diseño de los elementos de la interfaz de usuario lejos del tamaño físico real y la resolución de los dispositivos. Una aplicación Windows Phone Silverlight usa píxeles de vista para hacerlo. Con Windows 10, el concepto de píxeles de vista se ha refinado en el de píxeles efectivos. Esta es una explicación de ese término, lo que significa y el valor adicional que ofrece.
El término "resolución" hace referencia a una medida de densidad de píxeles y no, como se suele pensar, recuento de píxeles. "Resolución eficaz" es la forma en que los píxeles físicos que componen una imagen o glifo se resuelven en el ojo dadas las diferencias en la distancia de visualización y el tamaño de píxel físico del dispositivo (la densidad de píxeles es la recíproca del tamaño de píxel físico). La resolución eficaz es una buena métrica para crear una experiencia en torno a porque está centrada en el usuario. Al comprender todos los factores y controlar el tamaño de los elementos de la interfaz de usuario, puede hacer que la experiencia del usuario sea buena.
Para una aplicación de Windows Phone Silverlight, todas las pantallas de teléfono tienen exactamente 480 píxeles de vista ancho, sin excepción, independientemente de cuántos píxeles físicos tenga la pantalla, ni cuál es su densidad de píxeles o tamaño físico. Esto significa que un elemento Image con Width="48" será exactamente una décima parte del ancho de la pantalla de cualquier teléfono que pueda ejecutar la aplicación Windows Phone Silverlight.
Para una aplicación de Windows 10, no es el caso de que todos los dispositivos sean un número fijo de píxeles efectivos anchos. Es probable que sea obvio, dada la amplia gama de dispositivos en los que se puede ejecutar una aplicación para UWP. Diferentes dispositivos son un número diferente de píxeles efectivos de ancho, que van desde 320 epx para los dispositivos más pequeños, hasta 1024 epx para un monitor de tamaño modesto, y mucho más allá de anchos mucho más altos. Todo lo que tiene que hacer es seguir usando elementos de tamaño automático y paneles de diseño dinámico como siempre lo tiene. También habrá algunos casos en los que establecerás las propiedades de los elementos de la interfaz de usuario en un tamaño fijo en el marcado XAML. Un factor de escala se aplica automáticamente a la aplicación en función del dispositivo en el que se ejecuta y de la configuración de visualización realizada por el usuario. Y ese factor de escala sirve para mantener cualquier elemento de interfaz de usuario con un tamaño fijo que presente un destino táctil de tamaño más o menos constante (y lectura) al usuario en una amplia variedad de tamaños de pantalla. Además, junto con el diseño dinámico, la interfaz de usuario no solo escalará ópticamente en diferentes dispositivos, sino que hará lo necesario para ajustar la cantidad adecuada de contenido en el espacio disponible.
Dado que 480 era anteriormente el ancho fijo en píxeles de vista para una pantalla de tamaño telefónico, y ese valor suele ser más pequeño en píxeles efectivos, una regla general consiste en multiplicar cualquier dimensión en el marcado de la aplicación de Silverlight de Windows Phone por un factor de 0,8.
Para que la aplicación tenga la mejor experiencia en todas las pantallas, se recomienda crear cada recurso de mapa de bits en un intervalo de tamaños, cada uno adecuado para un factor de escala determinado. Proporcionar recursos a escala 100%, escala 200%y 400%-escala (en ese orden de prioridad) le dará excelentes resultados en la mayoría de los casos en todos los factores de escala intermedios.
Nota Si, por cualquier motivo, no puede crear recursos en más de un tamaño y, a continuación, crear recursos de escalado del 100 %. En Microsoft Visual Studio, la plantilla de proyecto predeterminada para aplicaciones para UWP proporciona recursos de personalización de marca (imágenes de mosaico y logotipos) en un solo tamaño, pero no son de escala del 100 %. Al crear recursos para su propia aplicación, siga las instrucciones de esta sección y proporcione un 100 %, un 200 % y un 400 % de tamaños y use paquetes de recursos.
Si tienes obras de arte complejas, es posible que quieras proporcionar tus recursos incluso más tamaños. Si empieza con el arte vectorial, es relativamente fácil generar recursos de alta calidad en cualquier factor de escala.
No te recomendamos que intentes admitir todos los factores de escala, pero la lista completa de factores de escala para aplicaciones de Windows 10 es del 100 %, 125 %, 150 %, 200 %, 250 %, 300 % y 400 %. Si los proporcionas, la Tienda elegirá los activos de tamaño correcto para cada dispositivo y solo se descargarán esos recursos. La Tienda selecciona los recursos que se van a descargar en función del PPP del dispositivo.
Para obtener más información, consulta Diseño dinámico 101 para aplicaciones para UWP.
Tamaño de la ventana
En tu aplicación para UWP, puedes especificar un tamaño mínimo (ancho y alto) con código imperativo. El tamaño mínimo predeterminado es 500x320epx y también es el tamaño mínimo más pequeño aceptado. El tamaño mínimo más grande aceptado es 500x500epx.
Windows.UI.ViewManagement.ApplicationView.GetForCurrentView().SetPreferredMinSize
(new Size { Width = 500, Height = 500 });
El tema siguiente es Migración de E/S, dispositivo y modelo de aplicación.