Questi negativi ancora validi contro l'utilizzo di Storyboard nello sviluppo di applicazioni iOS 6?

Question

Usare gli storyboard al posto della tradizionale strategia .xib è qualcosa con cui sto ancora combattendo perché c'è un po 'di esitazione nell'adottare qualcosa che fa tanto sotto-coperture senza capire veramente cosa sta facendo, e che controllo io sto davvero perdendo.

Il libro di programmazione BNR iOS evidenzia diversi "contro" nell'utilizzo degli storyboard. Li ho elencati di seguito, e la mia domanda è: Questi negativi sono ancora validi con iOS 6?

1. storyboard sono difficili da lavorare in un team
2. storyboard vite fino il controllo di versione
3. storyboard interrompere il flusso di programmazione
4. storyboard sacrificare flessibilità e controllo per la facilità d'uso
5. storyboard sempre creare nuove istanze del controller di visualizzazione

Sto cercando risposte da ragazzi che stanno effettivamente costruendo, e preferibilmente hanno distribuito applicazioni iOS reali e hanno lottato con le "storyboard vs .xib" stesse.

Grazie

Answer 1

Non credo iOS 6 risolve una di queste situazioni. Più precisamente, xcode 4.5 non li risolve o tenta di farlo. Le questioni elencate sembrano riflettere opinioni o preferenze stilistiche e forse qualche disinformazione. Questi non sono il tipo di cosa che potrebbe essere risolto nel codice.

Sto utilizzando gli storyboard per un'app sostanziale e li trovo un vero vantaggio in termini di produttività. Ti incoraggio a provarli per vedere se non sei d'accordo.

Un paio di commenti sulla lista questioni:

1. io non sono a conoscenza di eventuali problemi con le squadre e SBS, ma se fosse vero 2 (che non è) che spiegherebbe questa preoccupazione . Penso che questo sia un equivoco basato su 2.
2. Non vero. Uso Git religiosamente e commetto frequentemente. Nessun problema. Durante i commit, gli SB vengono visualizzati nel loro codice sorgente (XML). Le differenze funzionano perfettamente e in realtà forniscono alcune informazioni su come vengono implementati gli SB. Questo riduce la sensazione di misteriosi comportamenti "sotto le coperte", che diventano un non-problema con familiarità.
3. Non sono d'accordo. Non interrompono il flusso, offrono un flusso diverso - che è dove ottengono il loro potere. Molti programmatori trovano valore nella separazione imposta dalla disciplina MVC. Gli SB introducono una separazione tra il posizionamento degli elementi dell'interfaccia utente e il codice di supporto. È una divisione naturale ed elimina un sacco di codice irragionevole (che elimina l'opportunità di errori di battitura e "de-clutter" il codice REALE che rimane).
4. In parte d'accordo - sicuramente migliorano la facilità d'uso. Ma non trovo alcun sacrificio. Anche quando usi gli SB puoi sempre tornare a codificare manualmente qualsiasi oggetto, se necessario. Non c'è sacrificio di flessibilità o controllo.
5. Non so cosa significhi e perché potrebbe essere un problema. Naturalmente creiamo diversi VC per scene diverse, è naturale. Ma è certamente possibile riutilizzare le classi VC in SBs. Questo elemento potrebbe essere un equivoco su come impostare la classe per un oggetto SB. È facile dimenticarsi di fare questo passo, ea volte sconcerta i principianti.Ma è banale da correggere e impostare la classe diventa rapidamente un'abitudine.

Per me le vere preoccupazioni sono:

1. Utilizzando SB richiede un sacco di bene immobile dello schermo per lo sviluppo. L'uso di SB può essere frustrante su un piccolo display.
2. Le interfacce utente complesse con molte scene devono essere suddivise in più SB. Multiple SB sono pienamente supportati, ma è facile non riuscire a farlo. (E 'come il refactoring di un metodo che diventa troppo grande. Di solito mi accorgo che ho bisogno di rifrattore codice dopo qualcosa si è già ottenuto disordinato.)

La comodità di SBS durante il layout e l'eliminazione di gran parte del codice standard che ingombra gli oggetti VC è un enorme vantaggio. (Ogni riga di codice che elimini è una riga che non posso rovinare e una riga che non può oscurare il codice reale che rimane.)

In breve, non riesco a immaginare di tornare alla vita senza SB. Sì, è un cambiamento. Ma non ho trovato nessun vero serio inconveniente. È particolarmente importante tenere presente che anche quando si usano SB, tutte le tecniche di codifica non SB funzionano ancora. Fai una prova a SB e segnala la tua esperienza. In bocca al lupo!

Answer 2

Sono generalmente d'accordo con jbbenni. L'unica critica "valida" che vedo nei tuoi punti è che "gli storyboard creano sempre una nuova istanza". Fondamentalmente, questo significava che se si poteva collegare un pulsante per spingere un controller di visualizzazione sullo stack, non si poteva collegare un pulsante per eseguire il backup dello stack senza codice aggiuntivo. Questo problema è stato risolto in Xcode 4.5 con "exit segues", che consente di indicare che si desidera tornare a un controller precedente anziché creare una nuova istanza.

L'altra limitazione degli storyboard di cui molti si sono lamentati è che non è possibile incorporare controller di visualizzazione figlio nello storyboard stesso. Questo è stato anche affrontato in Xcode 4.5.

Gli storyboard rappresentano un significativo passo in avanti per lo sviluppo di iOS. Reclami come "rende difficile l'unione" sono infondati; gli storyboard non sono più difficili da unire rispetto ad altri codici; devi solo prendere il tempo di leggere effettivamente il diff invece di sorvolare su di esso come "non Obj-C; non può leggere".

Ho utilizzato gli storyboard con successo in un ambiente di squadra sin dalla loro introduzione. Non lasciare che i non informati ti spaventino. Sono grandi.