Interface Builder (XIB) o codice durante l'unione in un ambiente di team?

Question

L'unione di file di builder dell'interfaccia con altri (e persino me stesso da un altro computer) può essere una vera sfida. XIB xml è certamente migliore dei NIB ma anche come xml, ho trovato casi in cui l'unione e l'ottenimento di un XIB coerente e valido era più difficile che prendere l'altro e ripristinare manualmente le modifiche apportate.

Mi chiedo cosa fanno le altre persone che hanno più persone potenzialmente in collisione con XIBs.

Era la fusione di una considerazione per andare tutto il codice? Usi XIB solo per il layout e codifica il resto? Oppure, hai avuto fortuna nel fondere gli XIB e nel tempo riesci a migliorare la lettura manuale?

MODIFICA: Il mio attuale approccio lo utilizza per un layout rigoroso (cosa è veramente buono e doloroso codificare) e imposta tutte le opzioni e i dati tramite codice. Trovo che il codice sia molto più facile da unire, ma il layout dei controlli nel codice è noioso. Pensieri?

Answer 1

Era la fusione di una considerazione per andare tutto il codice?

Sì, No e "Porzioni di". Dipende da cose come:

• le persone coinvolte
• la complessità dell'interfaccia utente
• la qualità della realizzazione si ha bisogno.
• la durata prevista della realizzazione

Ma sì, è stato, e spesso è quando il caso non è solo banale - In caso contrario, è sufficiente combattere lo decomponendo XIBs in pezzi più piccoli. Questo può funzionare abbastanza bene (o meno), a seconda di cosa ti trovi di fronte.

Usi XIB solo per il layout e codifica il resto?

Dipende da molte cose.

• XIB-only ha le sue restrizioni ed è molto simile alla duplicazione del codice.Lo uso a volte per la prototipazione, altre volte perché è quello che preferiva qualcun altro.
• "Un po 'di entrambi" può richiedere molta colla. A volte, può essere abbastanza disorganizzato - ad es. "Dov'è l'azione impostata su?". Naturalmente, questo può anche essere usato per ottenere ciò che alcuni considererebbero un buon equilibrio tra XIB e separazione programmatica. Più semplice è XIB, meno spesso dovrà essere regolato e meno probabile causerà conflitti di fusione.
• Solo codice è la mia preferenza, ma ci sono persone che preferiscono semplicemente WYSIWYG e le persone non sono molto familiari a scrivere le interfacce utente a livello di codice. Inoltre, se la qualità, la riusabilità e la manutenibilità non sono requisiti (ad es. Sbattere un prototipo), il solo codice può essere eccessivo.

Oppure, hai avuto fortuna XIBs fusione e con il tempo che hai appena arriva meglio a leggere manualmente?

Nessuna vera fortuna, semplicemente suddividendoli in componenti più piccoli. Sfortunatamente, l'opzione "Decompose Interface" (da IB3) non è disponibile nell'editor di Xc4.

Answer 2

Ho trovato che IB è migliore per il layout come si menziona, ma probabilmente è solo per me perché sono stato sollevato in questo modo. Il codice più è molto più riutilizzabile rispetto ai layout.

Per quanto mi riguarda durante il runtime, entrambi agiscono allo stesso modo anche se non ne sono sicuro al 100%. I prototipi sono meno dolorosi in IB che in codice, lo so per certo e i clienti non prenderanno alcun valore sulla tua prototipazione in codice.

Answer 3

Quello che faccio è non preoccuparsi di provare a unire, accetta solo la versione del ramo completamente o la tua versione. Significa che devi essere un po 'disciplinato su chi arriva a cambiare il codice dell'interfaccia, e su commit e aggiornamenti, in pratica non abbiamo trovato un problema ma immagino dipenda dal tuo ambiente. Non usare questo come scusa per smettere di usare il generatore di interfacce, non c'è niente di peggio che cercare di scavare attraverso il codice di qualcun altro per trovare un pulsante in modo da poter capire cosa succede quando un uso fa clic su di esso. Senza Interface Builder non si rispetta la separazione MVC.