Migrar de Silverlight o código XAML en WPF a una aplicación de la Tienda Windows

Applies to Windows and Windows Phone

Si estás familiarizado con otras plataformas basadas en XAML, como Windows Presentation Foundation (WPF), Microsoft Silverlight o Silverlight para Windows Phone, puedes aprovechar estos conocimientos para crear aplicaciones de la Tienda Windows. En este tema se enumeran las diferencias de alto nivel que debes tener en cuenta a la hora de migrar el código y el XAML desde tu aplicación WPF o Silverlight original.

Nota  Si vas a migrar una aplicación de Windows Phone que usa XAML, consulta Recursos para desarrolladores de Windows.

Guía básica: ¿Qué relación tiene este tema con los demás? Consulta: Guía básica para crear aplicaciones de Windows en tiempo de ejecución con C# o Visual Basic.

Técnicas generales para portar XAML y código

Cuando migras código y XAML que antes se escribieron para otro marco de interfaz de usuario, como WPF o Silverlight, los pasos de migración van más allá de actualizar entre versiones del mismo marco, por ejemplo. Aún así, si usas este tema para identificar las áreas en las que existen diferencias en la API y el modelo de programación, podrás reutilizar partes del código y de XAML. La mejor manera de hacerlo es integrar estas partes en el código y la estructura XAML que consigues con una plantilla de nuevo proyecto de Microsoft Visual Studio para una aplicación de la Tienda Windows con C++, C# o Visual Basic. De esta forma, conseguirás una estructura de navegación adecuada para tus páginas XAML y los espacios de nombres de Windows en tiempo de ejecución para tu código subyacente. Si necesitas más páginas XAML o más código, usa las opciones Agregar nuevo para empezar con una página o un archivo de código de aplicación de la Tienda Windows, copia el código o XAML originales como segmentos en el nuevo archivo o página y luego realiza las conversiones necesarias en las líneas.

El resto de las secciones de este tema tratan diversas áreas de características compartidas por los marcos de interfaz de usuario iniciales y las aplicaciones de la Tienda Windows. Lee estas secciones para tener una visión general de las diferencias y lo que podrías hacer para que tu código y XAML migrados funcionen para una aplicación de la Tienda Windows.

Nuevo diseño y comportamiento

Las aplicaciones de la Tienda Windows tienen un comportamiento y una apariencia únicos (personalidad) que las diferencia de otras aplicaciones, como las que creaste usando otras plataformas basadas en XAML. Asegúrate de tomarte tu tiempo para aprender los procedimientos recomendados para crear una aplicación de la Tienda Windows excelente. Solucionar los aspectos de diseño cuando se crea una aplicación de la Tienda Windows a menudo supone tener que rediseñar una parte sustancial de la interfaz de usuario. En concreto, es posible que tengas que rehacer la forma en que tratas los cuadros de diálogo, los menús, los comandos de entrada y las listas para seguir las pautas de diseño. Consulta los temas sobre cómo crear aplicaciones de la Tienda Windows sobresalientes y las directrices sobre la experiencia del usuario para aplicaciones de la Tienda Windows.

Objeto de aplicación y Modelo de aplicaciones

  • El modelo de aplicaciones para la activación y la duración de la aplicación es diferente, porque las aplicaciones se pueden suspender y reanudar. Para obtener más información, consulta Inicio, reanudación y multitarea.
  • La etiqueta Application en app.xaml no puede usarse para adjuntar eventos de vigencia de aplicación; la conexión de eventos, como Suspending, debe realizarse como parte de la lógica de inicio en el archivo de código subyacente app.xaml.
  • El objeto Window es menos directamente equivalente a una aplicación HWND desde la perspectiva de programación de Microsoft Win32. Algunas de las características basadas en ventanas avanzadas se exponen en un objeto separado, que puedes obtener usando el valor de la propiedad Window.CoreWindow.
  • Por otro lado, si vienes de la perspectiva de una aplicación de Silverlight, ya no tendrás el host de explorador como límite de programación intermedio: tu aplicación de la Tienda Windows se ejecuta directamente en Windows en tiempo de ejecución. Esto simplifica las cosas, ya que elimina los problemas de hospedaje del explorador con los que Silverlight tenía que lidiar, como el control de entrada que debía atravesar una capa de acceso a programas, acceso de almacenamiento limitado y un modelo de seguridad y almacenamiento en caché centrado en Internet.
  • Las aplicaciones de Silverlight pueden empaquetar partes de la aplicación en el paquete de implementación, como partes externas, o descargar componentes a petición. Una aplicación de la Tienda Windows también ofrece estas opciones, pero las API usadas para obtener acceso a partes del paquete son diferentes. Donde Silverlight usa Application.GetResourceStream, una aplicación de la Tienda Windows usa un modelo más generalizado, en el que el paquete instalado es tan solo una carpeta de almacenamiento. Por ejemplo, puedes obtener el valor de la propiedad Package.InstalledLocation y después llamar a una variedad de API de StorageFolder (la mayoría de las cuales son asincrónicas), a fin de obtener cualquier otro componente empaquetado. Para obtener más información, consulta Crear y recuperar recursos en aplicaciones de la Tienda Windows.
  • El modelo de aplicaciones de Windows en tiempo de ejecución emplea un concepto de funcionalidad. Debes declarar una funcionalidad como parte del proceso de desarrollo e implementación, y un usuario podrá ver en la interfaz de usuario de la Tienda Windows que la aplicación ha solicitado una funcionalidad en particular. Es posible que debas solicitar funcionalidades para acceder al almacenamiento de la biblioteca de un usuario, para usar API de cámara web, etc. Esto puede significar tener que solicitar una funcionalidad de Windows en tiempo de ejecución para poder acceder a código que solía funcionar en Silverlight y WPF, incluso cuando has convertido el código correctamente en un nivel de sintaxis. Para más información, consulta el tema sobre las declaraciones de funcionalidad de las aplicaciones.
  • Iniciar una aplicación directamente desde un icono no es la única forma de activar una aplicación de la Tienda Windows. Así, existe la posibilidad de iniciarla mediante asociaciones de archivo, mediante un contrato de Reproducir en, etc. Para tener esto en cuenta, hay que definir la persistencia de estado de la aplicación como datos de la aplicación y procurar que la aplicación disponga de todos los datos que necesita para iniciarse en cualquier escenario de activación posible. Para obtener más información, consulta Cómo activar una aplicación y otros temas en Inicio, reanudación y multitarea.

Programación en .NET y proyección de tipo

La arquitectura de Windows en tiempo de ejecución se basa en el principio de que los desarrolladores pueden usar diferentes lenguajes para acceder a los mismos conceptos y a la misma funcionalidad de Windows en tiempo de ejecución subyacentes. Un aspecto de cómo cada uno de los diferentes lenguajes puede programar en Windows en tiempo de ejecución y, además, conservar características o patrones del lenguaje es la proyección de tipos. En el caso de los lenguajes de Microsoft .NET, los desarrolladores de esos lenguajes están familiarizados con el sistema de tipos .NET y con los conceptos, los tipos y los primitivos implementados por el ensamblado mscorlib de .NET.

Existe una lista de tipos que están específicamente proyectados para .NET cuando se programa para Windows en tiempo de ejecución. Estos tipos existen en el ensamblado mscorlib y en el espacio de nombres System, o bien se agregan específicamente a uno de los ensamblados WindowsRuntime que se incluyen como ensamblados de referencia de .NET para la programación de Windows en tiempo de ejecución.

  • Las interfaces de colección comunes se proyectan como las interfaces de colección que conocen los programadores de .NET. IVector<T> se proyecta como IList<T>. IMap<K,V> se proyecta como IDictionary<TKey,TValue>. Los tipos enumerables admiten la sintaxis foreach y métodos de extensión relacionados a través de System.Linq. Las clases de vista relacionadas y las variantes de solo lectura tienen proyecciones similares. A través de estas proyecciones, cualquier clase de Windows en tiempo de ejecución que implemente una interfaz de colección puede admitir la API de la interfaz de colección de .NET proyectada.

  • Uri se proyecta como System.Uri. (Sin embargo, existen algunas diferencias significativas. Para conocerlas, consulta la sección sobre URI).

  • Los "primitivos" comunes se proyectan como el tipo mscorlib/System que los desarrolladores ya conocen de la programación de .NET. Por ejemplo, cualquier código de aplicación que implique un valor double puede usar la API proporcionada para System.Double cuando se programa con un lenguaje .NET.

  • Las API de .NET que interactúan con el sistema de tipo pueden hacer referencia a la clase .NET System.Type, y se puede usar el operador typeof en el código de Windows en tiempo de ejecución. (Nota: si estás realizando tareas de interop o estás usando C++ para parte del código, C++ tiene un operador typeid, si bien presenta limitaciones frente a typeof.)

  • IReference<T> se proyecta como Nullable<T> para .NET y habilita la sintaxis del lenguaje, como bool?, para representar un valor booleano que acepta valores NULL.

  • EventHandler<T> se proyecta como System.EventHandler<TEventArgs> para .NET.

  • HResult se proyecta como System.Exception para .NET. También se puede extraer la información del mensaje de un error de Windows en tiempo de ejecución en función de cada API, así como proveer a un desarrollador de .NET de la excepción con tipo correspondiente basada en System.Exception. Puedes usar try-catch y técnicas similares para tu control de excepciones y puedes controlar muchas de las excepciones .NET estándar con las que ya estés familiarizado. Para obtener más información, consulta Control de excepciones para aplicaciones de Windows en tiempo de ejecución con C# o Visual Basic.

  • Los modelos ICommand usan la definición de .NET (System.Windows.Input.ICommand).
  • Las interfaces que usaste para objetos de negocios escritos en .NET compatibles con enlaces se traducen cuando usas el objeto como un origen de datos de Windows en tiempo de ejecución. Por ejemplo, un enlace puede responder a PropertyChanged o CollectionChanged según cómo esté implementado en una clase de objeto de negocios escrita originalmente para WPF o Silverlight.

  • Muchas de las estructuras que comúnmente se usan como tipos de valor para la programación de la interfaz de usuario de XAML se proyectan como estructuras que tienen métodos de utilidad disponibles. Estas estructuras tienen el mismo nombre y la misma ubicación de espacio de nombres, pero hacen referencia en un ensamblado de WindowsRuntime para que los métodos de utilidad se admitan para.NET. Por ejemplo, los programadores de .NET pueden usar la API de utilidad de Matrix3D, como HasInverse, o los operadores integrados. (C++/CX admite también un determinado nivel de utilidad para sus estructuras, que también se implementa como una proyección, pero de manera más restrictiva.)

  • Un concepto relacionado es que una vez que un tipo se proyecta como tipo de .NET, puede admitir métodos de extensión de .NET. Esto habilita los métodos de extensión de .NET que están específicamente destinados para la programación de aplicaciones de la Tienda Windows. Por ejemplo, un tipo de .NET existente, como StreamReader, puede admitir métodos que usan modelos async similares a los que se encuentran en las API de Windows.Storage.

  • El tipo base de todos los objetos de tiempo de ejecución aparece como System.Object, y tiene la API System.Object esperada como ToString. Sin embargo, hay algunas pequeñas diferencias en las implementaciones de dichos métodos cuando se ejecutan en Windows en tiempo de ejecución. A menudo, estas diferencias se explican en la documentación de referencia sobre .NET, en una sección de notas para Windows en tiempo de ejecución.

Nota  El propósito de las proyecciones de tipo es ayudar en escenarios de migración de código y XAML, en concreto, si estás migrando el código subyacente de páginas XAML, de objetos de negocios o de clases de lógica con almacenamiento. Para la mayoría, no tendrás que indagar si un tipo de tu código original es realmente un tipo proyectado en Windows en tiempo de ejecución. Los compiladores y las plantillas de proyecto harán lo que es correcto automáticamente.

Incluso cuando uses tipos que se proyectan, quizá necesites referencias de espacios de nombres para casos en los que las proyecciones estén ahí para admitir el tiempo de ejecución, pero no formen parte de las bibliotecas de marcos principales de .NET ni estén definidas en espacios de nombres de .NET existentes, como System.Collections.Generic. Por ejemplo, si tienes código C# que usa la estructura de Point, aún necesitarás una declaración using que haga referencia al espacio de nombres de Windows.Foundation, porque ese es el modo en el que también se define el Point proyectado.

Para más información sobre .NET y la aplicación de la Tienda Windows creada con programación de C++, C# o Visual Basic, consulta Introducción a .NET para aplicaciones de la Tienda Windows.

Modelo de programación general

  • Si no programas con un lenguaje .NET, sino que lo haces con extensiones de componente de Visual C++ (C++/CX), muchas de las estructuras tendrán una definición de estilo C básica que no admite miembros que no son de datos.
  • El modelo de programación tiene sintaxis integrada para operaciones asincrónicas. Este tipo de operaciones es más frecuente en el modelo de programación de lo que lo era en WPF o Silverlight. El objetivo de las API asincrónicas consiste en reforzar los patrones que dificultan el bloqueo no intencionado del subproceso de interfaz de usuario en una devolución de llamada o un controlador de eventos. Para obtener más información, consulta Inicio rápido: Llamada a API asincrónicas en C# o Visual Basic.
  • Los modelos asincrónicos y otras tareas en segundo plano que no estén en el subproceso de interfaz de usuario quizá precisen de llamadas desde otros subprocesos que, en algún momento, actualizarán el subproceso de interfaz de usuario de manera asincrónica. La API que se usa para pasar por los subprocesos (por lo general, desde un subproceso en segundo plano al subproceso de la interfaz de usuario) es la misma que en Silverlight, DependencyObject.Dispatcher.
  • El archivado y el acceso a almacenamiento que se realizaba con las API de ensamblado de mscorlib y system ahora se realizan con API de sistema dedicadas, como StorageFile.
  • Si programas con un lenguaje de .NET, también puedes usar la lógica basada en System.IO.Stream existente. Puedes acceder a los métodos de extensión que devuelven una transmisión por secuencias desde tipos de Windows en tiempo de ejecución similares, por ejemplo, llamando al método de extensión AsStream en una instancia de IRandomAccessStream. En un editor de código, la API System.IO.Stream aparecerá como opciones en las listas desplegables de Microsoft IntelliSense siempre que tengas instancias de Stream obtenidas de tipos de búfer/transmisión por secuencias relacionadas.

Navegación

El modelo de navegación de Silverlight usaba páginas XAML, ya sea sueltas o en el paquete, como base para apuntar al contenido al cual navegar. Las aplicaciones de la Tienda Windows usan tipos y, en particular, el tipo que se indica como x:Class para una página XAML. Un buen plan sería usar la funcionalidad Agregar nuevo desde el Explorador de soluciones para crear nuevas páginas XAML dentro de la plantilla de proyecto de la aplicación de la Tienda Windows que prefieras. Importa los elementos que se encuentran por debajo del nivel de raíz de la página de Silverlight original y soluciona cualquier otro problema de conversión que pueda existir. Después aumenta tu estructura de navegación usando un Frame en la página principal. Como alternativa, crea un nuevo proyecto mediante las plantillas Aplicación de cuadrícula o Aplicación dividida, que incluyen páginas que ya tienen un marco de navegación, más plantillas de estado de visualización y lógica de suspensión y reanudación. También se podría usar la plantilla Aplicación de concentrador y estrategia de navegación. Para obtener más información, consulta la Parte 3: Navegación, diseño y vistas o el tema sobre cómo agregar un control Page.

En Windows en tiempo de ejecución, las clases Page y Frame están en el conjunto de controles predeterminado, mientras que, en Silverlight, estas provenían de las bibliotecas del SDK y debían distribuirse. Si vas a migrar XAML que contiene elementos Page o Frame, puedes quitar el prefijo "sdk:" de dichos elementos y la asignación xmlns correspondiente al prefijo "sdk:". Las páginas pueden reemplazar a OnNavigatedTo y OnNavigatedFrom si necesitan realizar acciones de limpieza durante la acción de navegación, aunque también hay eventos y reemplazos disponibles en la clase Frame (Navigated, por ejemplo), de modo que puede que te interese poner la lógica de navegación en Frame en lugar de en páginas individuales. Además, donde Frame de Silverlight tenía botones de exploración sencillos, las características de exploración de Windows en tiempo de ejecución están integradas con las plantillas de página y usan plantillas y estilos dedicados para los propios botones. Para obtener más información, consulta Inicio rápido: navegar entre páginas.

Iconos y notificaciones

Las características de iconos y notificaciones tienen niveles de compatibilidad variables en marcos XAML anteriores, de modo que no hay un método general para convertirlas. Para obtener más información sobre cómo funcionan estas características en una aplicación de la Tienda Windows, consulta Trabajar con iconos, notificaciones y notificaciones del sistema. Si tu aplicación usa notificaciones de inserción de Windows Phone, consulta Recursos para desarrolladores de Windows Phone.

Uso de .NET Framework

En las aplicaciones de la Tienda Windows con lenguajes .NET (C# o Microsoft Visual Basic), las API de .NET Framework a las que llamas son parte de un perfil particular de .NET Framework. Esta relación se explica en detalle en el tema Introducción a .NET para aplicaciones de la Tienda Windows.

Funcionalidades de lenguaje de XAML

XAML para Windows en tiempo de ejecución es muy similar a XAML para Silverlight en lo que atañe a las funcionalidades que forman parte del lenguaje de XAML propiamente dicho, y muy similar también a XAML para WPF. Pero hay algunas diferencias.

  • En lugar de usar el calificador clr-namespace:/assembly= establecido para referencias de espacio de nombres de código a XAML, usas el calificador using:. Los espacios de nombres de XAML ya no hacen referencia a ensamblados específicos. Toda la inclusión y calificación de ensamblados se controla mediante el Modelo de aplicaciones y en función del modo en que compones el paquete de la aplicación.
  • Dado que no puedes asignar ensamblados específicos, ya no funcionan algunas de las referencias que se realizaron a mscorlib para admitir primitivos de Common Language Runtime. En cambio, puedes usar los tipos intrínsecos de lenguaje de XAML, como x:String. Para más información, consulta el tema sobre los tipos de datos intrínsecos de XAML. Además, considera que muchas de las cadenas que almacenaste antes como x:String en un ResourceDictionary probablemente se almacenen mejor como una cadena en un archivo de recursos del proyecto. Para obtener más información, consulta Globalización de la aplicación.
  • XAML para Windows en tiempo de ejecución no admite extensiones de marcado personalizadas.
  • En raras ocasiones, es posible que el XAML en el que se aceptó un atributo Name sin prefijo en Silverlight requiera un atributo x:Name en su lugar.
  • En algunos casos en los que funcionaba una propiedad Setter.Property sobrecalificada en el XAML de Silverlight, esta ya no funciona en el XAML de Windows en tiempo de ejecución. La mayor parte de los valores de Setter.Property deben ser simplemente el nombre sencillo de la propiedad de dependencia, sin el objetivo de calificar a su propietario (las propiedades adjuntas son una excepción, aún las debe calificar el propietario).
  • Si migras XAML desde WPF, existen construcciones que XAML para Windows en tiempo de ejecución no admite, aparte de las diferencias de XAML de Silverlight ya mencionadas. Se trata de los siguientes: la extensión de marcado DynamicResource(y el comportamiento de búsqueda de recursos subyacente), x:ClassModifier y x:Subclass, x:Array y la compatibilidad con los aspectos genéricos de XAML 2009 relacionados, x:Code, x:Static, x:Type utilizado explícitamente (hay evaluación de x:Type implícita para las propiedades que lo necesitan), los nodos VisualTree en plantillas y algunas otras diferencias de carácter menor. Debes poder capturar los problemas de compatibilidad con XAML en la fase de diseño basándote en las excepciones del análisis de XAML.

Entrada y funcionalidad táctil

  • No existen eventos de entrada específicos del mouse, como MouseLeftButtonDown. Estos eventos, junto con eventos específicos de entrada táctil, se unifican bajo los eventos Pointer. En la mayoría de los casos, puedes convertir el evento de mouse relevante a PointerPressed, PointerReleased, PointerEntered o PointerExited. Para obtener más información, consulta el tema sobre cómo responder a la interacción con el usuario. Para MouseWheel, usa el evento PointerWheelChanged. El diferencial de la rueda puede verse en la clase PointerPointProperties del PointerPoint principal de los datos del evento.
  • Si controlabas manipulaciones sin procesar para permitir acciones en controles y creaste estados visuales para el control de manipulaciones, debes confirmar que los controles que uses no tengan ya integrada la compatibilidad para manipulaciones o gestos. Por ejemplo, ListBox de Windows en tiempo de ejecución tiene varias interacciones ya habilitadas como transiciones de tema.
  • Para las interacciones en general, considera la posibilidad de controlar los eventos de gesto en lugar de los eventos de puntero, dado que suele ser más fácil. Por ejemplo, Tapped suele ser un evento mejor en el modelo de eventos de Windows en tiempo de ejecución para las interacciones que serían controladas por un evento específico del mouse en Silverlight.
  • Se pueden habilitar o deshabilitar interacciones táctiles específicas para cada elemento individual mediante las propiedades. Por ejemplo, puedes establecer IsRightTapEnabled en false y ese elemento no originará un evento RightTapped. El objetivo es evitar posibles problemas con el reconocimiento de gestos y manipulación cuando los eventos se propagan por un árbol visual de composición de controles.
  • Las claves para los eventos de clave no tienen una separación PlatformKeyCode/Key. La clave notificada desde los datos del evento usa una enumeración diferente, VirtualKey, y los demás datos de evento de clave se encuentran disponibles como KeyStatus.
  • La captura de puntero de UIElement puede capturar varios punteros para admitir las manipulaciones táctiles que inician la captura. Para obtener la referencia de puntero correcta, usa una clase de datos de un evento relacionado con punteros, como PointerRoutedEventArgs.
  • Las llamadas a Control.Focus deben especificar un valor de enumeración que indique que la acción con el foco se estableció mediante programación. Windows en tiempo de ejecución separa las llamadas de foco porque sus estados visuales usan un comportamiento diferente para las llamadas de foco mediante programación. Puede que debas agregar a tus plantillas nuevos estados visuales personalizados para el foco que no se realiza con el teclado.
  • Algunos controles de Windows en tiempo de ejecución llevan integrado el control de manipulaciones. Así, por ejemplo, ScrollViewer controla internamente las interacciones de desplazamiento, movimiento panorámico y zoom, por lo que el control devuelve la respuesta de acción adecuada. Este control puede evitar que se activen eventos de puntero de nivel inferior. Puedes llamar a CancelDirectManipulations para invalidar este comportamiento. Quizás también quieras revisar cómo se administran en general las entradas en tus controles. Es posible que exista un comportamiento integrado que ya abarque tu escenario, en cuyo caso no es necesario un controlador de nivel de puntero.

Gráficos y composición o diseño de elementos

  • Para poder optimizar de la mejor manera el elemento establecido para las funcionalidades de la nueva pila de gráficos, eliminamos algunos conceptos o API que reducirían la velocidad de representación. Algunos ejemplos son OpacityMask, imágenes no rectangulares, funciones de aceleración personalizadas y efectos de mapa de bits.
  • VideoBrush no se admite en Windows en tiempo de ejecución; tampoco se admite RadialGradientBrush.
  • La API de procesamiento de imágenes de Windows en tiempo de ejecución tiene un componente de digitalización subyacente distinto y más compatible, Windows Imaging Component. Lo bueno es que este componte admite más formatos de orígenes de imagen que Silverlight o incluso WPF. También dispones de tipos de codificador y descodificador fáciles de usar, y de algunas API adicionales para la manipulación de imágenes que ya está integrada en WIC. Para más información, consulta el tema sobre el espacio de nombres Windows.Graphics.Imaging.
  • BitmapCache tiene una lógica subyacente diferente de la que proporciona Silverlight, Silverlight para Windows Phone o WPF. Además, el almacenamiento en caché de mapas de bits puede tener una interrelación con las animaciones y puede provocar que algunas de ellas se consideren dependientes. Si acaso usas UIElement.CacheMode, debes volver a generar los perfiles de tu aplicación y analizar si el uso de un valor UIElement.CacheMode en algunas partes de la interfaz de usuario implica un mejor rendimiento en una aplicación de la Tienda Windows. Para obtener más información, consulta UIElement.CacheMode y DebugSettings.IsOverdrawHeatMapEnabled.
  • En algunos escenarios en los que hayas usado WriteableBitmap, puede que te interese usar RenderTargetBitmap en su lugar.

Controles

  • Las aplicaciones de la Tienda Windows y otros marcos que usan XAML para la definición de la interfaz de usuario tienen los mismos controles básicos, como Button y ListBox, y los mismos contenedores de diseño básicos, como Border, Grid y StackPanel. Windows en tiempo de ejecución tiene muchos controles listos para la colección, como SemanticZoom y FlipView. Además, GridView es un control independiente en lugar de un componente que se usa en una ListView, donde la única diferencia real entre GridView y ListView es la orientación dominante de los elementos presentados que usa cada una. Para obtener más información, consulta el tema sobre los controles por función.
  • Si bien muchas veces puedes usar el mismo control que usaste en la aplicación de Silverlight WPF original, y quizás hasta puedas migrar toda la interfaz de usuario a componentes equivalentes, este no siempre es el mejor enfoque. Sobre todo al migrar la interfaz de usuario de la aplicación, te recomendamos que te detengas un momento y repases la guía de diseño de las aplicaciones de la Tienda Windows una vez más. Por ejemplo, es posible que la aplicación original y los controles de su interfaz de usuario no se hayan diseñado para una experiencia táctil, mientras que la aplicación de la Tienda Windows debe estar diseñada para entrada táctil. La experiencia de interfaz de usuario global también será distinta, dado que el hospedaje ya no está en el explorador. Para obtener más información sobre diseño, consulta Diseño de la experiencia del usuario para aplicaciones. Para obtener más información sobre las directrices de la experiencia del usuario para controles, consulta el tema sobre el índice de directrices sobre la experiencia del usuario.

Animaciones, transiciones, estados visuales y estilos

  • Windows en tiempo de ejecución agrega el concepto de las animaciones de personalidad. Estas se pueden usar en XAML como animaciones de transición y animaciones de tema aplicadas directamente a elementos de la interfaz de usuario sin que sea necesario destinarlas a varias propiedades de esos elementos. Las animaciones de guiones gráficos funcionan prácticamente de la misma manera. Pero no todas están habilitadas de manera predeterminada. Las animaciones dependientes están deshabilitadas de manera predeterminada para que los desarrolladores se percaten de los costos de rendimiento de las animaciones que implicarían un impacto significativo en el subproceso de interfaz de usuario principal. Si la animación no se ejecuta como es debido, intenta establecer EnableDependentAnimations en true. Pero hazlo sensatamente, ya que la ejecución de animaciones dependientes implica un costo en el rendimiento. Para más información, consulta Animación de la interfaz de usuario Animaciones de guión gráfico y Suavizar las animaciones.
  • Si tienes algún prefijo "vsm:" en las definiciones de XAML de tu estado visual, quita los usos y la definición del prefijo. Ya no necesitas asignar prefijos de estado visual y espacios de nombres por separado.
  • Si vas a convertir estados visuales, asegúrate de convertir los conceptos de "mouse" en conceptos de "puntero", del mismo modo que cambiaste al control de eventos de nivel de elemento. También puede resultar conveniente cambiar el nombre de los propios estados visuales y ajustar las propiedades que cambiará el estado. Echa un vistazo a los diccionarios de recursos XAML como generic.xaml en la subcarpeta include/winrt/xaml/design de una instalación del SDK de Windows. Estos podrían sugerir modelos que puedes seguir para los estados visuales y los eventos relacionados.
  • Si ya tienes un tema de contraste alto existente para un control personalizado que has convertido, asegúrate de seguir el modelo de ThemeDictionaries al conectar los temas con la definición del control. En concreto, probablemente te resulte conveniente admitir los temas con nombre identificados en la enumeración HighContrastScheme. Para obtener más información, consulta el tema sobre la muestra de estilo de contraste alto XAML.
  • Si tu aplicación permite el intercambio de temas, debes admitir plantillas de tema tanto claro como oscuro. Las plantillas predeterminadas ya incorporan este aspecto, pero puede que necesites agregar un tema a cualquiera de las plantillas personalizadas que hayas importado.
  • WPF y Microsoft Silverlight permitían usar una expresión Binding para suministrar el Value de un Setter en un Style. Windows en tiempo de ejecución no admite el uso de Binding para Setter.Value (Binding no se evaluará y Setter no tiene efecto; no obtendrás errores pero tampoco los resultados deseados). Cuando conviertas estilos de XAML desde código XAML de WPF o Silverlight, reemplaza los usos de la expresión Binding con cadenas u objetos que establezcan valores, o refactoriza los valores como valores StaticResource compartidos en lugar de valores obtenidos mediante Binding.

Medios

  • Las API multimedia son similares, pero el modo en que la administración de derechos digitales (DRM) se integra con ellas es diferente. A diferencia de Silverlight, Windows tiene un modelo de DRM conectable y PlayReady es uno de los tantos que posiblemente se admitirían. Por ello, las API son diferentes para dar cuenta de un administrador de protección de contenido.

  • En gran medida, MediaElement es igual, aunque es probable que quieras definir una nueva plantilla XAML para las plantillas anteriores que tengan controles de transporte de MediaElement, a fin de que la interfaz de usuario sea compatible con una experiencia táctil. O puedes ver AreTransportControlsEnabled para obtener algunos controles de transporte predeterminados. Otras incorporaciones destacables de Windows en tiempo de ejecución a la API MediaElement incluyen la posibilidad de tener un "póster" para cargar, detectar y usar modos de empaquetado de vídeo y la capacidad de agregar efectos de vídeo.
  • La captura de cámara es conceptualmente diferente entre las plataformas; si tienes esta característica, lo que harás será reescribir el código en lugar de convertirlo. Para obtener más información, consulta Cómo obtener una vista previa de vídeo desde una cámara web y el tema sobre captura de multimedia con una muestra de dispositivo de captura. Probablemente usarás CaptureElement como la superficie de pantalla, porque VideoBrush no está disponible.

URI

El control de Identificador uniforme de recursos (URI) para referencias de archivo funciona de una manera un poco diferente en Windows en tiempo de ejecución. No se admiten los URI relativos, al menos no en el nivel de los tipos de URI puros. El System.Uri de .NET puede parecer que te da una opción de RelativeOrAbsolute en ciertas llamadas de API pero, en la práctica, todos esos URI son absolutos y se evalúan según conceptos y ubicaciones, como el paquete de la aplicación, las ubicaciones seleccionadas por el usuario, los datos de la aplicación, etc.

Es posible que se deba examinar cualquier valor de propiedad que tome un URI. No puedes usar URI de esquema file:. Es posible que puedas transferir XAML con referencias de URI a valores, como archivos Image.Source, sin tener que preocuparte para nada por problemas de URI, y hacerlo funcionar como la nueva interfaz de usuario de Windows. Pero esto depende de cómo se estructuró tu aplicación original. Cuando se especifica en XAML, un URI a menudo parece ser un URI relativo, pero el analizador de XAML procesa y completa estas cadenas antes de configurar cualquier propiedad en tiempo de ejecución. Para reproducir este mismo comportamiento en código subyacente, usa el FrameworkElement.BaseUri devuelto como valor del parámetro baseUri en el constructor de Uri que combina un URI base y un URI relativo. Para más información, consulta el tema sobre la definición de recursos de la aplicación.

API de almacenamiento y archivos

Las técnicas que usas para obtener acceso a archivos y almacenamiento en Windows en tiempo de ejecución son diferentes de las que usas en .NET, en especial, porque muchas de estas API usan un modelo asincrónico y las palabras clave async o await. Para más información, consulta Acceder a datos y archivos.

XML y XMLDOM

El área de .NET disponible para una aplicación de la Tienda Windows con C++, C# o Visual Basic no incluye parte de la API de XML DOM del marco, o reenvía algunos de los tipos base al espacio de nombres de Linq. Busca API similares en Windows.Data.Xml.Dom y System.Xml.Linq.

HTML hospedado y en paralelo

En Silverlight, el HTML en paralelo es sencillo porque el control de Silverlight se hospeda en un elemento DOM y el otro contenido HTML se encuentra en otro elemento DOM o en un iframe. O, en el caso de WPF, puede que hayas usado el control WebBrowser. En el caso de una aplicación de la Tienda Windows que usa XAML para su interfaz de usuario, el control que hay que usar para mostrar el contenido HTML es WebView. El modelo WebView es que el HTML se muestra en una región dentro de la interfaz de usuario de XAML global. El contenido HTML que muestras en una aplicación de la Tienda Windows debe examinarse por motivos de seguridad y de experiencia del usuario. No basta con redestinar lo que muestres en un iframe de la aplicación Silverlight de forma que sea el Source de una WebView. Tendrás también que examinar qué lógica deberías conservar como código JavaScript para HTML, en lugar de ejecutarla como código subyacente para la página. Tus decisiones aquí dependerán de cómo Windows en tiempo de ejecución procese los eventos de interacción del usuario dentro de los límites de WebView. Para obtener más información, consulta WebView.

Convertir proyectos

En términos generales, la conversión de la totalidad de un proyecto se efectúa de mejor forma comenzando por una de las plantillas de proyecto existentes para una aplicación de la Tienda Windows. A continuación, usa la función Agregar existente en el Explorador de soluciones para introducir páginas XAML nuevas o existentes y archivos de código subyacente. Finalmente, migra bloques específicos de código a los archivos de código y XAML. Si lo haces de esta manera, puedes evitar la infraestructura y los detalles de implementación del marco previo para proyectos y compilaciones que probablemente estén allí por accidente. Puedes usar la instrucción using/Imports con los espacios de nombres de "Windows" correctos, hacer referencia a los tipos de compilaciones actuales y acceder al sistema de recursos de .resw, porque todo esto estará disponible desde las páginas y los proyectos para los que recientemente se crearon plantillas.

Si el proyecto de Silverlight usa el sistema de localización basado en Binding, tal como se explica en el procedimiento para hacer que el contenido XAML sea localizable, debes considerar cambiar tu técnica de localización y usar cadenas que estén declaradas en el sistema de índice de recursos del paquete (PRI). El sistema de localización basado en Binding seguirá funcionando, pero no tendrá la compatibilidad con herramientas que es posible con los archivos PRI y .resw, tanto dentro de Visual Studio como para cualquier proceso de localización dedicado, ni con las herramientas basadas en la metodología de localización de Visual Studio.

Si eliges intentar traer archivos de código completo, con frecuencia puedes buscar y reemplazar las instrucciones using/Imports o las referencias totalmente calificadas. Por ejemplo, "System.Windows" debe reemplazarse con "Windows.UI.Xaml". Existen algunas excepciones a esta regla general de cómo se los tipos de Silverlight/WPF se relacionan con los tipos y los espacios de nombres de Windows en tiempo de ejecución, e incluiremos estos casos en la documentación de la API (en la sección de observaciones).

Para obtener más información sobre las plantillas del proyecto, consulta Plantillas de proyecto C#, VB y C++ para aplicaciones de la Tienda Windows.

Más recursos para migrar aplicaciones

Temas relacionados

Recursos para desarrolladores de Windows Phone
Guía básica para crear aplicaciones de la Tienda Windows con C# o Visual Basic
Directrices de experiencia del usuario para aplicaciones de la Tienda Windows
Plantillas de proyecto C#, VB y C++ para aplicaciones de la Tienda Windows
Introducción a .NET para aplicaciones de la Tienda Windows
Compatibilidad de .NET Framework con aplicaciones de la Tienda Windows y Windows en tiempo de ejecución

 

 

Mostrar:
© 2014 Microsoft