Geração de código .xib no Xamarin.iOS

A ferramenta Apple Interface Builder ("IB") pode ser usada para projetar interfaces do usuário visualmente. As definições de interface criadas pelo IB são salvas em arquivos .xib . Widgets e outros objetos em arquivos .xib podem receber uma "identidade de classe", que pode ser um tipo personalizado definido pelo usuário. O uso de tipos personalizados permite que você personalize o comportamento dos widgets e escreva widgets personalizados.

Normalmente, essas classes de usuário são subclasses de classes de controlador de interface do usuário. Eles têm saídas (propriedades) e ações (eventos) que podem ser conectadas a objetos de interface. Em runtime, o IB é carregado. Nesse momento, os objetos são criados e as saídas e ações são conectadas aos vários objetos de interface do usuário dinamicamente. Ao definir essas classes gerenciadas, você deve definir todas as ações e saídas para corresponder às esperadas pelo IB. Visual Studio para Mac usa um modelo semelhante a CodeBehind para simplificar o código. O Xcode tem um modelo semelhante Objective-C . Mas o modelo e as convenções de geração de código do Xamarin.iOS foram ajustados para serem mais familiares para os desenvolvedores do .NET.

Arquivos .xib e classes personalizadas

É possível definir tipos personalizados em arquivos .xib , além de usar os tipos existentes do Cocoa Touch. Também é possível usar tipos definidos em outros arquivos .xib ou definidos puramente no código C#. Atualmente, o Interface Builder não está ciente dos detalhes dos tipos definidos fora do arquivo .xib atual, portanto, ele não os listará nem mostrará suas saídas e ações personalizadas. A remoção dessa limitação está planejada para algum momento no futuro.

Classes personalizadas podem ser definidas em um arquivo .xib usando o comando "Adicionar Subclasse" na guia "Classes" do Construtor de Interfaces. Nos referimos a essas classes como classes "CodeBehind". Se o arquivo .xib tiver um arquivo equivalente ".xib.designer.cs" no projeto, Visual Studio para Mac o preencherá automaticamente com definições de classes parciais para todas as classes personalizadas no .xib. Nos referimos a essas classes parciais como "classes de designer".

Gerando código

A geração de código é habilitada pela presença de um {0}arquivo .xib.designer.cs para qualquer {0}arquivo .xib com uma ação de build de Page. Visual Studio para Mac gera classes parciais no arquivo de designer para todas as classes de usuário que ele pode encontrar no arquivo .xib. Visual Studio para Mac gera propriedades para saídas e métodos parciais para ações.

O arquivo de designer é atualizado automaticamente quando o arquivo .xib é alterado e Visual Studio para Mac recupera o foco. Não é recomendável fazer alterações no arquivo de designer, pois as alterações serão substituídas na próxima vez Visual Studio para Mac atualizar o arquivo.

Registro e namespaces

Visual Studio para Mac gera as classes de designer usando o namespace padrão do projeto para o local do arquivo de designer. Esse comportamento é consistente com a geração normal de namespace do projeto .NET. O namespace de arquivos de designer usa o "namespace padrão" do projeto e suas configurações de "políticas de nomenclatura do .NET". Se o namespace padrão do projeto for alterado, as classes regeneradas usarão o novo namespace. Após a regeneração, você pode achar que suas classes parciais não correspondem mais.

Para tornar a classe detectável pelo Objective-C runtime, Visual Studio para Mac aplica um [Register (name)] atributo à classe . Embora o Xamarin.iOS registre NSObjectautomaticamente classes derivadas de , ele usa os nomes .NET totalmente qualificados. O atributo aplicado por Visual Studio para Mac substitui o comportamento do Xamarin.iOS para garantir que cada classe seja registrada com o nome usado no arquivo .xib. Adicione o atributo manualmente para todas as classes personalizadas definidas usando IB, sem usar Visual Studio para Mac para gerar arquivos de designer. Isso faz com que suas classes gerenciadas correspondam aos nomes de classe esperados Objective-C .

As classes não podem ser definidas em mais de um .xib ou entrarão em conflito.

Partes de classe não Designer

Designer classes parciais não devem ser usadas como estão. As saídas são privadas e nenhuma classe base é especificada. Espera-se que cada classe tenha uma parte de classe "não designer" correspondente em outro arquivo. O arquivo "não designer" define a classe base, manipula as saídas e define construtores necessários para instanciar a classe do código nativo. Os modelos .xib padrão têm as partes de classe "não designer", mas para qualquer outra classe personalizada que você definir em um .xib, você deve adicionar a parte não designer manualmente.

Essa separação usando classes parciais é necessária para flexibilidade. Por exemplo, várias classes CodeBehind podem subclasse de uma classe abstrata gerenciada comum, que subclasse a classe a ser subclasse pelo IB.

É convencional colocar classes CodeBehind em um {0}arquivo .xib.cs ao lado do {0}arquivo de designer .xib.designer.cs .

Ações e saídas geradas

Nas classes parciais do designer, Visual Studio para Mac gera propriedades correspondentes a quaisquer saídas conectadas definidas no IB e métodos parciais correspondentes a qualquer ação conectada.

Propriedades de saída

Designer classes contêm propriedades correspondentes a todas as saídas definidas na classe personalizada. Essas propriedades habilitam a associação lenta. Eles são um detalhe de implementação da ponte Xamarin.iOS para Objective C. Pense neles como equivalentes aos campos privados, destinados a serem usados somente da classe CodeBehind. Torne o campo público adicionando o acessador público ao campo na parte de classe não designer.

Se as propriedades de tomada forem definidas para ter um tipo de id (equivalente a NSObject), o gerador de código do designer determinará atualmente o tipo mais forte possível com base em objetos conectados a essa tomada, por conveniência. No entanto, esse comportamento pode não ter suporte em versões futuras. É recomendável que você digite explicitamente as saídas ao definir a classe personalizada.

Propriedades da ação

Designer classes contêm métodos parciais correspondentes a todas as ações definidas na classe personalizada. Esses métodos não têm uma implementação. A finalidade dos métodos parciais é dupla:

1. Se você digitar partial o corpo da classe da parte de classe não designer, Visual Studio para Mac oferecerá o preenchimento automático das assinaturas de todos os métodos parciais não implementados.
2. As assinaturas de método parcial têm um atributo aplicado que as Objective-C expõe ao mundo, para que possam ser tratadas como a ação correspondente.

Você pode ignorar o método parcial e implementar a ação aplicando o atributo a um método diferente. Ou deixe-o passar para uma classe base.

Se as ações forem definidas para ter um tipo de remetente ( id equivalente a NSObject), o gerador de código do designer determinará atualmente o tipo mais forte possível com base em objetos conectados a essa ação. No entanto, esse comportamento pode não ter suporte em versões futuras. É recomendável que você digite explicitamente fortemente as ações ao definir a classe personalizada.

Esses métodos parciais são criados apenas para C#, porque o CodeDOM não dá suporte a métodos parciais. Eles não são gerados para outros idiomas.

Uso de classe entre XIB

Às vezes, os usuários desejam referenciar a mesma classe de vários arquivos .xib , por exemplo, com controladores de guia. Você pode referenciar explicitamente a definição de classe de outro arquivo .xib ou definir o mesmo nome de classe novamente no segundo .xib.

Este último caso pode ser problemático devido ao processamento de arquivos .xib Visual Studio para Mac individualmente. Visual Studio para Mac não consegue detectar e mesclar definições duplicadas. Você pode acabar com conflitos aplicando o atributo Register várias vezes quando a mesma classe parcial é definida em vários arquivos de designer. Versões recentes do Visual Studio para Mac tentam resolve conflitos, mas pode nem sempre funcionar conforme o esperado. No futuro, esse comportamento provavelmente não terá suporte e, em vez disso, Visual Studio para Mac tornará todos os tipos definidos em todos os arquivos .xib e código gerenciado no projeto diretamente visíveis de todos os arquivos .xib.

Resolução de tipos

Os tipos usados no IB são Objective-C nomes de tipo mapeados para tipos CLR usando atributos Register. Ao gerar código, Visual Studio para Mac resolve tipos CLR, qualificando totalmente os nomes de tipo para os Objective-C tipos. Esses Objective-C tipos são encapsulados pelo núcleo do Xamarin.iOS.

No momento, o gerador de código não pode resolve tipos CLR de nomes de Objective-C tipo em código de usuário ou bibliotecas. Nesses casos, ele gera o nome do tipo textualmente. Ele deve ter o mesmo nome que o Objective-C tipo para resolve corretamente o tipo CLR. O tipo CLR deve estar no mesmo namespace que o código que o está usando. Versões futuras do gerador de código considerarão todos os Objective-C tipos no projeto.