Ho riflettuto su questa domanda per un po 'di tempo ...Progettare l'interfaccia iPhone in un pennino o in un codice?
Da un lato, Interface Builder offre un modo davvero semplice per progettare l'interfaccia e cablare gli elementi con gli oggetti nel codice.
D'altra parte, in progetti di grandi dimensioni, Interface Builder diventa una seccatura da mantenere.
Qualsiasi suggerimento sarebbe molto apprezzato.
Una volta ero molto fermamente contrario all'uso di Interface Builder nei miei progetti. Ciò era dovuto a una serie di fattori. Ho iniziato a lavorare per la prima volta con gli strumenti Xcode quando l'iPhone SDK era tornato in versione beta (verso marzo 2008), e dal momento che non provengo da uno sfondo Mac Cocoa, non ero abituato a usarlo. Questo non è stato il fattore principale nel mio rifiuto iniziale di IB per lo sviluppo di iPhone, tuttavia - lo sviluppo di Interface Builder per iPhone durante l'iniziale beta dell'SDK di iPhone ha effettivamente fatto schifo ed è stato doloroso da usare.
Tuttavia, la storia è molto diversa con l'iPhone SDK di oggi. Mentre ci sono ancora alcuni fastidiosi bug IB, ho fatto un quasi completo 180 ° con il mio atteggiamento verso l'uso di Interface Builder. Il più delle volte è una buona idea usare Interface Builder nei tuoi progetti, ho trovato. È un ottimo strumento ora, e dovresti approfittarne.
Ora, non fraintendetemi - Sono ancora fermamente nel campo che crede che si dovrebbe essere in grado di implementare nulla si fa in Interface Builder utilizzando il codice da solo e penso di essere in grado di farlo è inestimabile . Non utilizzare Interface Builder come stampella - alla fine ti farai solo del male (e della tua produttività o della qualità dei tuoi prodotti). Mentre le sottigliezze drag-and-drop di IB sono grandi per il 90% di quello che devi fare, quando hai qualcosa di personalizzato da implementare che può essere fatto solo in codice, o vorresti aver seguito o essere grato per seguire questo consiglio. Ho avuto la fortuna di odiare IB abbastanza a lungo da insegnarmi come fare tutto nel codice da solo, e poi applicare quella conoscenza a IB.
Edit:
per ovviare alla mancanza di riutilizzabilità (percepita o reale) con ONA contro il codice ... non sarà implementando qualcosa che è destinato a essere fortemente riutilizzato in Interface Builder con ogni probabilità. Non è possibile creare un controllo o una visualizzazione personalizzata in IB, quindi è escluso e, nella maggior parte dei casi, si implementerà una sottoclasse di controller di visualizzazione creata per rispondere a uno scopo specifico. Ovviamente dovresti sempre sforzarti di rendere il tuo codice e le risorse associate il più possibile riutilizzabili. Ciò potrebbe includere considerazioni di progettazione per garantire che non vengano duplicate inutilmente sottoclassi di controller di visualizzazione molto simili.
+1 Molto ben inserito.Comprendere IB e MVC ti consente di fare tutto ciò che è necessario in caso di necessità, ma fare le interfacce a mano sarà di solito un handicap piuttosto che un vantaggio. La mossa saggia è decidere in base all'esperienza degli sviluppatori, la quantità di funzionalità non standard che si intende implementare e il progetto stesso. Anche con tutti questi fattori, lo faccio sempre prima in IB, poi lo faccio solo a mano se non puoi farlo in IB. –
L'utilizzo di builder ti libera dal codice che altrimenti avresti bisogno di mantenere e meno hai bisogno di mantenere il meglio.
I layout creati da IB richiedono una certa manutenzione, ma è uno strumento standard con la propria documentazione e il proprio supporto online (forum, elenchi, ecc.). Se qualcun altro dovesse mai entrare nel tuo codice, puoi virtualmente garantire che hanno esperienza con IB, ma non necessariamente il tuo particolare stile di costruzione del layout.
Dipende dalle vostre preferenze.
Preferisco scriverlo in codice.
IB è grande per la capacità di prototipazione e di oggetti di navigazione e le apparenze (io non sono un graphic designer), anche se ho penso che sia più facile basta scrivere nel codice una volta che il prototipo esiste se avete intenzione di mantenendolo o riusandolo.
La mia raccomandazione: scrivere librerie di codice altamente riutilizzabili e stabili, e utilizzare IB principalmente per prototipazione e one-off.
Risposte:
Sbrocket: Sono curioso di sapere perché si affermi che i riferimenti circolari sono più probabilità di verificarsi a seguito di utilizzo di ONA.
Ciao Sbrocket: Inizierò dicendo che ho utilizzato Interface Builder dai giorni del Project Builder (il predecessore di Xcode).
Mancanza di proprietà strutturata affidabile, identità e inizializzazione. Io non voglio ivars essere connessioni IB perché rende molte classi difficili da usare oltre 'il contesto corrente', In altre parole, lega il codice alla risorsa (più spesso che idealmente). Poiché non è possibile definire l'ordine di inizializzazione o definire gli inizializzatori o gli argomenti di inizializzazione aggiuntivi in IB, è necessario quindi rendere gli oggetti a conoscenza reciproca, creando dipendenze e riferimenti circolari.
Sbrocket: o perché l'inizializzazione differita (ipotizzando che è in realtà quello che ti riferisci a) è così spaventoso quando la sua relativamente facile (o di fatto automatica in molti casi) per garantire che l'oggetto viene inizializzato e connesso.
Re: spaventoso Non stavo parlando di inizializzazione pigro. Stavo parlando di un ordine di inizializzazione differito e ambiguo.
L'inizializzazione del pennino è semi-ordinata. L'ordine/processo effettivo può variare, e questo non può essere usato in modo affidabile all'interno di programmi introspettivi riutilizzabili ... di nuovo, si finisce per scrivere troppi codici che sono fragili, impossibili da riutilizzare, non si può mai garantire un comportamento prevedibile e devono convalidare sempre lo stato (ancora un'altra voce per la dipendenza circolare). Se non si tratta di un'implementazione una tantum, perché preoccuparsi delle complicazioni?
Questo approccio alla programmazione è caotico e le implementazioni devono (a turno) essere preparate a gestire qualsiasi cosa in qualsiasi momento. Una cosa è proteggersi dagli incidenti, ma scrivere un codice di livello di produzione difensivo in questo contesto ... in nessun modo.
È molto più facile scrivere un programma coerente che l'inizializzazione determina la validità nel contesto, che le implementazioni possono quindi sapere (se inizializzato) che l'oggetto è generalmente pronto per essere utilizzato. La complessità del caso speciale è ridotta al minimo. Molti di questi progetti si disgregano a mano a mano che la complessità del programma aumenta, mentre gli scrittori di biblioteche aggiungono strati su strati di "misure protettive" solo per mantenere in movimento gli ingranaggi - il threading è un ottimo input per tali heisenbug. Le ambiguità non necessarie non sono gradite nel codice di livello di produzione riutilizzabile; gli esseri umani non dovrebbero avere riferimenti incrociati a tutti i casi speciali di un programma, e le complessità relative al comportamento definito e ai casi speciali si diffondono o vengono ignorati (presumendo che siano tracciati e documentati in modo corretto, che è uno sforzo combinato piuttosto che scriverlo correttamente dall'inizio). Penso che tutti possiamo essere d'accordo sul fatto che dovrebbero essere evitate interfacce e implementazioni onerose.
Sbrocket: Mi piacerebbe anche essere interessati a vedere alcuni numeri duri che mostrano che NIB caricamento è più lento - naturalmente, sembrerebbe dare un senso al primo pensiero, ma siamo sempre tali cattive predittori di performance colli di bottiglia senza qualche duro test.
Non ho mai detto (esplicitamente) che era più lento :)
Ok, serietà, NIB estrazione dall'archivio è stato (per me) un processo sorprendentemente lento, anche se le nostre idee su tempi lenti e disarchiviazione può variare notevolmente .
Esempio: avevo un'app basata su documenti e il caricamento del pennino era più lento del caricamento del documento, quando le dimensioni del documento erano diverse volte la dimensione del pennino. Spostare l'implementazione sul codice ha reso il processo molto più veloce. Una volta che si trovava sul codice e avevo il controllo dell'ordine di inizializzazione, ho rimosso più complessità del multithreading (checkpoint, blocchi, voci della race condition, ecc.), Il che ha reso il caricamento del documento ancora più veloce.
Ora che hai una risposta esplicita, ti ricorderò che hai tutti gli strumenti necessari per misurare le prestazioni.
Ricordare che l'analisi e i miglioramenti delle prestazioni sono appresi.
Sono curioso del motivo per cui affermi che i riferimenti circolari hanno maggiori probabilità di verificarsi a seguito dell'uso di NIB, o perché l'inizializzazione pigra (supponendo che sia in realtà ciò a cui ti stai riferendo) è così spaventosa quando è relativamente facile (o in molti casi automatico) per garantire che l'oggetto sia inizializzato e connesso. Sarei anche interessato a vedere alcuni numeri difficili che mostrano che il caricamento NIB è più lento - ovviamente, a prima vista sembrerebbe avere un senso, ma siamo sempre così pessimi predittori di colli di bottiglia nelle prestazioni senza qualche duro test. –
Questo non serve per confutare necessariamente i tuoi punti, cioè, sono solo interessato ad alcuni dettagli su alcuni dei tuoi punti dati. –
Il builder dell'interfaccia è ottimo per un certo livello di complessità. Per cose più o meno complesse, preferirei farlo in codice.
Se si dispone di un'interfaccia che non sarà utilizzata in più di un modo, ha molti ma non molti elementi e non ha bisogno di alcun layout complicato, che IB è ottimo.
A lungo termine, non utilizzo quasi mai IB. Questa è la natura dei progetti su cui lavoro come preferenza personale. Ci sono sicuramente alcune interfacce che vorrei andare direttamente a IB, ma non ho avuto bisogno di crearne una per un po '.
Hai una domanda valida. Gestire le interfacce in IB è un paradigma diverso che richiede nuove competenze e familiarità. Tuttavia, rendersi conto che costruire interfacce a mano senza IB è un'abilità ancora più rara, e trovare persone disposte o in grado di gestire tale codice è una responsabilità a sé stante. Vorrei ipotizzare che i grandi progetti siano in realtà più facili da mantenere in IB, ma è ancora un compromesso: le interazioni non sono sempre immediatamente visibili in IB, ma quando lo si fa in codice, aggiunge un sacco di codice di colla extra e rimuove l'abilità per il sistema operativo e il runtime per ottimizzare le cose per te. –