Lo que code behind significa en Xamarin Forms

Sobre el tema:

what code behind means xamarin forms - Luis Matos
Contenido

En una aplicación de Xamarin.Forms, se usa principalmente para definir el contenido visual de una página XAML para el código de marcado (markup)) y funciona junto con un archivo C# para el código detrás (code behind).

El archivo de código detrás proporciona compatibilidad de código para el marcado. Juntos, estos dos archivos contribuyen a una nueva definición de clase que incluye vistas secundarias e inicialización de la propiedad. En el archivo XAML, se hace referencia a clases y propiedades con los elementos y atributos XML y se establecen vínculos entre el código y marcado.

El archivo XAML (.xaml) y el archivo de código detrás correspondiente (.xaml.cs) son dos definiciones parciales de la misma clase.

El método InitializeComponent() que se llama en el constructor de la clase de código subyacente en tiempo de ejecución localiza un URI en el archivo XAML compilado y lo pasa a un método LoadComponent() que analiza el BAML, es decir, el XAML compilado, y crea instancias de los elementos que ha definido en su marcado XAML.

Entonces, en resumen, los archivos que terminan en .xaml.cs son los que contienen nuestro «código detrás» del archivo .xaml principal. Cualquier cosa dentro de este archivo está estrechamente relacionado al archivo .xaml.

Notarás, por ejemplo, que las clases del archivo son «parciales» porque habrá un código generado automáticamente cuando tu compiles tú aplicación que haga cosas específicas de la vista, como enlaces (bindings), referencias, etc. El archivo xaml.cs debe usarse con moderación y solo cuando necesita conocer u operar con detalles específicos de la Vista en sí.

MVVM (Model-View-ViewModel)

Ahora bien, usando el patrón MVVM (Model-View-ViewModel), codificarás casi toda la interacción de la interfaz de usuario (User Interface, UI) con sus modelos (Models) en los modelos de vista (ViewModels, archivos .cs), que son independientes de las vistas.

El único vínculo entre la vista y el modelo de vista es que el modelo de vista es el contexto de datos de la vista. En otras palabras, la Vista sabe sobre ViewModel, pero esa ViewModel no sabe nada sobre la Vista.

Con MVVM, a menudo verás código detrás de clases que están casi completamente vacías, con solo un constructor presente. La lógica en estos casos se traslada a una clase «ViewModel» que proporciona un enlace entre la Vista y el Modelo. Debe enlazar objetos en el Modelo de vista y usarlo como contexto de datos para su vista. Contiene toda la lógica para definir cómo la vista afecta su modelo.

Lo importante a tener en cuenta es que MVVM trata principalmente, dos cosas: la separación de preocupaciones (UI vs UI Logic) y la capacidad de prueba de su aplicación.

Manejadores de eventos (Event Handlers)

Un evento debe vivir en el código detrás, porque no puede vincularse explícitamente a uno en su ViewModel. Puede llamar fácilmente a la función que desee accediendo al ViewModel directamente dentro de ese controlador de eventos, y no hay nada particularmente atroz en este enfoque.

Los controladores de eventos (Event Handlers) generalmente no se usan en un mundo MVVM. Necesitas usar otro concepto llamado Comando que vivirá en el ViewModel en sí; un comando, a diferencia de un controlador de eventos, es una Propiedad, por lo que puede vincularlo en su archivo .xaml usando

Estos tienen buenas características como poder definir cuándo el comando es válido (por lo que puede deshabilitar su botón automáticamente cuando, por ejemplo, al formulario le falta un campo obligatorio).

Por otro lado, también se pueden usar Triggers, o Behaviors.

Cuando usar código detrás (Code behind)

Por lo general, es recomendable usar c# cuando se necesita crear controles dinámicos, pero teniendo el diseño general, guiones gráficos estáticos, estilos, plantillas de datos, etc. en el XAML.

Lo mejor de XAML es que permite separar el diseño de su lógica, lo que hace que el código sea mucho más fácil de leer para todos nosotros. Esto facilita y agiliza el soporte a largo plazo enormemente.

También pueden utilizar C# for Markup para hacer UI declarativas. Creo que es un proyecto que tiene mucho que ofrecer, y que debemos apoyarlo. Personalmente, creo que teniendo las opciones a la disposición podemos usar lo que mejor nos convenga en ciertas situaciones.

Un buen ejemplo de esto son las animaciones dentro de tus vistas. Las animaciones de por sí, son un poco complejas en cualquier plataforma, y tratar de agregar mas complejidad puede ser un dolor de cabeza.

Lo que yo trato de hacer siempre, si son controles específicos, es crear estos controles en archivos aparte para luego reutilizarlos en otras Vistas. Si las animaciones son para la pagina puedes crear una pagina base con la animación deseada o si es una página con funcionalidades muy específicas de esa página entonces si utilizo el código detrás en esa página.

En resumen, debemos utilizar código detrás cuando se necesita interacción entre los controles de una vista. Acordándoles que nuestras vistas (y nuestro código detrás también) conocen nuestra ViewModel pero nuestra ViewModel no debería conocer nuestra vista con el objetivo de separar conceptos.

Muchas gracias por leer esta publicación!

¿Qué opinas de este contenido?
 
Luis Matos

Luis Matos

I help professionals and companies to create value solutions. I am a Systems Engineer, blockchain executive, and international mobile application speaker. Founder of the Malla Consulting Agency and several international technology communities.
Suscribirte
Notificar de
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x

Buscar en el sitio