Migrar de Windows Phone Silverlight a UWP

  • Artículo

Si eres un desarrollador con una aplicación de Windows Phone Silverlight, puedes hacer un uso inigualable de tus conocimientos y código fuente al pasar a Windows 10. Con Windows 10, puedes crear una aplicación para la Plataforma universal de Windows (UWP), que es un único paquete de la aplicación que los clientes pueden instalar en todos los tipos de dispositivos. Para más información sobre Windows 10, las aplicaciones para UWP y los conceptos de código adaptable e interfaz de usuario adaptable que se mencionan en esta guía de migración, consulta la Guía de aplicaciones de la Plataforma universal de Windows (UWP).

Al migrar la aplicación de Windows Phone Silverlight a una aplicación de Windows 10, podrás ponerte al día de las funciones móviles que se introdujeron en Windows Phone 8.1 e ir más allá y usar la Plataforma universal de Windows (UWP) cuyo modelo de aplicación y marco de trabajo de la interfaz de usuario son universales en todos los dispositivos Windows 10. Esto hace posible admitir PC, tabletas, teléfonos y un gran número de otros tipos de dispositivos, con un código base y un paquete de la aplicación. Y multiplicará el público potencial de la aplicación, además de crear nuevas posibilidades con datos compartidos, consumibles comprados, etcétera. Para obtener más información sobre las nuevas funciones, consulta Novedades para desarrolladores de Windows 10.

Si lo deseas, la versión de Windows Phone Silverlight de la aplicación y la versión de Windows 10 pueden estar disponibles para los clientes al mismo tiempo.

Nota Esta guía está diseñada para ayudarle a migrar manualmente la aplicación Windows Phone Silverlight a Windows 10. Además de usar la información de esta guía para migrar la aplicación, puedes probar la vista previa de desarrollador de Puente Mobilize.NET Silverlight para facilitar la automatización del proceso de migración. Esta herramienta analiza el código fuente de la aplicación y convierte las referencias en controles de Windows Phone Silverlight y las API en sus equivalentes de UWP. Dado que esta herramienta todavía está en la vista previa de desarrollador, aún no procesa todos los escenarios de conversión. Sin embargo, la mayoría de los desarrolladores deberían poder ahorrar tiempo y esfuerzo si empiezan con esta herramienta. Para probar la vista previa de desarrollador, visita el sitio web de Mobilize.NET.

¿XAML y .NET o HTML?

Windows Phone Silverlight tiene un marco de interfaz de usuario XAML basado en Silverlight 4.0 y programa con una versión de .NET Framework y un pequeño subconjunto de API de Windows Runtime. Puesto que usaste el lenguaje XAML en la aplicación de Windows Phone Silverlight, es probable que el XAML sea tu elección para tu versión de Windows 10 porque se transferirá la mayor parte de tus conocimientos y experiencia, así como gran parte del código fuente y patrones de software que usas. Incluso el marcado y el diseño de interfaz de usuario se pueden migrar inmediatamente. Encontrarás las API administradas, el marcado XAML, el marco de trabajo de la interfaz de usuario y las herramientas muy familiares; además puedes usar C++, C# o Visual Basic con XAML en una aplicación para UWP. 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.

Consulta Guía básica para aplicaciones para la Plataforma universal de Windows con C# o Visual Basic.

Nota Windows 10 admite mucho más de .NET Framework que una aplicación de Windows Phone Store. Por ejemplo, Windows 10 tiene varios espacios de nombres System.ServiceModel.* así como System.Net, System.Net.NetworkInformation y System.Net.Sockets. Por lo tanto, ahora es un buen momento para migrar tu Windows Phone Silverlight y compilar y usar el código .NET en la nueva plataforma. Consulta Asignaciones de espacios de nombres y clases. Otro buen motivo para volver a compilar el código fuente de .NET existente en una aplicación de Windows 10 es que te beneficiarás de .NET Native, que es una tecnología de compilación anticipada que convierte MSIL en código máquina que se puede ejecutar nativamente. Las aplicaciones de .NET Native se inician más rápido, usan menos memoria y usan menos batería que sus equivalentes MSIL.

Esta guía de portabilidad se centrará en XAML, pero, como alternativa, puedes crear una aplicación funcionalmente equivalente(llamar a muchas de las mismas API de Windows Runtime) mediante JavaScript, Hojas de estilos en cascada (CSS) y HTML5 junto con la Biblioteca de Windows para JavaScript. Aunque los marcos de trabajo de la interfaz de usuario de Windows en tiempo de ejecución de XAML y HTML son diferentes entre sí, el que elijas funcionará universalmente en toda la gama de dispositivos Windows.

Objetivo la familia de dispositivos universales o móviles

Una opción que tienes es migrar la aplicación a una aplicación que tiene como objetivo la familia de dispositivos universales. En este caso, la aplicación puede instalarse en la gama más amplia de dispositivos. Si la aplicación llama a las API implementadas solamente en la familia de dispositivos móviles, puedes proteger esas llamadas con código adaptable. Como alternativa, puedes migrar la aplicación a una aplicación que tenga como objetivo la familia de dispositivos móviles, en cuyo caso no es necesario escribir código adaptable.

Adaptar la aplicación a distintos factores de forma

La opción que elijas de la sección anterior determinará la gama de dispositivos en que se ejecutarán tus aplicaciones, la cual puede ser muy amplia. Incluso limitando la aplicación a la familia de dispositivos móviles, dispones de una amplia variedad de tamaños de pantalla compatibles. Por lo tanto, como la aplicación se ejecuta en factores de forma que antes no se admitían, prueba la interfaz de usuario en esos factores de forma y realiza los cambios necesarios para que la interfaz de usuario se adapte correctamente a cada uno. Piensa que se trata de una tarea posterior a la migración, o un objetivo de ampliación de la migración, y hay un ejemplo de ella en el caso de estudio Bookstore2.

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 (incluidas las API para el acceso a datos). La mayoría de ellas están disponibles para aplicaciones para UWP, por lo que posiblemente podrás 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 UWP te permite ejecutar probablemente necesitará los cambios de modelo de vista correspondientes. Para redes y llamadas a servicios en la nube, normalmente tiene la opción entre usar .NET o Windows Runtime API. Para conocer los factores que implica tomar esta decisión, consulta Servicios en la nube, redes y bases de datos.
  • 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 para UWP es Servicios móviles de Microsoft Azure, que proporciona componentes back-end eficaces a los 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 para UWP 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 todos los dispositivos, independientemente de la interfaz de usuario. Es probable que también puedas volver a usar la mayor parte del modelo de vista y los elementos de vista entre dispositivos.

Una o dos excepciones a la regla

Cuando leas esta guía de migración, puedes consultar Asignaciones de espacios de nombres y clases. Una asignación bastante sencilla es la regla general; la tabla de asignaciones de espacios de nombres y clases describe las excepciones.

En el nivel de función, la buena noticia es que hay muy poco que no sea compatible con UWP. La mayoría de tus conocimientos y código fuente se traslada muy bien a las aplicaciones para UWP, como verás en el resto de esta guía de migración. No obstante, estas son algunas características de Windows Phone Silverlight que puede que hayas usado y para las que no existe un equivalente de UWP.

Función para la que no hay equivalente en UWP Documentación de Windows Phone Silverlight para la característica
Microsoft XNA. En general, Microsoft DirectX con C++ sirve de sustitución. Consulta Desarrollo de juegos e Interoperabilidad de DirectX y XAML. Biblioteca de clases de XNA Framework
Aplicaciones de modos Modos para Windows Phone 8

 

Tema Descripción
Asignaciones de espacios de nombres y clases En este se tema se ofrece una asignación completa de las API de Windows Phone Silverlight a sus equivalentes de UWP.
Migración del proyecto El proceso de migración se empieza creando un nuevo proyecto de Windows 10 en Visual Studio y copiando los archivos en él.
Solución de problemas Se recomienda leer hasta el final esta guía de migración, aunque somos conscientes de que estás deseando 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 UWP. 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. No obstante, este código no se considera generalmente 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 para UWP, 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 común entre PC, dispositivos móviles y muchos otros tipos de dispositivos. 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.
Caso práctico: Bookstore1 En este tema se presenta un caso práctico de migración de una aplicación para Windows Phone Silverlight muy simple a una aplicación para la Plataforma universal de Windows a la aplicación para UWP de Windows 10. Con Windows 10, puedes crear un paquete de la aplicación único que los clientes pueden instalar en una amplia variedad de dispositivos, como se verá en este caso práctico.
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 que ha escrito 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.

Documentación

Artículos de MSDN Magazine

Presentaciones

  • La historia de traer la música de Nokia de Windows Phones a Windows 8.