Quando usare lo Storyboard e quando usare gli XIB

Ci sono delle linee guida su quando usare gli storyboard in un progetto iOS e quando usare gli XIB? quali sono i pro e i contro di ciascuno e quali situazioni si adattano a ciascuno?

Per quanto ne sappia, non è così semplice utilizzare i follower dello storyboard quando i controller di visualizzazione sono spinti da elementi dell'interfaccia utente dinamica (come i pin della mappa).

Ho usato ampiamente gli XIB e ho completato due progetti usando Storyboard. I miei apprendimenti sono:

• Gli storyboard sono utili per le app con un numero medio-piccolo di schermate e una navigazione relativamente semplice tra le visualizzazioni.
• Se hai molte visualizzazioni e molta navigazione incrociata tra loro, la visualizzazione Storyboard diventa confusa e troppo lavoro per essere pulita.
• Per un grande progetto con più sviluppatori non userei gli Storyboard perché hai un singolo file per la tua UI e non puoi lavorare facilmente in parallelo.
• Potrebbe valere la pena che le app di grandi dimensioni si suddividano in più file di storyboard, ma non l'ho provato. Questa risposta mostra come fare segues tra storyboard.
• Hai ancora bisogno di XIB: in entrambi i miei progetti Storyboard ho dovuto usare XIB per celle di tabella personalizzate.

Penso che gli storyboard siano un passo nella giusta direzione per l'implementazione dell'interfaccia utente e spero che Apple li estenda nelle future versioni di iOS. Tuttavia, devono risolvere il problema del "file singolo", altrimenti non saranno attraenti per i progetti più grandi.

Se avessi avviato un'app di piccole dimensioni e potessi permettermi solo la compatibilità con iOS5, avrei usato Storyboard. Per tutti gli altri casi, mi attengo agli XIB.

Aggiornamento 1/12/2016 : è il 2016 e preferisco ancora impostare le mie UI nel codice e non negli Storyboard. Detto questo, gli storyboard hanno fatto molta strada. Ho rimosso tutti i punti da questo post che semplicemente non si applicano più nel 2016.

Aggiornamento 24/04/2015 : È interessante notare che Apple non usa nemmeno gli Storyboard nel suo ResearchKit di recente provenienza, come ha notato Peter Steinberger (sotto il sottotitolo "Interface Builder").

Aggiornamento del 6/10/2014 : come previsto, Apple continua a migliorare Storyboard e Xcode. Alcuni dei punti applicati a iOS 7 e versioni precedenti non si applicano più a iOS 8 (e ora sono contrassegnati come tali). Quindi, sebbene gli Storyboard abbiano intrinsecamente ancora difetti, rivedo il mio consiglio di non usare per usare selettivamente dove ha senso .

Anche ora che iOS 9 è uscito, lo consiglierei controprestare attenzione quando si decide se utilizzare gli storyboard. Ecco i miei motivi:

• Gli storyboard falliscono in fase di esecuzione, non in fase di compilazione : hai un errore di battitura in un nome seguito o lo hai collegato in modo errato nello storyboard? Si esploderà in fase di esecuzione. Utilizzi una sottoclasse UIViewController personalizzata che non esiste più nello storyboard? Si esploderà in fase di esecuzione. Se fai queste cose nel codice, le prenderai presto, durante la compilazione. Aggiornamento : il mio nuovo strumento StoryboardLint risolve principalmente questo problema.

• Gli storyboard diventano rapidamente confusi : man mano che il progetto cresce, lo storyboard diventa sempre più difficile da navigare. Inoltre, se più controller di visualizzazione hanno più follower su più altri controller di visualizzazione, lo storyboard inizia rapidamente a sembrare una scodella di spaghetti e ti ritroverai a zoomare avanti e indietro e scorrere ovunque per trovare il controller di vista che stai cercando per e per scoprire cosa segue punti dove. Aggiornamento : questo problema può essere risolto principalmente dividendo lo Storyboard in più Storyboard, come descritto in questo articolo di Pilky e in questo articolo di Robert Brown .

• Gli storyboard rendono il lavoro in gruppo più difficile : poiché di solito hai solo un enorme file di storyboard per il tuo progetto, avere più sviluppatori che apportano regolarmente modifiche a quel file può essere un mal di testa: le modifiche devono essere unite e i conflitti risolti. Quando si verifica un conflitto, è difficile dire come risolverlo: Xcode genera il file XML dello storyboard e non è stato realmente progettato con l'obiettivo in mente che un essere umano dovrebbe leggere, figuriamoci modificarlo.

• Gli storyboard rendono le revisioni del codice difficili o quasi impossibili : le revisioni dei codici peer sono un'ottima cosa da fare per il tuo team. Tuttavia, quando si apportano modifiche a uno storyboard, è quasi impossibile rivedere queste modifiche con uno sviluppatore diverso. Tutto ciò che puoi estrarre è una diff di un enorme file XML. Decifrare ciò che è realmente cambiato e se quei cambiamenti sono corretti o se hanno rotto qualcosa è davvero difficile.

• Gli storyboard ostacolano il riutilizzo del codice : nei miei progetti iOS, di solito creo una classe che contiene tutti i colori, i caratteri, i margini e gli inserti che utilizzo in tutta l'app per dargli un aspetto coerente: è un cambio di una riga se devo regola uno di questi valori per l'intera app. Se imposti tali valori nello storyboard, li duplichi e dovrai trovare ogni singola occorrenza quando vuoi cambiarli. È molto probabile che tu ne perda uno, perché non c'è ricerca e sostituzione negli storyboard.

• Gli storyboard richiedono costanti cambi di contesto : mi trovo a lavorare e navigare molto più velocemente nel codice che negli storyboard. Quando la tua app utilizza gli storyboard, cambi continuamente contesto: "Oh, voglio un tocco su questa cella di visualizzazione tabella per caricare un controller di visualizzazione diverso. Ora devo aprire lo storyboard, trovare il controller di visualizzazione giusto, creare un nuovo seguito all'altro controller di visualizzazione (che devo anche trovare), dai un nome ai seguaci, ricorda quel nome (non riesco a usare costanti o variabili negli storyboard), torna al codice e spero di non sbagliare a digitare il nome di che segue per il mio metodoifyForSegue. Come vorrei poter semplicemente digitare quelle 3 righe di codice proprio qui dove sono! " No, non è divertente. Il passaggio tra codice e storyboard (e tra tastiera e mouse) invecchia rapidamente e ti rallenta.

• Gli storyboard sono difficili da refactoring : quando si esegue il refactoring del codice, è necessario assicurarsi che corrisponda ancora a ciò che si aspetta lo storyboard. Quando sposti le cose nello storyboard, scoprirai in fase di esecuzione solo se funziona ancora con il tuo codice. Mi sembra di dover sincronizzare due mondi. È fragile e scoraggia il cambiamento secondo la mia modesta opinione.

• Gli storyboard sono meno flessibili : nel codice puoi praticamente fare tutto quello che vuoi! Con gli storyboard sei limitato a un sottoinsieme di ciò che puoi fare nel codice. Soprattutto quando vuoi fare alcune cose avanzate con animazioni e transizioni ti troverai a "combattere lo storyboard" per farlo funzionare.

• Gli storyboard non ti consentono di cambiare il tipo di controller di visualizzazione speciali : vuoi cambiare a UITableViewControllerin UICollectionViewController? O in una pianura UIViewController? Non è possibile in uno storyboard. Devi eliminare il vecchio controller di visualizzazione e crearne uno nuovo e riconnettere tutti i follower. È molto più semplice apportare una tale modifica al codice.

• Gli storyboard aggiungono due ulteriori responsabilità al tuo progetto : (1) Lo strumento Editor storyboard che genera lo storyboard XML e (2) il componente runtime che analizza l'XML e crea l'interfaccia utente e gli oggetti controller da esso. Entrambe le parti possono contenere bug che non è possibile correggere.

• Gli storyboard non ti consentono di aggiungere una sottoview aUIImageView : Chissà perché.

• Gli storyboard non ti consentono di abilitare il layout automatico per le singole viste (-Controller) : selezionando / deselezionando l'opzione Layout automatico in uno storyboard, la modifica viene applicata a TUTTI i controller nello storyboard. (Grazie a Sava Mazăre per questo punto!)

• Gli storyboard hanno un rischio maggiore di interrompere la compatibilità all'indietro : Xcode a volte modifica il formato del file Storyboard e non garantisce in alcun modo che sarai in grado di aprire i file Storyboard che crei oggi tra qualche anno o addirittura mesi. (Grazie a Thoughtadvances per questo punto. Vedi il commento originale )

• Gli storyboard possono rendere il codice più complesso : quando crei i controller di visualizzazione nel codice, puoi creare initmetodi personalizzati , ad esempio initWithCustomer:. In questo modo, è possibile rendere customerimmutabile l' interno del controller della vista e assicurarsi che questo controller della vista non possa essere creato senza un customeroggetto. Questo non è possibile quando si utilizzano gli storyboard. Dovrai attendere prepareForSegue:sender:che venga chiamato il metodo, quindi dovrai impostare la customerproprietà sul controller della vista, il che significa che devi rendere mutevole questa proprietà e dovrai consentire la creazione del controller della vista senza un customeroggetto . Nella mia esperienza questo può complicare notevolmente il tuo codice e rendere più difficile ragionare sul flusso della tua app. Aggiornamento del 09/09/16: Chris Dzombak ha scritto un ottimo articolo su questo problema .

• È McDonald's : per dirlo con le parole di Steve Jobs su Microsoft: è McDonald's (video) !

Questi sono i motivi per cui non mi piace davvero lavorare con gli storyboard. Alcuni di questi motivi si applicano anche agli XIB. Nei progetti basati su storyboard a cui ho lavorato, mi sono costati molto più tempo di quanto abbiano risparmiato e hanno reso le cose più complicate anziché più semplici.

Quando creo la mia interfaccia utente e il flusso di applicazioni nel codice, ho molto più controllo su ciò che sta accadendo, è più facile eseguire il debug, è più facile individuare errori in anticipo, è più facile spiegare le mie modifiche ad altri sviluppatori e è più facile supportare iPhone e iPad.

Tuttavia, sono d'accordo sul fatto che la disposizione dell'intera interfaccia utente nel codice potrebbe non essere una soluzione unica per tutti i progetti. Se l'interfaccia utente del tuo iPad differisce notevolmente dall'interfaccia utente del tuo iPhone in alcuni punti, potrebbe essere sensato creare un XIB solo per quelle aree.

Molti dei problemi descritti sopra potrebbero essere risolti da Apple e spero che sia quello che faranno.

Solo i miei due centesimi.

Aggiornamento : in Xcode 5, Apple ha tolto l'opzione per creare un progetto senza Storyboard. Ho scritto un piccolo script che porta i modelli di Xcode 4 (con l'opzione di opt-out per Storyboard) su Xcode 5: https://github.com/jfahrenkrug/Xcode4templates

Gli storyboard sono stati creati per aiutare gli sviluppatori a visualizzare la loro applicazione e il flusso dell'applicazione. È molto come avere un sacco di xib ma in un singolo file.

C'è una domanda simile a questa trova Qual è la differenza tra un file .xib e un .storyboard? .

Puoi anche creare transizioni personalizzate tramite codice che cambierà dinamicamente se necessario, proprio come puoi fare con .xibs.

PROFESSIONISTI:

• Puoi simulare il flusso di un'applicazione senza scrivere molto, se non con alcun codice.
• Molto più facile vedere le transizioni tra le schermate e il flusso dell'applicazione.
• Può anche usare .xibs se necessario con gli storyboard.

CONS:

• Funziona solo con iOS 5+. Non funziona con iOS4.
• Può essere facilmente ingombra se si dispone di un'applicazione molto intensa.

Non c'è davvero un giusto / sbagliato quando usare l'uno o l'altro, è solo una questione di preferenza e quali versioni di iOS che si desidera utilizzare.

Spiegherò solo 4 semplici motivi per cui dovresti usare gli storyboard, specialmente in un ambiente produttivo in cui devi lavorare in un team di proprietari di prodotti, responsabili di prodotto, progettisti di UX, ecc.

1. Apple ha notevolmente migliorato il lavoro con gli storyboard. E ti incoraggiano a lavorare con loro. Ciò significa che non romperanno i tuoi progetti esistenti con gli aggiornamenti, assicureranno che gli storyboard siano a prova di futuro per le versioni XCode / iOS più recenti.
2. Risultati più visibili in meno tempo per i proprietari e i gestori del prodotto, anche durante la fase di creazione. Puoi persino usare lo storyboard stesso come diagramma del flusso di schermo e discuterne durante le riunioni.
3. Anche dopo che un'app è stata eseguita (ed è generalmente qui che inizia il suo ciclo di vita) - in futuro sarà più veloce e più facile applicare piccole regolazioni . E questi potrebbero benissimo cambiare contemporaneamente più aspetti del layout, che probabilmente vorrai vedere in modo WYSIWYG. L'alternativa sarebbe scrivere a mano le modifiche dell'interfaccia utente nel codice e passare avanti e indietro tra l'IDE e il simulatore per testarlo, ogni volta in attesa di compilazione e compilazione.
4. Ai non sviluppatori può essere insegnato a impostare layout negli storyboard e creare gli hook necessari per gli sviluppatori (IBOutlets e IBActions). Questo è un grande vantaggio perché consente agli sviluppatori di concentrarsi sulla logica e i progettisti di UX applicano le loro modifiche in modo visivo, senza dover scrivere alcun codice.

Non scriverò alcun contro, dal momento che Johannes ha già elencato probabilmente tutti quelli praticabili nella sua risposta. E la maggior parte di essi non è assolutamente fattibile, soprattutto con i miglioramenti di XCode6.

Non credo che ci sia una risposta giusta per la tua domanda, è solo una questione di esperienza personale e con cui ti senti più a tuo agio.

Secondo me, gli storyboard sono una grande cosa. È vero, è davvero difficile scoprire perché la tua app si blocca misteriosamente in fase di runtime, ma dopo un po 'di tempo ed esperienza ti accorgerai che è sempre collegata a qualche IBOutlet mancante da qualche parte e sarai facilmente in grado di risolverlo.

L'unico vero problema è lavorare in team sotto il controllo della versione con gli storyboard, nelle prime fasi di sviluppo potrebbe essere un vero casino. Ma dopo quel primo stadio, gli aggiornamenti dell'interfaccia utente che cambiano completamente lo storyboard sono molto rari e nella maggior parte dei casi si verificano conflitti nelle ultime parti dell'xml, che sono i riferimenti che di solito si auto-correggono quando si riapre lo storyboard . Nel nostro lavoro di gruppo abbiamo preferito occuparci di questo anziché di pesanti controller di vista con tonnellate di codice di visualizzazione.

Ho letto molti commenti sull'auto-layout. Con XCode5 è stato davvero migliorato, è ottimo anche per i layout di autorotazione. In alcuni casi dovrai fare qualcosa nel codice, ma puoi semplicemente eliminare il vincolo che devi modificare e, a quel punto, fare quello che ti serve nel tuo codice. Anche animarli.

Penso anche che la maggior parte delle persone a cui non piacciono gli storyboard non abbiano provato a comprendere appieno la potenza di un manuale personalizzato che segue, in cui è possibile personalizzare totalmente (in un singolo file) il modo in cui si passa da un modo all'altro e anche (con alcuni trucchi) persino riutilizzare un controller di visualizzazione precedentemente caricato semplicemente aggiornando i contenuti della visualizzazione anziché ricaricare completamente il tutto. Alla fine puoi davvero fare le stesse cose del codice, ma penso che tu abbia una migliore separazione delle preoccupazioni con gli storyboard, ma sono d'accordo sul fatto che in molte cose mancano di funzionalità (caratteri, immagine come sfondo di colore, ecc ... ).

Non sto usando StoryBoard o XIBs in nessuna delle mie app ... ma sto creando tutto a livello di programmazione.

∆ Vantaggi:

√ È possibile creare qualsiasi tipo complesso di interfaccia utente o animazioni di transizione per UIView.

√ Supporta tutte le versioni di iOS. Non devi preoccuparti di <iOS 5.

√ * L'app supporta tutti i dispositivi iPhone / iPod / iPad nel tuo codice.

√ Sei sempre aggiornato perché conosci il codice che funzionerà sempre.

√ * Funzionerà su qualsiasi (nuovo) dispositivo lanciato - Non è necessario modificare il codice.

√ Tutto dipende da te. In un determinato posto in cui vuoi cambiare qualcosa - Non c'è bisogno di guardare nello storyboard o in xib. Basta cercarlo in una classe particolare.

√ Ultimo ma non l'elenco: non lo dimenticherai mai, come gestire tutto a livello di programmazione. Questa è la cosa migliore perché conosci un controllo molto profondo di chiunque altro.

_{Non ho mai trovato un problema non usando SB o XIB come sto bene con questo.}

_{* se hai impostato i frame degli oggetti di UIKit in base alle dimensioni dello schermo.}

_{PS Se non hai ancora fatto questa cosa - potresti avere difficoltà (o potresti sentirti noioso) ma una volta che avrai familiarità con questo - è davvero una caramella per te.}

Se stai per preoccuparti delle prestazioni dello Storyboard, guarda la Sessione 407 del WWDC 2015

Tempo di costruzione

Quando il generatore di interfacce sta compilando uno storyboard, sta facendo prima due cose, sta cercando di massimizzare le prestazioni della tua applicazione e, in secondo luogo, sta anche minimizzando il numero di file pennino creati.

Se ho un controller di visualizzazione con una vista e un mucchio di viste secondarie, builder di interfaccia, il tempo di creazione creerà un file pennino per il controller di visualizzazione e creerà un file pennino per la vista.

Avendo file di pennini separati sia per il controller della vista che per la vista, ciò significa che la gerarchia della vista può essere caricata su richiesta.

Tempo di esecuzione

Quando si alloca un'istanza dello storyboard utilizzando lo storyboard dell'interfaccia utente, API, inizialmente tutto ciò che si sta allocando memoria è l'istanza dello storyboard dell'interfaccia utente stessa.

Nessun controller di visualizzazione ancora nessuna visualizzazione.

Quando si crea un'istanza del controller di visualizzazione iniziale, questo caricherà il pennino per quel controller di visualizzazione iniziale ma, ancora una volta, non è stata ancora caricata una gerarchia di viste fino a quando qualcuno non lo richiede effettivamente.

Ho lavorato su un progetto di dimensioni ragionevoli (> 20 scene in stile storyboard), e ho riscontrato molte limitazioni e devo andare ripetutamente alla documentazione e alle ricerche su Google per fare le cose.

1. L'interfaccia utente è tutto in un unico file. Anche se crei più storyboard, hai comunque molte scene / schermate in ogni storyboard. Questo è un problema nei team medio-grandi.

2. In secondo luogo, non giocano bene con i controller contenitore personalizzati che incorporano altri controller contenitore ecc. Stiamo usando MFSlideMenu in un'applicazione a schede e la scena ha una tabella. Questo è quasi impossibile da fare con uno storyboard. Dopo aver trascorso giorni, ho fatto ricorso al modo XIB in cui c'è il controllo completo.

3. L'IDE non consente di selezionare i controlli in stato di ingrandimento. Quindi, in un grande progetto, lo zoom indietro serve principalmente per ottenere una vista di alto livello e niente di più.

Vorrei utilizzare gli storyboard per applicazioni più piccole con team di piccole dimensioni e utilizzare l'approccio XIB per team / progetti medio-grandi.

Se si desidera riutilizzare alcune UI in più controller di visualizzazione, è necessario utilizzare gli XIB