Generación de código .xib en Xamarin.iOS

La herramienta Interface Builder apple ("IB") se puede usar para diseñar interfaces de usuario visualmente. Las definiciones de interfaz creadas por IB se guardan en archivos .xib. A los widgets y otros objetos de los archivos .xib se les puede dar una "identidad de clase", que puede ser un tipo personalizado definido por el usuario. El uso de tipos personalizados permite personalizar el comportamiento de los widgets y escribir widgets personalizados.

Estas clases de usuario suelen ser subclases de clases de controlador de interfaz de usuario. Tienen salidas (propiedades) y acciones (eventos) que se pueden conectar a objetos de interfaz. En tiempo de ejecución, se carga el IB. En ese momento, se crean los objetos y las salidas y las acciones se conectan dinámicamente a los distintos objetos de interfaz de usuario. Al definir estas clases administradas, debe definir todas las acciones y salidas para que coincidan con las esperadas por IB. Visual Studio para Mac un modelo de tipo CodeBehind para simplificar el código. Xcode tiene un modelo Objective-C similar. Pero el modelo y las convenciones de generación de código de Xamarin.iOS se han ajustado para que sean más familiares para los desarrolladores de .NET.

Archivos .xib y clases personalizadas

Es posible definir tipos personalizados en archivos .xib, además de usar los tipos existentes de Cocoa Touch. También es posible usar tipos definidos en otros archivos .xib o definidos exclusivamente en código de C#. Actualmente, Interface Builder no conoce los detalles de los tipos definidos fuera del archivo .xib actual, por lo que no los enumera ni muestra sus salidas y acciones personalizadas. La eliminación de esta limitación está prevista para algún momento en el futuro.

Las clases personalizadas se pueden definir en un archivo .xib mediante el comando "Agregar subclase" en la pestaña "Clases" de Interface Builder. Nos referimos a esas clases como clases "CodeBehind". Si el archivo .xib tiene un archivo homólogo ".xib.designer.cs" en el proyecto, Visual Studio para Mac lo rellenará automáticamente con definiciones de clases parciales para todas las clases personalizadas en .xib. Estas clases parciales se hacen referencia a ellas como "clases de diseñador".

Generar código

La generación de código está habilitada por la presencia de un archivo .xib.designer.cs, para cualquier archivo .xib con una acción de compilación de Page. Visual Studio para Mac genera clases parciales en el archivo del diseñador para todas las clases de usuario que puede encontrar en el archivo .xib. Visual Studio para Mac genera propiedades para salidas y métodos parciales para las acciones.

El archivo del diseñador se actualiza automáticamente cuando cambia el archivo .xib y Visual Studio para Mac recupera el foco. No se recomienda realizar cambios en el archivo del diseñador, ya que los cambios se sobrescribirán la próxima Visual Studio para Mac actualizar el archivo.

Registro y espacios de nombres

Visual Studio para Mac genera las clases del diseñador mediante el espacio de nombres predeterminado del proyecto para la ubicación del archivo del diseñador. Este comportamiento es coherente con la generación normal de espacios de nombres de proyecto de .NET. El espacio de nombres de los archivos del diseñador usa el "espacio de nombres predeterminado" del proyecto y su configuración de "directivas de nomenclatura de .NET". Si cambia el espacio de nombres predeterminado del proyecto, las clases regeneradas usarán el nuevo espacio de nombres. Después de la regeneración, es posible que las clases parciales ya no coincidan.

Para que el tiempo de ejecución detecte la Objective-C clase, Visual Studio para Mac aplica un atributo a [Register (name)] la clase . Aunque Xamarin.iOS registra automáticamente las NSObject clases derivadas de , usa los nombres completos de .NET. El atributo aplicado por Visual Studio para Mac invalida el comportamiento de Xamarin.iOS para asegurarse de que cada clase se registra con el nombre usado en el archivo .xib. Agregue el atributo manualmente para todas las clases personalizadas definidas mediante IB, sin usar Visual Studio para Mac para generar archivos de diseñador. Esto hace que las clases administradas coincidan con los nombres Objective-C de clase esperados.

Las clases no se pueden definir en más de un archivo .xibo estarán en conflicto.

Elementos de clase que no son de diseñador

Las clases parciales del diseñador no están diseñadas para usarse tal y como están. Las salidas son privadas y no se especifica ninguna clase base. Se espera que cada clase tenga una parte de clase "no diseñador" correspondiente en otro archivo. El archivo "no diseñador" establece la clase base, manipula las salidas y define los constructores necesarios para crear instancias de la clase a partir de código nativo. Las plantillas .xib predeterminadas tienen las partes de clase "que no son de diseñador", pero para cualquier otra clase personalizada que defina en un archivo .xib,debe agregar manualmente la parte que no es de diseñador.

Esta separación mediante clases parciales es necesaria para la flexibilidad. Por ejemplo, varias clases CodeBehind podrían crear subclases de una clase abstracta administrada común, que subclasesa la clase que IB va a subclasificar.

Es convencional colocar clases CodeBehind en un archivo .xib.cs junto al archivo de diseñador .xib.designer.cs.

Acciones y salidas generadas

En las clases parciales del diseñador, Visual Studio para Mac propiedades correspondientes a las salidas conectadas definidas en IB y métodos parciales correspondientes a cualquier acción conectada.

Propiedades de salida

Las clases del diseñador contienen propiedades correspondientes a todas las salidas definidas en la clase personalizada. Estas propiedades habilitan el enlace diferido. Son un detalle de implementación del puente de Xamarin.iOS a Objective C. Piense en ellos como equivalentes a los campos privados, diseñados para usarse solo desde la clase CodeBehind. Haga que el campo sea público agregando el accessor público al campo en la parte de clase que no es de diseñador.

Si las propiedades de salida se definen para tener un tipo de (equivalente a ), el generador de código del diseñador determina actualmente el tipo más fuerte posible en función de los objetos conectados a esa salida, por idNSObject comodidad. Sin embargo, es posible que este comportamiento no se pueda usar en versiones futuras. Se recomienda escribir explícitamente las salidas al definir la clase personalizada.

Propiedades de acción

Las clases del diseñador contienen métodos parciales correspondientes a todas las acciones definidas en la clase personalizada. Estos métodos no tienen una implementación. El propósito de los métodos parciales es doble:

1. Si escribe el cuerpo de clase de la parte de clase que no es de diseñador, Visual Studio para Mac ofrecerá para autocompletar las firmas de todos los métodos parciales no partial implementados.
2. Las firmas de método parcial tienen un atributo aplicado que las expone al mundo, por lo que se pueden Objective-C controlar como la acción correspondiente.

Puede omitir el método parcial e implementar la acción aplicando el atributo a un método diferente. O deje que pase a una clase base.

Si las acciones se definen para tener un tipo de remitente de (equivalente a ), el generador de código del diseñador determina actualmente el tipo más fuerte posible en función de los objetos conectados a idNSObject esa acción. Sin embargo, es posible que este comportamiento no se pueda usar en versiones futuras. Se recomienda escribir explícitamente las acciones al definir la clase personalizada.

Estos métodos parciales solo se crean para C#, porque CodeDOM no admite métodos parciales. No se generan para otros idiomas.

Uso de clases cross-XIB

A veces, los usuarios desean hacer referencia a la misma clase desde varios archivos .xib, por ejemplo, con controladores de pestañas. Puede hacer referencia explícitamente a la definición de clase desde otro archivo .xib o volver a definir el mismo nombre de clase en el segundo archivo .xib.

El último caso puede ser problemático debido al procesamiento Visual Studio para Mac archivos .xib individualmente. Visual Studio para Mac no puede detectar ni combinar definiciones duplicadas. Puede acabar con conflictos al aplicar el atributo Register varias veces cuando se define la misma clase parcial en varios archivos de diseñador. Las versiones recientes Visual Studio para Mac intentar resolver los conflictos, pero es posible que no funcione siempre según lo previsto. En el futuro, es probable que este comportamiento no sea compatible y, en su lugar, Visual Studio para Mac hará que todos los tipos definidos en todos los archivos .xib y código administrado del proyecto sean visibles directamente desde todos los archivos .xib.

Resolución de tipos

Los tipos usados en IB son Objective-C nombres de tipo asignados a tipos CLR mediante atributos Register. Al generar código, Visual Studio para Mac resolverá los tipos CLR, con lo que se calificarán completamente los nombres de tipo para los Objective-C tipos. El Objective-C núcleo de Xamarin.iOS encapsula estos tipos.

El generador de código no puede resolver actualmente tipos CLR a partir de nombres Objective-C de tipo en código de usuario o bibliotecas. En tales casos, genera el nombre de tipo textual. Debe tener el mismo nombre que el Objective-C tipo para resolver correctamente el tipo CLR. El tipo CLR debe estar en el mismo espacio de nombres que el código que lo usa. Las versiones futuras del generador de código tendrán en cuenta Objective-C todos los tipos del proyecto.