Patrones y expresiones comunes en Xamarin.Mac
En las API de Apple que se exponen a través de C#, se repiten con frecuencia ciertos patrones y expresiones. Si tiene experiencia en programación con Xamarin.iOS, puede que le resulten familiares. En la documentación se hace referencia a estos patrones y expresiones de forma repetida y frecuente, por lo que conocerlos bien le ayudará a comprenderla.
MVC: Modelo-Vista-Controlador
Modelo Vista Controlador, o MVC para abreviar, es un patrón muy común que se encuentra en todo Cocoa. Una explicación detallada queda más allá del ámbito de este documento, pero en resumen se trata de una forma de estructurar su aplicación en componentes:
- Los objetos Modelo representan los datos subyacentes que se visualizan y manipulan (como las direcciones en una libreta de direcciones)
- Los objetos Vista se encargan de dibujar un objeto determinado en la pantalla y de controlar la interacción del usuario (un campo de texto que muestra la dirección en la pantalla)
- Los objetos Controlador controlan la interacción entre el modelo y la vista. Envían los cambios del modelo "hacia arriba" para actualizar la vista y "hacia abajo" desde la vista cuando los usuarios realizan cambios en la interfaz de usuario.
Si está familiarizado con MVVM (Modelo-Vista-Modelo de vista) de otras bibliotecas como WPF, el Controlador actúa de forma similar al Modelo-Vista, pero a menudo está más estrechamente vinculado a los elementos específicos de la interfaz de usuario.
Se pueden encontrar aquí más detalles:
Origen de datos/delegado/subclases
Otro patrón muy común en Cocoa se ocupa de proporcionar datos a los elementos de la interfaz de usuario y de reaccionar a las interacciones de los usuarios. Usando NSTableView
como ejemplo, necesitará proporcionar de algún modo los datos de cada fila, algún conjunto de elementos de interfaz de usuario que representen esa fila, algún conjunto de comportamientos para reaccionar a las interacciones del usuario y, posiblemente, algún grado de personalización. Los patrones de orígenes de datos y delegados le permiten controlar la mayoría de los casos sin tener que recurrir a crear usted mismo una subclase de NSTableView
.
A la propiedad
DataSource
se le asigna una instancia de una subclase personalizada deNSTableViewDataSource
a la que se llama para rellenar la tabla con datos (a través deGetRowCount
yGetObjectValue
).A la propiedad
Delegate
se le asigna una instancia de una subclase personalizada deNSTableViewDelegate
que proporciona la vista para un objeto modelo determinado (a través deGetViewForItem
) y controla las interacciones de la interfaz de usuario (a través deDidClickTableColumn
,MouseDownInHeaderOfTableColumn
, etc.).
En algunos casos, querrá personalizar un control de una forma que vaya más allá de los enlaces que se dan en el delegado o en el origen de datos y podrá hacer una subclase de la vista directamente. Sin embargo, tenga cuidado, en muchos casos invalidar el comportamiento predeterminado requerirá después que usted mismo controle todo ese comportamiento (personalizar el comportamiento de selección puede requerir que usted mismo implemente todos los comportamientos de selección).
En Xamarin.iOS, algunas API, como UITableView
, se han ampliado con una propiedad que implementa tanto el delegado como el origen de datos (UITableViewSource
). Esto es para sortear la limitación común de que una sola clase C# solo puede tener una clase base, y nuestra exposición de protocolos se hace a través de clases base.
Para más información sobre cómo trabajar con vistas de tabla en una aplicación de Xamarin.Mac, consulte nuestra documentación Vista de tabla.
Protocolos
Los protocolos en Objective-C pueden compararse con las interfaces en C#, y en muchos casos se usan en situaciones similares. En el ejemplo de NSTableView
anterior, tanto el delegado como el origen de datos son en realidad protocolos. Xamarin.Mac los expone como clases base con métodos virtuales que puede invalidar. La principal diferencia entre las interfaces de C# y los protocolos de Objective-C es que algunos métodos de un protocolo pueden ser opcionales de implementar. Tendrá que examinar la documentación o la definición de una API para determinar qué es opcional.
Para más información, consulte nuestra documentación sobre Delegados, protocolos y eventos.