Perché mi sento come Interface Builder mi si mette di mezzo?

Question

Sono molto nuovo in Cocoa per MacOSX, ma non posso fare a meno di pensare di combattere costantemente Interface Builder.

La mia situazione attuale è che sto costruendo un'app che avrà diversi controlli e viste personalizzati. Ho iniziato a creare l'app in Interface Builder perché inizialmente era molto facile trascinare le cose e portarle nei punti corretti con i colori giusti e le regole di ridimensionamento automatico corrette. Tuttavia è giunto il momento di iniziare a creare i miei controlli e le mie visualizzazioni personalizzate, che non riesco a rappresentare in modo corretto in Interface Builder senza passare attraverso il lavoro di costruzione di un IBPlugin! L'unica altra opzione che conosco è quella di avere un documento Interface Builder che includa un gruppo di "Visualizzazioni personalizzate" ovunque con solo la loro classe cambiata. Improvvisamente sembra inutile preoccuparsi persino di IB - specialmente alla luce del fatto che questi controlli e viste avranno proprietà come il colore che devono essere impostati - proprio come le altre viste e controlli già presenti nel documento IB. Quindi ora ho le proprietà di visualizzazione impostate in due punti disconnessi e sembra contrastare uno dei potenziali vantaggi di IB che sta rendendo relativamente facile modificare l'interfaccia utente dell'app senza scavare nel codice.

Sono anche di fronte a una situazione in cui alcuni controlli cambiano le proprietà (come i colori) in base ai dati o alle selezioni correnti. Quindi ora ho i colori predefiniti iniziali del controllo specificato in Interface Builder, ma devo specificare i colori basati sui dati nel codice? Ancora una volta Interface Builder mi sembra dover dividere alcune impostazioni di presentazione tra il suo mondo e il codice. Suppongo che sia possibile risolverlo in qualche modo con un plug-in complesso che conosce i miei dati, i miei stati o altro, ma sembra che finirei per mantenere una tonnellata di codice di supporto che esiste proprio così l'esperienza di Interface Builder rimane "corretta. "

Un'altra cosa che vedo spesso menzionata è la facilità con cui IB consente di definire i collegamenti tra i componenti. " Puoi farlo senza scrivere alcun codice! " Ancora una volta, potrei mancare qualcosa, ma legare una proprietà a un'altra è una singola riga di codice, per quanto posso dire. Impostare le proprietà di una coppia in una casella in IB è davvero meglio che scrivere quella singola riga di codice? E perché è meglio inserire ciò che equivale alla logica dell'applicazione nelle specifiche del livello di presentazione?

Come ho detto all'aperto, sono abbastanza nuovo con questa roba di Cocoa, ma mi sento come se mi stessi perdendo qualcosa di molto importante su come usare Interface Builder, o sia progettato principalmente per banali applicazioni demo con un alto " wow " fattore.

Answer 1

Trovo che Interface Builder sia eccellente per ottenere il layout generico di un'app. È anche meraviglioso per cose come i binding (su Mac). Tuttavia, non è possibile creare Delicious Library utilizzando Interface Builder. Più complessa è la tua interfaccia, più codice dovrai scrivere.

Answer 2

Interface Builder può richiedere un po 'di tempo per abituarsi. Ma, come è stato precedentemente affermato, più lo usi, meglio è. Certo, le visualizzazioni personalizzate possono essere eseguite nel codice, ma IB è uno standard per un motivo. Le app per Mac sono tenute a determinati standard di qualità dell'interfaccia utente dalla community, che sono molto più alti degli standard dell'interfaccia utente per altre piattaforme. IB rende molto più facile conformarsi a tali standard piuttosto che fare tutto nel codice, senza riferimenti visivi.

E non devi fare tutto nel codice per avere la tua UI nel controllo della versione. Tutti i miei progetti Cocoa vivono nel loro repository git con file nib / xib inclusi.

Quindi dai una possibilità a IB. Diventa più facile solo più lo usi.

Answer 3

Jeff LaMarche (famoso per lo sviluppo di iPhone) ha scritto un eccellente articolo sul motivo per cui IB è una buona scelta da utilizzare, anche se non "sembra" la strada giusta una volta superati i tutorial di base. Avevo rinunciato a IB per motivi simili a te, ma l'articolo mi ha ispirato a continuare a lavorarci, e alla fine è davvero la soluzione giusta, anche se va contro la tendenza geek a non consentire astrazioni troppo impercettibili.

Answer 4

Il mio primo programma per iPhone, disponibile per la vendita, così come il mio secondo in fase di sviluppo non usano Interface Builder. Mi piace avere tutto nel codice in modo da poter capire cosa sta succedendo e in modo da poter utilizzare il rilevamento delle versioni per tenere traccia di tutte le modifiche.

Per quanto ne so, si tratta di una questione di preferenza. Ci sono libri di cacao là fuori che usano entrambi gli stili (IB e no IB).