Migración de Windows Phone Silverlight a XAML para Windows en tiempo de ejecución 8

Migración de Windows Phone Silverlight a XAML para Windows en tiempo de ejecución 8

[ Este artículo está destinado a desarrolladores de Windows 8.x y Windows Phone 8.x que escriben aplicaciones de Windows en tiempo de ejecución. Si estás desarrollando para Windows 10, consulta la documentación más reciente

Nota  Para obtener información sobre la migración de una aplicación para la Plataforma universal de Windows (UWP) para Windows 10, consulta Migración de Windows Phone Silverlight a UWP.
 

Al migrar una aplicación Windows Phone Silverlight al modelo para las aplicaciones Windows en tiempo de ejecución XAML, la mayoría de tus conocimientos y experiencia se transferirá, así como gran parte del código fuente y los patrones de software que usas. Incluso el marcado y el diseño de interfaz de usuario se pueden migrar inmediatamente. Es posible que te sorprendas de lo relativamente fácil que es el proceso, incluso si te encuentras con algún desafío sobre la marcha.

Cuando leas esta guía de migración, puedes consultar el tema anterior a este: Asignaciones de espacios de nombres y clases de Silverlight de Windows Phone a Windows en tiempo de ejecución. La asignación suele ser bastante sencilla por regla general, pero existen algunas excepciones. En la tabla de asignaciones de espacios de nombres y clases se describen las excepciones, pero consulta también algunas excepciones en el nivel de función indicadas en la sección principal de este tema.

Encontrarás información general adicional acerca de aplicaciones de la Tienda Windows con XAML en la Guía básica para crear aplicaciones de Windows en tiempo de ejecución con C# o Visual Basic.

Enfoque de la migración capa a capa

  • Vista. La vista (junto con el modelo de vista) conforma la interfaz de usuario de la aplicación. Lo ideal es que la vista conste de marcado enlazado a propiedades observables de un modelo de vista. Otro patrón (común y conveniente, pero solo a corto plazo) es para el código imperativo en un archivo de código subyacente para manipular directamente elementos de la interfaz de usuario. En cualquier caso, gran parte del marcado y diseño de interfaz de usuario (incluso el código imperativo que manipula los elementos de la interfaz de usuario) serán sencillos de migrar.
  • Modelos de vistas y modelos de datos. Aunque no adoptes formalmente patrones de separación de cuestiones (por ejemplo, MVVM), inevitablemente hay código presente en la aplicación que realiza la función de modelo de vista y modelo de datos. El código del modelo de vista usa tipos en los espacios de nombres del marco de trabajo de la interfaz de usuario. Tanto el modelo de vista como el modelo de datos usan además un sistema operativo no visual y las API de .NET Framework (incluidas las API para el acceso a datos). Y la mayoría de ellas están disponibles para aplicaciones de Windows en tiempo de ejecución, por lo que se puede esperar poder migrar gran parte de este código sin cambios. Pero recuerda: un modelo de vista es un modelo, o abstracción, de una vista. Un modelo de vista proporciona el estado y el comportamiento de la interfaz de usuario, mientras que la vista en sí proporciona los elementos visuales. Por este motivo, cualquier interfaz de usuario que adaptes a los diferentes factores de forma en los que Windows en tiempo de ejecución te permite ejecutar probablemente necesitará los cambios de modelo de vista correspondientes.
  • Servicios en la nube. Es probable que parte de la aplicación (quizás una gran parte) se ejecute en la nube en forma de servicios. La parte de la aplicación que se ejecuta en el dispositivo cliente se conecta a ellos. Esta es la parte de una aplicación distribuida que probablemente no se modificará al migrar la parte del cliente. Si aún no tienes uno, una buena opción de servicios en la nube para tu aplicación universal de Windows es Servicios móviles de Microsoft Azure, que proporciona componentes back-end eficaces que las aplicaciones universales de Windows pueden llamar para servicios que van desde sencillas notificaciones de actualizaciones de iconos dinámicos hasta la clase de escalabilidad de tareas difíciles que puede proporcionar una granja de servidores.

Antes o durante la migración, considera la posibilidad de si la aplicación podría mejorarse mediante la refactorización de modo que el código con un propósito similar se agrupe en capas y no se disperse arbitrariamente. La factorización de la aplicación universal de Windows en capas, como las descritas anteriormente, facilita corregir la aplicación, probarla y posteriormente leerla y mantenerla. Puedes hacer más reutilizable las funciones (y evitar algunos problemas de diferencias de API de interfaz de usuario entre plataformas) siguiendo el patrón Model-View-ViewModel (MVVM). Este patrón mantiene separadas entre sí las partes de la aplicación correspondientes a los datos, al negocio y a la interfaz de usuario. Incluso dentro de la interfaz de usuario, puede mantener separados el estado y el comportamiento, además de poderse probar por separado, desde los elementos visuales. Con MVVM, puedes escribir una vez la lógica de datos y de negocio y usarla en todas las plataformas. También es muy probable que gran parte del modelo de vista y de las partes de vista se puedan reutilizar entre plataformas, también, aunque eso varía entre aplicaciones.

Manifiesto del paquete de aplicaciones

Es importante saber cómo editar el manifiesto del paquete de aplicaciones, porque en los temas siguientes se habla sobre el uso de diversas declaraciones, capacidades y otras opciones de configuración que necesitan algunas funciones. Puedes usar el editor de manifiestos del paquete de aplicaciones de Visual Studio para editarlo. Si el Explorador de soluciones no se muestra, selecciónalo en el menú Ver. Haz doble clic en Package.appxmanifest. Esto abre la ventana del editor de manifiestos. Selecciona la pestaña apropiada para realizar cambios y, a continuación, guarda.

En esta sección

TemaDescripción

Migración del proyecto

El proceso de migración se empieza creando un nuevo proyecto de Windows en tiempo de ejecución (un tipo de proyecto de la Tienda) en Visual Studio y copiando los archivos en él. Si optas por crear un proyecto de aplicación universal, podrás admitir PC, tabletas y teléfonos a partir de un código base.

Solución de problemas

Recomendamos leer hasta el final esta guía de migración, pero también sabemos que estás ansioso por seguir avanzando y llegar a la fase de compilación y ejecución de tu proyecto. Con esto en mente, puedes avanzar temporalmente si comentas o quitas cualquier código que no sea esencial y más tarde regresas allí para restaurar lo que has quitado. La tabla de solución de problemas de síntomas y soluciones de este tema puede resultarte útil en esta etapa, aunque no sustituye la lectura de los siguientes temas. Siempre puedes consultar la tabla a medida que avances a través de los temas posteriores.

Migración de XAML y la interfaz de usuario

La práctica para definir la interfaz de usuario en forma de marcado XAML declarativo se traslada muy bien desde Windows Phone Silverlight a las aplicaciones de Windows en tiempo de ejecución. Encontrarás que grandes secciones del marcado son compatibles, una vez hayas actualizado las referencias de clave de recurso del sistema, cambiado algunos nombres de tipos de elementos y cambiado "clr-namespace" por "using".

Migración de modelo de E/S, dispositivos y aplicaciones

El código que se integra con el dispositivo y sus sensores implica la entrada del usuario y la salida de este. También puede implicar el procesamiento de datos. Pero este código generalmente no se considera como la capa de interfaz de usuario o la capa de datos. Este código incluye la integración con el controlador de vibración, el acelerómetro, el giroscopio, el micrófono y los altavoces (que se relacionan con el reconocimiento y la síntesis de voz), la localización (geográfica) y las modalidades de entrada, como, por ejemplo, entrada táctil, mouse, teclado y lápiz.

Migración de capas de negocio y de datos

Detrás de la interfaz de usuario se encuentran las capas de negocio y de datos. El código de estas capas llama a las API del sistema operativo y de .NET Framework (por ejemplo, proceso en segundo plano, ubicación, cámara, sistema de archivos, red y acceso a otros datos). La mayoría de ellas están disponibles para aplicaciones de Windows en tiempo de ejecución, por lo que posiblemente podrás migrar gran parte de este código sin cambios.

Migración para factor de forma y experiencia del usuario

Las aplicaciones de Windows comparten una apariencia y un funcionamiento comunes entre equipos, tabletas y teléfonos. La interfaz de usuario, las entradas y los patrones de interacción son muy similares, y un usuario que se mueve entre dispositivos agradecerá la experiencia familiar. Pero las diferencias prácticas entre dispositivos como el tamaño físico, la orientación predeterminada y el factor de resolución en píxeles efectivos se deben tener en cuenta en el diseño de una aplicación para Windows universal.

Caso práctico: Bookstore1

En este tema presentamos un caso práctico de migración de una aplicación para Windows Phone Silverlight muy simple a una aplicación universal de Windows (mediante Windows en tiempo de ejecución o WinRT). La aplicación consta de un enlace ListBox a un modelo de vista. El modelo de vista tiene una lista de libros que muestra el título, el autor y la portada de libro.

Caso práctico: Bookstore2

Este caso práctico, que se basa en la información proporcionada en Bookstore1, comienza con una aplicación Windows Phone Silverlight que muestra datos agrupados en un LongListSelector. En el modelo de vista, cada instancia de la clase Author representa el grupo de los libros escritos por ese autor y en LongListSelector podemos ver la lista de libros agrupados por autor, o bien podemos alejar la vista para ver una lista de accesos directos a autores.

Caso práctico: Bookstore3

Este caso práctico es el tercero de una serie que muestra cómo portar aplicaciones de Windows Phone Silverlight a aplicaciones universales de Windows (mediante Windows en tiempo de ejecución o WinRT). Pretende complementar las técnicas de puerto que hemos visto en Bookstore1 y Bookstore2, y la aplicación que veremos aquí agrega nuevas funciones importantes para su modelo de vista y su interfaz de usuario.

 

Temas relacionados

Asignaciones de espacios de nombres y clases de Silverlight de Windows Phone a Windows Runtime.
Referencia de Windows en tiempo de ejecución
Introducción a .NET para aplicaciones de la Tienda Windows
.NET para aplicaciones de la Tienda Windows
Diseño de la experiencia de usuario para aplicaciones

 

 

Mostrar:
© 2017 Microsoft