Aunque estaba inicialmente programado para salir con .NET 5 en noviembre de 2020 y luego en noviembre de 2021 junto a .NET 6, lo cierto es que .NET MAUI, la siguiente evolución de Xamarin Forms, no apareció hasta mayo de 2022, si bien el tooling para trabajar con ella tardó un poco más en ponerse al día. Pero lo importante es que .NET MAUI ya está aquí.
A pesar de que hay diferencias importantes con Xamarin y rompe compatibilidad hacia atrás en muchas cosas, ¿te conviene actualizar tus aplicaciones y empezar a desarrollar con .NET MAUI en su lugar?
Pues, aparte del hecho de que Xamarin es el pasado y van a dejar de soportarlo en el futuro, te voy a dar algunos motivos interesantes más por los que deberías aprender y por los que deberías desarrollar con el nuevo framework. Hay muchas más razones para migrar, pero estas son, en mi humilde opinión, las principales.
Puedes ver una interesante conversación que mantuve con Javier Suárez, del equipo de desarrolladores de .NET MAUI en Microsoft, en la que hablamos largo y tendido sobre esta tecnología.
1.- Aplicaciones de escritorio
.NET MAUI es el acrónimo de .NET Multi-platform App User Interface, en español, Interfaz de Usuario para Aplicaciones Multiplataforma de .NET. Y, en rigor, Xamarin también era multiplataforma, pero era capaz de crear tan solo aplicaciones para móviles en iOS y Android. Aunque existieron algunos experimentos para crear aplicaciones de escritorio también, nunca pasaron de eso: experimentos sin ningún tipo de soporte y estabilidad a largo plazo.
Por eso, .NET MAUI va un paso más allá y con él puedes crear también aplicaciones de escritorio para Windows y macOS (con soporte de Microsoft) y para Linux (con soporte de la comunidad). En .NET MAUI el escritorio tiene la misma consideración que las aplicaciones móviles y puedes reutilizar tu código en todas las plataformas a la vez y con todo el soporte de Microsoft dentro de .NET:
Para lograrlo, en Windows .NET MAUI utiliza WinUI 3 por debajo (mira esta otra conversación con Miguel Ramos, uno de sus program managers, en nuestros canal de YouTube), el kit de desarrollo universal de interfaces de usuario para Windows. En el caso de macOS utiliza Mac Catalyst el SDK de Apple la solución de Apple para que las aplicaciones de iOS creadas con UIKit, funcionen también en macOS.
Por supuesto crear estas aplicaciones requieren un cierto esfuerzo adicional para hacer que la misma interfaz se adapte a anchos tan diferentes (algo parecido al diseño responsivo para la Web), pero en cualquier caso ya había que tenerlo en cuenta porque en los dispositivos móviles es similar: desde teléfonos muy pequeños a tabletas, los anchos son tremendamente variables.
El resumen es que escribes tu aplicación una vez y tienes versiones para iOS, Android, Windows y Mac. Cuatro aplicaciones por el precio de una (y alguna más si quieres porque podrías también generar aplicaciones para Smart TVs y relojes inteligentes que funcionen con el sistema operativo Tizen de Samsung, también soportado).
2.- Proyecto único
Una de las cosas más tediosas de Xamarin y que concentraba muchas de las quejas de los desarrolladores era la necesidad de tener un proyecto diferente para cada plataforma a la que te dirigías. No es que fuera nada muy grave, pero te obligaba a tener un proyecto común en .NET Standard y un proyecto específico para cada plataforma con sus recursos, sus códigos específicos de la plataforma, etc... Y en la mayor parte de los proyectos reales, a nada que creciesen, hacían que las soluciones creciesen mucho y tuvieses que acordarte de tocar en muchos sitios diferentes de cada vez.
En .NET MAUI han tratado de solucionar este problema utilizando un nuevo tipo de proyecto único, más simple y elegante, que contiene todo lo necesario para todas las plataformas que decidamos atacar y que es capaz de generar el ejecutable adecuado en cada caso sin tener que cambiar de proyecto.
Por ejemplo, todos los recursos comunes a la aplicación como las imágenes e iconos, las fuentes, la pantalla de presentación o los estilos, están todos juntos, y el compilador sabe cuál debe elegir para cada plataforma en caso de necesitar uno específico:
Pero esto no implica que le reste flexibilidad. Puedes crear código o recursos específicos para una plataforma determinada. Ahora lo único que hay que hacer es meterlos en una subcarpeta con el nombre del sistema operativo que nos interese y el compilador sabe dónde encontrarlos, sin necesidad de tener proyectos adicionales solo para eso:
3.- Mejor rendimiento y más flexibilidad
Algo en lo que ha hecho hincapié el equipo de .NET MAUI es en mejorar rendimiento, por lo que solo por el hecho de migrar una aplicación desde Xamarin ya obtienes una mejora considerable de velocidad, algo que a veces se le achacaba a la plataforma.
Pero además han realizado cambios importantes en la forma en la que están implementados todos los controles por debajo y la manera de renderizarlos en cada plataforma. En Xamarin se utilizaban los "renderers" que se deduce de su propio nombre, en cada plataforma, se encargaban de renderizar la interfaz a partir del XAML correspondiente (o del árbol visual escrito en C#), renderizando cada control nativo que correspondiera. El problema de esta manera de trabajar es que existe una vinculación muy fuerte entre los controles Xamarin y los nativos, lo que les resta flexibilidad y también hace más difícil su personalización.
Ahora, en .NET MAUI tenemos el concepto de "handlers" que disponen de una interfaz que permite abstraer cada control de su renderizado. A las implementaciones concretas de esas interfaces en cada plataforma se les denomina vistas virtuales. Los handlers "mapean" esas vistas virtuales con los correspondientes controles nativos de cada plataforma:
Esto hace que no estén atados a .NET MAUI necesariamente y que se abra la posibilidad de otras maneras de definir interfaces, como por ejemplo la interesantísima Comet que también sirve para Blazor (mira este vídeo de poco más de 1 minuto y comprenderás por qué digo que es interesante).
Para la personalización de controles se definen "mappers", que por defecto "mapean" controles de .NET MAUI con controles nativos, pero que se pueden modificar fácilmente tocando el "mapper", plataforma a plataforma o incluso de manera única para todas a la vez si los cambios son compatibles.
Finalmente, otra cuestión importante es que se ha adoptado un punto de entrada único para toda la aplicación que sigue el patrón del builder genérico de host que tiene toda la plataforma, y que ya conoces si has trabajado con MVC o con Blazor, por ejemplo. Esto hace que .NET MAUI sea consistente con el resto de .NET y que sea muy familiar y sencillo añadir cosas como inyección de dependencias, registrar los "handlers" que acabamos de comentar, utilizar el patrón MVVM y muchas otras extensiones que necesitemos.
4.- Hot Reload
Una de las cosas más fastidiosas de Xamarin era lo que se suele denominar el inner loop, es decir el bucle habitual de desarrollo-modificación-depuración y la facilidad para hacerlo. O, hablando más claro, la rapidez con la que podemos ver y probar los cambios que hacemos en una aplicación.
En el caso de Xamarin era un proceso lento ya que con cada cambio era necesario recompilar la aplicación y desplegarla en el dispositivo móvil. Aunque esto fue mejorando con el tiempo gracias a cosas como XAML Previewer para Xamarin Forms o, mejor aún, Hot Restart, que permitía compilar parcialmente la aplicación y desplegar los cambios en el emulador de dispositivo sin tener que redesplegar la aplicación. Pero Hot Restart no era más que un parche y además solo funcionaba en Windows.
En .NET MAUI tienes disponible la característica de Hot Reload que permite ver casi en tiempo real los cambios que realizamos en la interfaz y en el código de la aplicación. Esta característica está disponible en .NET y supone un cambio de era en la productividad a la hora de desarrollar.
5.- .NET MAUI Community Toolkit
Si programabas en Xamarin, entonces sin duda has utilizado Xamarin Essentials y el Xamarin Community Toolkit. El primero incluía APIs multiplataforma para desarrollo de aplicaciones móviles. Y el toolkit es un conjunto de controles, animaciones, convertidores, behaviours (un concepto específico de Xamarin) y efectos para desarrollo móvil que facilitan mucho la vida a la hora de programar. Cantidad de tareas que deberías hacer desde cero ya las tenías listas para usar en el Community Toolkit.
.NET MAUI ya incluye de serie lo que antes eran los Xamarin Essentials, solo que ahora funcionan también en las plataformas de escritorio soportadas. Cuando creas un proyecto .NET MAUI nuevo verás que el archivo .csproj del proyecto incluye una entrada ´true´, lo que hace que todas las utilidades de Essentials estén disponibles. Solo tienes que incluir el espacio de nombres correspondiente con using Microsoft.Maui.Essentials; y listo.
Por otra parte, el .NET MAUI Community Toolkit es un proyecto de la comunidad (aunque el mayor peso del desarrollo lo lleva gente de Microsoft, eso sí, en sus ratos libres) y porta todo lo que había en el anterior toolkit además de ser la versión que evolucionará en el futuro para dar más capacidades a tus apps (la de Xamarin deja de estar mantenida a partir de noviembre de 2022). Los elementos que contiene (controles, animaciones...) funcionan en todas las plataformas soportadas por .NET MAUI, y además lo han separado en dos partes:
CommunityToolkit.Maui: que contiene el grueso de la funcionalidad.CommunityToolkit.Maui.Markup: que incluye la interfaz fluida de C# para construir interfaces por código simplemente enlazando métodos uno tras otro. Mola, pero no tanto como Comet (que mencioné antes).
Gracias al toolkit y a la inclusión de los Essentials podrás ahorrar muchísimo tiempo a la hora de programar, mejorando tu productividad y la de tu equipo.
Fecha de publicación: