Guía de portabilidad de aplicaciones de escritorio
La mayoría del código de aplicación se puede clasificar en una de las siguientes áreas:
- Código de interfaz de usuario (por ejemplo, ventanas y botones)
- Controles de terceros (por ejemplo, gráficos)
- Lógica de negocios (por ejemplo, reglas de validación)
- Almacenamiento y acceso a datos locales
- Servicios web y acceso a datos remotos
En el caso de las aplicaciones de Windows Forms y WPF escritas con C# (o Visual Basic.NET), una cantidad sorprendente de la lógica de negocios, el acceso a datos locales y el código de servicios web se puede compartir entre plataformas.
Analizador de portabilidad de .NET
Visual Studio 2017 y versiones posteriores admiten el Analizador de portabilidad de .NET (descarga para Windows) que puede examinar las aplicaciones existentes e indicar cuánto código se puede migrar "tal cual" a otras plataformas.
También hay una herramienta de línea de comandos que se puede descargar desde el Analizador de portabilidad en GitHub y se usa para proporcionar los mismos informes.
"x% de mi código es portable. ¿Qué debo hacer a continuación?"
Esperemos que el analizador muestre que una gran parte de su código es portable, pero sin duda habrá algunas partes de cada aplicación que nopuedan trasladarse a otras plataformas.
Es probable que diferentes fragmentos de código se conviertan en uno de estos cubos, que se explican con más detalle a continuación:
- Código portable reutilizable
- Código que requiere cambios
- Código que no es portable y requiere una reescritura
Código portable reutilizable
El código de .NET que se escribe en las API disponibles en todas las plataformas se puede realizar sin cambios entre plataformas. Lo ideal es que pueda mover todo este código a una biblioteca de clases portable, biblioteca compartida o biblioteca estándar de .NET y, a continuación, probarlo dentro de la aplicación existente.
Después, esa biblioteca compartida se puede agregar a proyectos de aplicación para otras plataformas (como Android, iOS, macOS).
Código que requiere cambios
Es posible que algunas API de .NET no estén disponibles en todas las plataformas. Si estas API existen en el código, deberá volver a escribir esas secciones para usar API multiplataforma.
Algunos ejemplos de esto incluyen el uso de las API de Reflexiones que están disponibles en .NET 4.6, pero no están disponibles en todas las plataformas.
Una vez que haya escrito el código mediante API portables, debería poder empaquetar ese código en una biblioteca compartida y probarlo dentro de la aplicación existente.
Código que no es portable y requiere una reescritura
Entre los ejemplos de código que no es probable que sean multiplataforma se incluyen:
Interfaz de usuario: las pantallas de Windows Forms o WPF no se pueden usar en proyectos en Android o iOS, por ejemplo. La interfaz de usuario deberá volver a escribirse con esta comparación de controles como referencia.
Almacenamiento específico de la plataforma: código que se basa en una tecnología específica de la plataforma (como una base de datos local de SQL Server Express). Tendrá que volver a escribir esto mediante una alternativa multiplataforma (como SQLite para el motor de base de datos). Es posible que algunas operaciones del sistema de archivos también necesiten ajustarse, ya que UWP tiene API ligeramente diferentes para Android e iOS (por ejemplo, algunos sistemas de archivos distinguen mayúsculas de minúsculas y otros no).
Componentes de terceros: compruebe si los componentes de terceros de las aplicaciones están disponibles en otras plataformas. Algunos, como paquetes NuGet que no son visuales, pueden estar disponibles, pero otros (especialmente controles visuales como gráficos o reproductores multimedia)
Recomendaciones para hacer que el código sea portable
Inserción de dependencias: proporcione implementaciones diferentes para cada plataforma y
Enfoque en capas: ya sea MVVM, MVC, MVP o algún otro patrón que le ayude a separar el código portable del código específico de la plataforma.
Mensajería: puede usar el mensaje pasando el código para desacoplar las interacciones entre diferentes partes de la aplicación.