Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
El tema anterior fue 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 para la Plataforma universal de Windows (UWP). Verá que grandes secciones de su marcado son compatibles una vez que haya actualizado las referencias de claves de recursos del sistema, modificado algunos nombres de tipos de elementos y 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 elemento PhoneApplicationPage en la raíz del archivo XAML no es válido para un proyecto de la 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 elementos de <phone:PhoneApplicationPage> a <Page> (no olvide la sintaxis del elemento de propiedad) y puede eliminar la declaración de xmlns:phone.
Para obtener un enfoque más general para buscar el tipo de UWP que corresponde a un tipo de Windows Phone Silverlight, puedes hacer referencia a Espacio de nombres 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 difiere entre Windows Phone Silverlight y la 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 este aspecto:
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 está 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 la calificación del espacio de nombres como en el fragmento de arriba. 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 eliminar la directiva using de System.Windows.Media.Imaging, y eso será todo lo que se necesita para portar el código como en el fragmento anterior. Cuando hayas terminado, habrás quitado todos los espacios de nombres de Windows Phone Silverlight.
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 Resolver es una excelente manera de descubrir 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 que se quitan todas las directivas using antiguas y se agregan las nuevas, puede usar el comando de Organizar usos 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, consulte el resto de esta guía de portabilidad en combinación con la descripción general de .NET para aplicaciones de 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 marcar como pendiente cualquier código no esencial. A continuación, trata un problema a la vez y revisa los temas siguientes en esta sección (y el tema anterior: Resolución de problemas), hasta que se solucionen los problemas de compilación y tiempo de ejecución y se complete el proceso de portabilidad.
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 en el 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 un toast 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 las animaciones desde/hacia, la biblioteca de animaciones de UWP está disponible para aplicaciones 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: Animar la interfaz de usuario mediante animaciones de biblioteca.
Si usas animaciones de fotograma clave o animaciones de inicio/a fin en tus aplicaciones UWP, es posible que quieras comprender la distinción entre animaciones independientes y dependientes que ha introducido la nueva plataforma. Consulte Optimizar animaciones y multimedia. 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 redirigirlos para animar diferentes propiedades, como RenderTransform, haciéndolos 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 usa Blend de Visual Studio para crear nuevas animaciones, esa propiedad se establecerá automáticamente si es necesario.
Manejo 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 como un botón capacitivo en el dispositivo o como un botón en la carcasa. En un dispositivo de escritorio, agregas un botón al cromo de la aplicación siempre que sea posible la navegación hacia atrás 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 modo tableta (solo Windows 10). El evento del botón Atrás es un concepto universal en todas las familias de dispositivos, y los botones implementados en hardware o 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 cerrar la aplicación de forma programada.
Windows.UI.Xaml.Application.Current.Exit();
Vinculación y enlaces compilados con {x:Bind}
El tema de la encuadernación 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 en los espacios 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.
Las barras de aplicaciones y los botones de la barra de aplicaciones de Windows Phone Silverlight 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 de IDataErrorInfo y 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 idioma como parámetros en lugar de objetos CultureInfo.
- La clase CollectionViewSource de
no proporciona compatibilidad integrada para 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 de enlace de datos de .
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 el enlace de datos: mejora el rendimiento de tus aplicaciones con las nuevas funcionalidades de enlace de datos XAML y el ejemplo de x:Bind.
Vincular una imagen a un modelo de vista
Puede enlazar la propiedad
// 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 poder mantener el resto del código igual, puede usar una sobrecarga diferente del constructor de System.Uri para colocar el esquema URI ms-appx en un URI base y agregar 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 la ruta de la imagen y los enlaces del marcado XAML pueden mantenerse exactamente iguales.
Controles y estilos o plantillas de control
Las aplicaciones de Windows Phone 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 controles XAML en UWP son prácticamente iguales que los controles de Windows Phone 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 |
|---|---|
| Barra de Aplicaciones | La propiedad Page.TopAppBar de. |
| BotónDeIconoDeBarraDeAplicación | El equivalente de UWP es la propiedad glifo. PrimaryCommands es la propiedad contenido de CommandBar. El analizador XAML interpreta el xml interno de un elemento como el valor de su propiedad de contenido. |
| ElementoDeMenúDeBarraDeAplicación | El equivalente de UWP es el AppBarButton.Label establecido en el texto del elemento de menú. |
| ContextMenu (en el Kit de herramientas de Windows Phone) | Para un desplegable de selección única, use desplegable. |
| Clase TiltEffect de ControlTiltEffect | Las animaciones de la biblioteca de animaciones para UWP están integradas en los estilos predeterminados de los controles comunes. Consulte las acciones de punteros animados . |
| LongListSelector con datos agrupados | El LongListSelector de Windows Phone Silverlight funciona de dos maneras, que se pueden usar de manera conjunta. En primer lugar, puede mostrar los datos agrupados por una clave, por ejemplo, una lista de nombres agrupados por letra inicial. En segundo lugar, es capaz de "hacer zoom" entre dos vistas semánticas: la lista agrupada de elementos (por ejemplo, nombres) y una lista que contiene únicamente las claves del grupo (por ejemplo, letras iniciales). Con UWP, puedes mostrar datos agrupados con las directrices de para controles de vista de lista y 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 de Silverlight de Windows Phone incluso para datos planos y no agrupados. En una aplicación UWP, GridView se prefieren para listas largas de elementos, independientemente de si los datos se pueden agrupar o no. |
| Panorama | El control Panorama de Silverlight de Windows Phone corresponde a las directrices de para los controles del centro en aplicaciones de Windows Runtime 8.x y las directrices para el control del centro. Tenga en cuenta que un control Panorama se ajusta desde la última sección hasta la primera, y su imagen de fondo se mueve de forma paralela con respecto a las secciones. Las secciones del Hub no se ajustan y no se utiliza parallax. |
| Pivote | El equivalente UWP del control Pivot 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 aplicaciones de Windows Phone 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 Controles por función, Lista de controles, y Directrices para controles.
Lenguaje de diseño en Windows 10
Hay algunas diferencias en el lenguaje de diseño entre las aplicaciones de Windows Phone Silverlight y las 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: ser atentos a los detalles, pero siempre esforzarse por simplificar centrándose en el contenido, no en los elementos decorativos, reduciendo fieramente los elementos visuales y permaneciendo auténticos en el dominio digital; usar jerarquía visual especialmente con tipografía; diseñar en una cuadrícula; y dar vida a tus experiencias con animaciones fluidas.
Localización y globalización
Para las cadenas localizadas, puedes volver a usar el archivo .resx desde tu proyecto de Windows Phone Silverlight 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.
Las aplicaciones de Windows Phone Silverlight usan la clase CultureInfo de
El tema ResourceContext.QualifierValues describe cómo se cargan recursos específicos de la familia de dispositivos según el 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 caracteriza por 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 de RadialGradientBrush que no está presente en la UWP, aunque otros tipos de Brush sí lo están. 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 Microsoft DirectX y XAML C++ para UWP.
Windows Phone Silverlight tiene la propiedad System.Windows.UIElement.OpacityMask, pero esa propiedad no es miembro del tipo UIElement 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++. Sin embargo, 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 adaptados a los temas (como los diagramas 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 la OpacityMask 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 portar esto a una aplicación para UWP es usar un BitmapIcon, de esta 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, puede querer proporcionar diferentes tamaños de winrt_check.png para usarse con distintos factores de escalado. Para obtener más información al respecto y para una explicación de los cambios en los valores de Ancho y Altura, consulta Visualización o pixeles efectivos, distancia de visualización 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 Adaptar los recursos para el idioma, la 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 un geometry y normalmente se serializa en el marcado XAML en el StreamGeometry mini language. En UWP, el tipo de la propiedad Clip
<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 Microsoft DirectX y XAML C++.
Navegación
Cuando navegas a una página en una aplicación de Windows Phone Silverlight, usas 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*/);
Defina la página de inicio 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 UWP usan navegación basada en tipos, la cual es de tipo estricto y verificada por el compilador, y no tiene el problema que la asignación de URI soluciona. 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. Se puede lograr el mismo objetivo 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 de XAML subrayará una referencia a la clave de estilo PhoneTextNormalStyle con una línea ondulada roja. Si no se corrige, la aplicación finalizará inmediatamente cuando intente implementarla en el emulador o en el dispositivo. Por lo tanto, es importante prestar atención a la correctitud 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. Puede controlar su visibilidad en código imperativo llamando a los métodos Windows.UI.ViewManagement.StatusBar.ShowAsync y HideAsync.
Mensaje de 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. Utilice estas ilustraciones para encontrar los estilos del sistema UWP TextBlock 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 de TextBlock del sistema para aplicaciones de Windows 10
En una aplicación de 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 quieres reproducir el aspecto del texto de Windows Phone Silverlight, puedes establecer tus propias métricas mediante propiedades como LineHeight y LineStackingStrategy. Para obtener más información, consulta Directrices para fuentes y Diseño de aplicaciones UWP.
Cambios de tema
Para una aplicación de 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.
Azulejos
Los iconos para aplicaciones para UWP tienen comportamientos similares a los iconos dinámicos para aplicaciones de Windows Phone 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, TileNotificationy/o ScheduledTileNotification.
Para obtener más información sobre mosaicos, notificaciones emergentes, distintivos, banners y notificaciones, consulta Creación de mosaicos y Trabajar con mosaicos, distintivos y notificaciones emergentes. Para obtener información específica sobre los tamaños de los recursos visuales usados para los iconos de UWP, consulta recursos visuales de icono y notificación del sistema.
Brindis
El código que muestra una notificación emergente con la clase Microsoft.Phone.Shell.ShellToast debe ser migrado para utilizar las clases ToastNotificationManager, ToastNotifier, ToastNotification, y/o ScheduledToastNotification. Tenga en cuenta que en los dispositivos móviles, el término orientado al consumidor para "toast" es "banner".
Consulte Trabajar con iconos, distintivos y notificaciones del sistema.
Vista o píxeles efectivos, distancia de visualización y factores de escala
Las aplicaciones de Windows Phone Silverlight y las aplicaciones de Windows 10 difieren en la forma 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 de 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 ella 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 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, es no 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 tienen un ancho diferente de píxeles efectivos, 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á, a anchos mucho mayores. Solamente necesitas seguir usando elementos de tamaño automático y paneles de diseño dinámico como siempre lo has hecho. 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. Ese factor de escala ayuda a que cualquier elemento de la interfaz de usuario con un tamaño fijo ofrezca un objetivo táctil -y de lectura- de tamaño más o menos constante al usuario, sin importar la 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 es multiplicar cualquier dimensión en el marcado de la aplicación de Windows Phone Silverlight 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 100%-scale, 200%-scale y 400%-scale (en ese orden de prioridad) le proporcionará excelentes resultados en la mayoría de los casos en todos los factores de escala intermedios.
Nota Si, por cualquier motivo, no puede crear activos en más de un tamaño, entonces cree 100 activos a escala%. 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 100%-scale. Al crear recursos para su propia aplicación, siga las instrucciones de esta sección y proporcione 100%, 200%y 400 tamaños de% y use paquetes de recursos.
Si tienes obras de arte complejas, es posible que desees ofrecer tus recursos en un mayor número de 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 las aplicaciones de Windows 10 es 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 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 Portabilidad para E/S, dispositivo y modelo de aplicación.