Compartir a través de

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 de Plataforma universal de Windows (UWP), que es un único paquete de aplicación que los clientes pueden instalar en cada tipo de dispositivo. Para obtener más información sobre Windows 10, las aplicaciones para UWP y los conceptos de código adaptable y la interfaz de usuario adaptable que mencionaremos en esta guía de portabilidad, consulta la Guía para aplicaciones de Plataforma universal de Windows (UWP).

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

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

Nota Esta guía está diseñada para ayudarle a migrar manualmente la aplicación de Windows Phone Silverlight a Windows 10. Además de usar la información de esta guía para migrar la aplicación, puede probar la versión preliminar del desarrollador del puente silverlight de Mobilize.NET para ayudar a automatizar el proceso de portabilidad. Esta herramienta analiza el código fuente de la aplicación y convierte las referencias a Windows Phone controles y API de Silverlight a sus homólogos de UWP. Dado que esta herramienta todavía está en versión preliminar para desarrolladores, aún no controla todos los escenarios de conversión. Sin embargo, la mayoría de los desarrolladores deben poder ahorrar tiempo y esfuerzo empezando por esta herramienta. Para probar la versión preliminar del desarrollador, visite 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 has usado el lenguaje de marcado de aplicaciones extensibles (XAML) en tu aplicación de Windows Phone Silverlight, es probable que XAML sea tu elección para tu versión de Windows 10 porque la mayoría de tus conocimientos y experiencia se transferirán, como gran parte del código fuente y los patrones de software que usas. Incluso el marcado y el diseño de la interfaz de usuario pueden migrarse fácilmente. Encontrarás las API administradas, el marcado XAML, el marco de interfaz de usuario y las herramientas que te resultarán familiares y puedes usar C++, C#o Visual Basic junto con XAML en una aplicación para UWP. Es posible que se sorprenda de lo relativamente fácil que es el proceso, incluso si hay un desafío o dos a lo largo del camino.

Consulta Plan de desarrollo para aplicaciones de Plataforma universal de Windows (UWP) 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 su Windows Phone Silverlight y hacer que el código de .NET solo compile y trabaje en la nueva plataforma. Consulte Namespace y asignaciones de clases. Otra excelente razón para volver a compilar el código fuente de .NET existente en una aplicación de Windows 10 es que se beneficiará de .NET Native, que una tecnología de compilación anticipada que convierte MSIL en código de máquina ejecutable de forma nativa. 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 interfaz de usuario de Windows Runtime de XAML y HTML son diferentes entre sí, cualquiera que elija funcionará universalmente en toda la gama de dispositivos Windows.

Destino de la familia universal o de dispositivos móviles

Una opción que tiene es migrar la aplicación a una aplicación destinada a la familia de dispositivos universales. En este caso, la aplicación se puede instalar en la gama más amplia de dispositivos. Si la aplicación llama a las API que solo se implementan en la familia de dispositivos móviles, puede proteger esas llamadas con código adaptable. Como alternativa, puede optar por migrar la aplicación a una aplicación destinada a la familia de dispositivos móviles en cuyo caso no es necesario escribir código adaptable.

Adaptación de la aplicación a varios factores de forma

La opción que elija en la sección anterior determinará la gama de dispositivos en los que se ejecutará la aplicación o las aplicaciones, y que puede ser una gama muy amplia de dispositivos. Incluso la limitación de la aplicación a la familia de dispositivos móviles aún te deja con una amplia gama de tamaños de pantalla para admitir. Por lo tanto, dado que la aplicación se ejecutará en factores de forma que no admitía anteriormente, pruebe la interfaz de usuario en esos factores de forma y realice cualquier cambio necesario para que la interfaz de usuario se adapte adecuadamente en cada uno. Puede pensar que se trata de una tarea posterior a la migración, o un objetivo extendido de portabilidad, y hay un ejemplo de ello en la práctica en el caso práctico bookstore2 .

Aproximación a la migración de capas por capa

  • Vista. La vista (junto con el modelo de vista) compone la interfaz de usuario de la aplicación. Idealmente, la vista consta de marcado enlazado a propiedades observables de un modelo de vista. Otro patrón (común y conveniente, pero solo en el corto plazo) es para el código imperativo en un archivo de código subyacente para manipular directamente los elementos de la interfaz de usuario. En cualquier caso, gran parte del marcado y el diseño de la interfaz de usuario, e incluso el código imperativo que manipula los elementos de la interfaz de usuario, será sencillo de migrar.
  • Ver modelos y modelos de datos. Incluso si no adopta formalmente patrones de separación de preocupaciones (como MVVM), es inevitable que haya código presente en la aplicación que realiza la función del modelo de vista y del modelo de datos. El código de modelo de vista usa tipos en los espacios de nombres del marco de interfaz de usuario. Tanto el modelo de vista como el código del modelo de datos también usan el sistema operativo no visual y las API de .NET (incluidas las API para el acceso a datos). Y la gran mayoría de ellas están disponibles para una aplicación para UWP, por lo que puedes esperar poder migrar gran parte de este código sin cambios. No obstante, recuerde que 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 propia vista proporciona los objetos visuales. Por este motivo, cualquier interfaz de usuario que se adapte a los diferentes factores de forma en los que la UWP te permite ejecutar probablemente necesitará los cambios correspondientes del modelo de vista. En el caso de los servicios en la nube de redes y llamadas, normalmente tiene la opción entre usar las API de .NET o Windows Runtime. Para conocer los factores implicados en la toma de esa decisión, consulte Servicios en la nube, redes y bases de datos.
  • Servicios en la nube. Es probable que algunas de las aplicaciones (quizás una gran cantidad de ella) se ejecuten en la nube en forma de servicios. La parte de la aplicación que se ejecuta en el dispositivo cliente se conecta a ellas. Esta es la parte de una aplicación distribuida que es más probable que permanezca sin cambios al migrar la parte del cliente. Si aún no tienes una, una buena opción de servicios en la nube para tu aplicación para UWP es Microsoft Azure Mobile Services, que proporciona componentes de back-end eficaces que las aplicaciones universales de Windows pueden llamar a servicios que van desde notificaciones sencillas para actualizaciones de iconos dinámicos hasta el tipo de escalabilidad de trabajo intensivo que puede proporcionar una granja de servidores.

Antes o durante la migración, considere si la aplicación podría mejorarse refactorizando para que el código con un propósito similar se recopile en capas y no se disperse arbitrariamente. Factorizar la aplicación para UWP en capas como las descritas anteriormente facilita que la aplicación sea correcta, probarla y, a continuación, leerla y mantenerla. Puede hacer que la funcionalidad sea más reutilizable 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 los datos, la empresa y las partes de la interfaz de usuario de la aplicación separados entre sí. Incluso dentro de la interfaz de usuario, puede mantener el estado y el comportamiento separados y, por separado, de los objetos visuales. Con MVVM, puede escribir los datos y la lógica de negocios una vez y usarlo en todos los dispositivos independientemente de la interfaz de usuario. Es probable que también pueda volver a usar gran parte del modelo de vista y las partes de vista en todos los dispositivos.

Una o dos excepciones a la regla

A medida que lea esta guía de portabilidad, puede hacer referencia a Namespace y asignaciones de clases. La asignación bastante sencilla es la regla general y la tabla de asignaciones de espacios de nombres y clases describe todas las excepciones.

En el nivel de características, la buena noticia es que hay muy poco que no se admite en UWP. La mayoría de tu conjunto de aptitudes y el código fuente se traducen muy bien en aplicaciones para UWP, como leerás en el resto de esta guía de portabilidad. Pero estos son los pocos Windows Phone características de Silverlight que puedes haber usado para las que no hay ningún equivalente para UWP.

Característica para la que no hay ningún equivalente de UWP Windows Phone documentación de Silverlight para la característica
Microsoft XNA. En general, Microsoft DirectX con C++ es el reemplazo. Consulta Desarrollar juegos e interoperabilidad xaml y DirectX. Biblioteca de clases de marco XNA
Aplicaciones de Lens Lentes para Windows Phone 8

 

Tema Descripción
Asignaciones de espacios de nombres y clases En este tema se proporciona una asignación completa de Windows Phone API de Silverlight a sus equivalentes de UWP.
Portabilidad del proyecto Para comenzar el proceso de portabilidad, cree un nuevo proyecto de Windows 10 en Visual Studio y copie los archivos en él.
Solución de problemas Se recomienda leer al final de esta guía de portabilidad, pero también sabemos que está ansioso por avanzar y llegar a la fase en la que se compila y se ejecuta el proyecto. Para ello, puede realizar un progreso temporal mediante comentarios o código auxiliar de cualquier código no esencial y, a continuación, volver a pagar esa deuda más adelante. La tabla de solución de problemas de síntomas y remedios de este tema puede resultarle útil en esta fase, aunque no es un sustituto de leer los siguientes temas. Siempre puede hacer referencia a la tabla a medida que avanza a través de los temas posteriores.
Migración de XAML y la interfaz de usuario 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 UWP. Verá que las secciones grandes del marcado son compatibles una vez que ha actualizado las referencias de clave de recurso del sistema, ha cambiado algunos nombres de tipo de elemento y ha cambiado "clr-namespace" a "using".
Migración del modelo de E/S, dispositivo y aplicación El código que se integra con el propio dispositivo y sus sensores implica la entrada y la salida al usuario. También puede implicar el procesamiento de datos. Sin embargo, este código no suele considerarse 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 el altavoz (que se intersecan con el reconocimiento de voz y la síntesis), la ubicación (geo)y las modalidades de entrada, como la entrada táctil, el mouse, el teclado y el lápiz.
Migración de capas empresariales 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 al sistema operativo y a las API de .NET Framework (por ejemplo, procesamiento en segundo plano, ubicación, cámara, sistema de archivos, red y otro acceso a datos). La gran mayoría de ellas están disponibles para una aplicación para UWP, por lo que puedes esperar poder migrar gran parte de este código sin cambios.
Migración para factor de forma y experiencia de 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 de Windows Phone Silverlight muy sencilla a una aplicación para UWP de Windows 10. Con Windows 10, puedes crear un único paquete de aplicación que los clientes puedan instalar en una amplia gama de dispositivos y eso es lo que haremos en este caso práctico.
Caso práctico: Bookstore2 Este caso práctico, que se basa en la información que se proporciona 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 alejarnos para ver una lista de saltos de autores.

Documentación

Artículos de revistas

Presentaciones

  • La historia de traer música de Nokia de Windows Phone a Windows 8