Generazione di codice xib in Xamarin.iOS

Lo strumento Apple Interface Builder ("IB") può essere usato per progettare visivamente le interfacce utente. Le definizioni di interfaccia create da IB vengono salvate nei file xib . Ai widget e ad altri oggetti nei file con estensione xib può essere assegnata un'identità di classe, che può essere un tipo personalizzato definito dall'utente. L'uso di tipi personalizzati consente di personalizzare il comportamento dei widget e di scrivere widget personalizzati.

Queste classi utente sono in genere sottoclassi delle classi controller dell'interfaccia utente. Hanno outlet (proprietà) e azioni (eventi) che possono essere connessi a oggetti di interfaccia. In fase di esecuzione, l'IB viene caricato. In quel momento, vengono creati gli oggetti e le azioni e i punti di accesso e le azioni sono connessi dinamicamente ai vari oggetti dell'interfaccia utente. Quando si definiscono queste classi gestite, è necessario definire tutte le azioni e gli outlet in modo che corrispondano a quelli previsti da IB. Visual Studio per Mac usa un modello simile a CodeBehind per semplificare il codice. Xcode ha un modello simile Objective-C . Tuttavia, il modello e le convenzioni di generazione del codice Xamarin.iOS sono state modificate per acquisire familiarità con gli sviluppatori .NET.

File xib e classi personalizzate

È possibile definire tipi personalizzati nei file con estensione xib , oltre a usare i tipi esistenti di Cocoa Touch. È anche possibile usare tipi definiti in altri file con estensione xib o definiti esclusivamente nel codice C#. Attualmente Interface Builder non riconosce i dettagli dei tipi definiti all'esterno del file con estensione xib corrente, quindi non li elenca né visualizza i relativi punti di vendita e azioni personalizzati. La rimozione di questa limitazione è prevista in futuro.

Le classi personalizzate possono essere definite in un file con estensione xib usando il comando "Aggiungi sottoclasse" nella scheda "Classi" di Interface Builder. Si fa riferimento a tali classi come classi "CodeBehind". Se il file xib ha un file controparte ".xib.designer.cs" nel progetto, Visual Studio per Mac lo riempirà automaticamente con definizioni di classi parziali per tutte le classi personalizzate in .xib. Si fa riferimento a queste classi parziali come "classi di progettazione".

Generazione di codice

La generazione del codice è abilitata dalla presenza di un {0}file .xib.designer.cs, per qualsiasi{0} file con estensione xib con un'azione di compilazione di Page. Visual Studio per Mac genera classi parziali nel file di progettazione per tutte le classi utente che può trovare nel file xib. Visual Studio per Mac genera proprietà per gli outlet e i metodi parziali per le azioni.

Il file di progettazione viene aggiornato automaticamente quando il file xib cambia e Visual Studio per Mac riprende lo stato attivo. Non è consigliabile apportare modifiche al file di progettazione perché le modifiche verranno sovrascritte la volta successiva Visual Studio per Mac aggiorna il file.

Registrazione e spazi dei nomi

Visual Studio per Mac genera le classi di progettazione usando lo spazio dei nomi predefinito del progetto per il percorso del file di progettazione. Questo comportamento è coerente con la normale generazione dello spazio dei nomi del progetto .NET. Lo spazio dei nomi dei file di progettazione usa lo "spazio dei nomi predefinito" del progetto e le impostazioni dei criteri di denominazione ".NET". Se lo spazio dei nomi predefinito del progetto cambia, le classi rigenerate useranno il nuovo spazio dei nomi. Dopo la rigenerazione, è possibile che le classi parziali non corrispondano più.

Per rendere individuabile la classe dal Objective-C runtime, Visual Studio per Mac applica un [Register (name)] attributo alla classe . Anche se Xamarin.iOS registra automaticamente classi NSObjectderivate da , usa i nomi .NET completi. L'attributo applicato da Visual Studio per Mac esegue l'override del comportamento di Xamarin.iOS per assicurarsi che ogni classe sia registrata con il nome usato nel file xib. Aggiungere manualmente l'attributo per tutte le classi personalizzate definite tramite IB, senza usare Visual Studio per Mac per generare file di progettazione. In questo modo le classi gestite corrispondono ai nomi di classe previsti Objective-C .

Le classi non possono essere definite in più di un file con estensione xib o saranno in conflitto.

Parti di classe non di progettazione

Le classi parziali della finestra di progettazione non devono essere usate così come sono. Gli outlet sono privati e non viene specificata alcuna classe di base. È previsto che ogni classe abbia una classe "non designer" corrispondente in un altro file. Il file "non designer" imposta la classe base, modifica gli outlet e definisce i costruttori necessari per creare un'istanza della classe dal codice nativo. I modelli con estensione xib predefiniti hanno le parti della classe "non designer", ma per qualsiasi altra classe personalizzata definita in un file xib, è necessario aggiungere manualmente la parte non della finestra di progettazione.

Questa separazione tramite classi parziali è necessaria per la flessibilità. Ad esempio, più classi CodeBehind possono sottoclassare una classe astratta gestita comune, che sottoclassa la classe da sottoclassare da IB.

È convenzionale inserire le classi CodeBehind in un {0}file .xib.cs accanto al file di {0}progettazione .xib.designer.cs .

Azioni e punti vendita generati

Nelle classi di progettazione parziali, Visual Studio per Mac genera proprietà corrispondenti a qualsiasi outlet connesso definito in IB e metodi parziali corrispondenti a qualsiasi azione connessa.

Proprietà outlet

Le classi della finestra di progettazione contengono proprietà corrispondenti a tutti gli outlet definiti nella classe personalizzata. Queste proprietà abilitano l'associazione differita. Si tratta di un dettaglio di implementazione del bridge Xamarin.iOS per Objective C. Si considerino equivalenti ai campi privati, destinati a essere usati solo dalla classe CodeBehind. Rendere pubblico il campo aggiungendo la funzione di accesso pubblica al campo nella parte della classe non di progettazione.

Se le proprietà di uscita sono definite per avere un tipo di (equivalente a NSObject), il generatore di id codice della finestra di progettazione determina attualmente il tipo più sicuro possibile in base agli oggetti connessi a tale presa, per praticità. Tuttavia, questo comportamento potrebbe non essere supportato nelle versioni future. È consigliabile digitare in modo esplicito i punti vendita quando si definisce la classe personalizzata.

Proprietà azione

Le classi della finestra di progettazione contengono metodi parziali corrispondenti a tutte le azioni definite nella classe personalizzata. Questi metodi non hanno un'implementazione. Lo scopo dei metodi parziali è duplicato:

1. Se si digita partial il corpo della classe non di progettazione, Visual Studio per Mac offrirà il completamento automatico delle firme di tutti i metodi parziali non implementati.
2. Le firme del metodo parziale hanno un attributo applicato che li espone al Objective-C mondo, in modo che possano essere gestiti come azione corrispondente.

È possibile ignorare il metodo parziale e implementare l'azione applicando l'attributo a un metodo diverso. In alternativa, passare a una classe di base.

Se vengono definite azioni per avere un tipo di mittente (equivalente a NSObject), il generatore di id codice della finestra di progettazione determina attualmente il tipo più sicuro possibile in base agli oggetti connessi a tale azione. Tuttavia, questo comportamento potrebbe non essere supportato nelle versioni future. È consigliabile digitare in modo esplicito le azioni quando si definisce la classe personalizzata.

Questi metodi parziali vengono creati solo per C#, perché CodeDOM non supporta metodi parziali. Non vengono generati per altre lingue.

Utilizzo di classi cross-XIB

In alcuni casi, gli utenti desiderano fare riferimento alla stessa classe da più file con estensione xib , ad esempio con i controller di tabulazione. È possibile fare riferimento in modo esplicito alla definizione della classe da un altro file con estensione xib oppure definire di nuovo lo stesso nome della classe nel secondo file xib.

Il secondo caso può essere problematico a causa di Visual Studio per Mac l'elaborazione dei file con estensione xib singolarmente. Visual Studio per Mac non è possibile rilevare e unire definizioni duplicate. È possibile che si verifichino conflitti che applicano l'attributo Register più volte quando la stessa classe parziale è definita in più file di progettazione. Le versioni recenti di Visual Studio per Mac tentano di risolvere i conflitti, ma potrebbero non funzionare sempre come previsto. In futuro, questo comportamento sarà probabilmente non supportato e invece Visual Studio per Mac renderà tutti i tipi definiti in tutti i file xib e il codice gestito nel progetto direttamente visibili da tutti i file xib.

Risoluzione dei tipi

I tipi usati in IB sono Objective-C nomi di tipi mappati ai tipi CLR usando gli attributi Register. Durante la generazione di codice, Visual Studio per Mac risolverà i tipi CLR, qualificando completamente i nomi dei tipi ai Objective-C tipi. Questi Objective-C tipi vengono inclusi nel wrapping dal core Xamarin.iOS.

Il generatore di codice non è attualmente in grado di risolvere i tipi CLR dai Objective-C nomi dei tipi nel codice utente o nelle librerie. In questi casi, restituisce il nome del tipo verbatim. Deve avere lo stesso nome del Objective-C tipo per risolvere correttamente il tipo CLR. Il tipo CLR deve trovarsi nello stesso spazio dei nomi del codice che lo usa. Le versioni future del generatore di codice considereranno tutti i Objective-C tipi nel progetto.