Wann wird Storyboard verwendet und wann werden XIBs verwendet?

Gibt es Richtlinien, wann Storyboards in einem iOS-Projekt und wann XIBs verwendet werden sollen? Was sind die Vor- und Nachteile von jedem und welche Situationen passen sie jeweils?

Soweit ich das beurteilen kann, ist es nicht so sauber, Storyboard-Segmente zu verwenden, wenn View-Controller von dynamischen UI-Elementen (wie Map-Pins) gepusht werden.

Ich habe XIBs ausgiebig genutzt und zwei Projekte mit Storyboards abgeschlossen. Meine Erkenntnisse sind:

• Storyboards eignen sich gut für Apps mit einer kleinen bis mittleren Anzahl von Bildschirmen und einer relativ einfachen Navigation zwischen Ansichten.
• Wenn Sie viele Ansichten und viel Navigation zwischen ihnen haben, wird die Storyboard-Ansicht verwirrend und zu viel Arbeit, um sauber zu bleiben.
• Für ein großes Projekt mit mehreren Entwicklern würde ich keine Storyboards verwenden, da Sie eine einzige Datei für Ihre Benutzeroberfläche haben und nicht einfach parallel arbeiten können.
• Es mag sich für große Apps lohnen, sich in mehrere Storyboard-Dateien aufzuteilen, aber das habe ich nicht versucht. Diese Antwort zeigt, wie Sie zwischen Storyboards wechseln.
• Sie benötigen noch XIBs: In meinen beiden Storyboard-Projekten musste ich XIBs für benutzerdefinierte Tabellenzellen verwenden.

Ich denke, Storyboards sind ein Schritt in die richtige Richtung für die Implementierung der Benutzeroberfläche und hoffe, dass Apple sie in zukünftigen iOS-Versionen erweitern wird. Sie müssen jedoch das Problem "Einzeldatei" lösen, da sie sonst für größere Projekte nicht attraktiv sind.

Wenn ich eine kleine App starte und mir nur iOS5-Kompatibilität leisten kann, würde ich Storyboards verwenden. In allen anderen Fällen halte ich mich an XIBs.

Update 12.01.2016 : Es ist 2016 und ich bevorzuge es immer noch, meine Benutzeroberflächen im Code und nicht in Storyboards auszulegen. Davon abgesehen haben Storyboards einen langen Weg zurückgelegt. Ich habe alle Punkte aus diesem Beitrag entfernt, die 2016 einfach nicht mehr zutreffen.

Update 24.04.2015 : Interessanterweise verwendet Apple nicht einmal Storyboards in seinem kürzlich veröffentlichten ResearchKit, wie Peter Steinberger bemerkt hat (unter der Überschrift "Interface Builder").

Update 10.06.2014 : Wie erwartet verbessert Apple Storyboards und Xcode ständig . Einige der Punkte, die für iOS 7 und niedriger gelten, gelten nicht mehr für iOS 8 (und sind jetzt als solche gekennzeichnet). Während Storyboards von Natur aus immer noch Fehler aufweisen, überarbeite ich meinen Rat von " Nicht verwenden", um selektiv zu verwenden, wo es sinnvoll ist .

Selbst jetzt, wo iOS 9 herauskommt, würde ich raten gegenVorsicht bei der Entscheidung, ob Storyboards verwendet werden sollen. Hier sind meine Gründe:

• Storyboards schlagen zur Laufzeit fehl, nicht zur Kompilierungszeit : Sie haben einen Tippfehler in einem Segue-Namen oder haben ihn in Ihrem Storyboard falsch verbunden? Es wird zur Laufzeit explodieren. Sie verwenden eine benutzerdefinierte UIViewController-Unterklasse, die in Ihrem Storyboard nicht mehr vorhanden ist? Es wird zur Laufzeit explodieren. Wenn Sie solche Dinge im Code tun, werden Sie sie während der Kompilierungszeit frühzeitig abfangen. Update : Mein neues Tool StoryboardLint löst dieses Problem größtenteils.

• Storyboards werden schnell verwirrend : Wenn Ihr Projekt wächst, wird die Navigation in Ihrem Storyboard immer schwieriger. Wenn mehrere Ansichts-Controller mehrere Abschnitte zu mehreren anderen Ansichts-Controllern haben, sieht Ihr Storyboard schnell wie eine Schüssel Spaghetti aus, und Sie zoomen hinein und heraus und scrollen überall herum, um den gewünschten Ansichts-Controller zu finden für und um herauszufinden, welche Segue Punkte wo. Update : Dieses Problem kann größtenteils gelöst werden, indem Sie Ihr Storyboard in mehrere Storyboards aufteilen , wie in diesem Artikel von Pilky und diesem Artikel von Robert Brown beschrieben .

• Storyboards erschweren die Arbeit in einem Team : Da Sie normalerweise nur eine große Storyboard-Datei für Ihr Projekt haben, kann es Kopfschmerzen bereiten, wenn mehrere Entwickler regelmäßig Änderungen an dieser einen Datei vornehmen: Änderungen müssen zusammengeführt und Konflikte gelöst werden. Wenn ein Konflikt auftritt, ist es schwer zu sagen, wie er gelöst werden kann: Xcode generiert die Storyboard-XML-Datei und wurde nicht wirklich mit dem Ziel entwickelt, dass ein Mensch sie lesen oder gar bearbeiten müsste.

• Storyboards machen Codeüberprüfungen schwierig oder nahezu unmöglich : Peer-Codeüberprüfungen sind eine großartige Sache für Ihr Team. Wenn Sie jedoch Änderungen an einem Storyboard vornehmen, ist es fast unmöglich, diese Änderungen mit einem anderen Entwickler zu überprüfen. Alles, was Sie aufrufen können, ist ein Unterschied zu einer riesigen XML-Datei. Es ist wirklich schwer zu entschlüsseln, was sich wirklich geändert hat und ob diese Änderungen korrekt sind oder ob sie etwas kaputt gemacht haben.

• Storyboards behindern die Wiederverwendung von Code : In meinen iOS-Projekten erstelle ich normalerweise eine Klasse, die alle Farben, Schriftarten, Ränder und Einfügungen enthält, die ich in der gesamten App verwende, um ein einheitliches Erscheinungsbild zu erzielen: Es ist eine einzeilige Änderung, wenn ich muss Passen Sie einen dieser Werte für die gesamte App an. Wenn Sie solche Werte im Storyboard festlegen, duplizieren Sie sie und müssen jedes einzelne Vorkommen finden, wenn Sie sie ändern möchten. Die Chancen stehen gut, dass Sie eines verpassen, da Storyboards nicht gesucht und ersetzt werden müssen.

• Storyboards erfordern ständige Kontextwechsel : Ich arbeite und navigiere im Code viel schneller als in Storyboards. Wenn Ihre App Storyboards verwendet, wechseln Sie ständig Ihren Kontext: "Oh, ich möchte auf diese Tabellenansichtszelle tippen, um einen anderen Ansichts-Controller zu laden. Ich muss jetzt das Storyboard öffnen, den richtigen Ansichts-Controller finden und einen neuen Abschnitt erstellen Geben Sie dem Segue einen Namen, merken Sie sich diesen Namen (ich kann keine Konstanten oder Variablen in Storyboards verwenden), wechseln Sie zurück zum Code und hoffen Sie, dass ich den Namen nicht falsch schreibe das segue für meine prepareForSegue-Methode. Wie ich wünschte, ich könnte diese 3 Codezeilen genau hier eingeben, wo ich bin! " Nein, es macht keinen Spaß. Das Umschalten zwischen Code und Storyboard (sowie zwischen Tastatur und Maus) wird schnell alt und verlangsamt Sie.

• Storyboards sind schwer umzugestalten : Wenn Sie Ihren Code umgestalten, müssen Sie sicherstellen, dass er immer noch den Erwartungen Ihres Storyboards entspricht. Wenn Sie Dinge in Ihrem Storyboard verschieben, werden Sie zur Laufzeit nur herausfinden, ob es noch mit Ihrem Code funktioniert. Es fühlt sich für mich so an, als müsste ich zwei Welten synchron halten. Es fühlt sich brüchig an und entmutigt Veränderungen meiner bescheidenen Meinung nach.

• Storyboards sind weniger flexibel : Im Code können Sie grundsätzlich alles tun, was Sie wollen! Mit Storyboards sind Sie auf eine Teilmenge dessen beschränkt, was Sie im Code tun können. Besonders wenn Sie einige fortgeschrittene Dinge mit Animationen und Übergängen machen möchten, werden Sie feststellen, dass Sie "gegen das Storyboard kämpfen", um es zum Laufen zu bringen.

• Mit Storyboards können Sie den Typ der speziellen Ansichtssteuerungen nicht ändern : Sie möchten a UITableViewControllerin a ändern UICollectionViewController? Oder in eine Ebene UIViewController? In einem Storyboard nicht möglich. Sie müssen den alten Ansichts-Controller löschen, einen neuen erstellen und alle Segmente erneut verbinden. Es ist viel einfacher, eine solche Codeänderung vorzunehmen.

• Storyboards fügen Ihrem Projekt zwei zusätzliche Verpflichtungen hinzu : (1) Das Storyboard-Editor-Tool, das das Storyboard-XML generiert, und (2) die Laufzeitkomponente, die das XML analysiert und daraus UI- und Controller-Objekte erstellt. Beide Teile können Fehler enthalten, die Sie nicht beheben können.

• In Storyboards können Sie keine Unteransicht zu einem hinzufügenUIImageView : Wer weiß warum.

• In Storyboards können Sie das automatische Layout für einzelne Ansichten (-Controller) nicht aktivieren : Durch Aktivieren / Deaktivieren der Option Auto Layout in einem Storyboard wird die Änderung auf ALLE Controller im Storyboard angewendet. (Danke an Sava Mazăre für diesen Punkt!)

• Storyboards haben ein höheres Risiko, die Abwärtskompatibilität zu beeinträchtigen : Xcode ändert manchmal das Storyboard-Dateiformat und garantiert in keiner Weise, dass Sie Storyboard-Dateien öffnen können, die Sie heute in einigen Jahren oder sogar Monaten erstellen. (Dank an nachdenkliche Fortschritte für diesen Punkt. Siehe den ursprünglichen Kommentar )

• Storyboards können Ihren Code komplexer machen : Wenn Sie Ihre View Controller im Code erstellen, können Sie initbeispielsweise benutzerdefinierte Methoden erstellen initWithCustomer:. Auf diese Weise können Sie das customerInnere Ihres View Controllers unveränderlich machen und sicherstellen, dass dieser View Controller nicht ohne customerObjekt erstellt werden kann. Dies ist bei Verwendung von Storyboards nicht möglich. Sie müssen warten, bis die prepareForSegue:sender:Methode aufgerufen wird, und dann müssen Sie die customerEigenschaft auf Ihrem Ansichtscontroller festlegen. Dies bedeutet, dass Sie diese Eigenschaft veränderbar machen und zulassen müssen, dass der Ansichtscontroller ohne customerObjekt erstellt wird . Nach meiner Erfahrung kann dies Ihren Code erheblich verkomplizieren und es schwieriger machen, über den Fluss Ihrer App nachzudenken. Update 09.09.16: Chris Dzombak hat einen großartigen Artikel über dieses Problem geschrieben .

• Es ist McDonald's : Um es in Steve Jobs 'Worten über Microsoft zu sagen: Es ist McDonald's (Video) !

Dies sind meine Gründe, warum ich wirklich nicht gerne mit Storyboards arbeite. Einige dieser Gründe gelten auch für XIBs. Bei den Storyboard-basierten Projekten, an denen ich gearbeitet habe, haben sie mich viel mehr Zeit gekostet als gespart und die Dinge komplizierter anstatt einfacher gemacht.

Wenn ich meine Benutzeroberfläche und meinen Anwendungsfluss in Code erstelle, habe ich viel mehr Kontrolle darüber, was vor sich geht, es ist einfacher zu debuggen, es ist einfacher, Fehler frühzeitig zu erkennen, es ist einfacher, meine Änderungen anderen Entwicklern und anderen zu erklären ist einfacher, iPhone und iPad zu unterstützen.

Ich bin jedoch damit einverstanden, dass das Auslegen Ihrer gesamten Benutzeroberfläche in Code möglicherweise nicht für jedes Projekt eine einheitliche Lösung darstellt. Wenn sich Ihre iPad-Benutzeroberfläche an bestimmten Stellen stark von Ihrer iPhone-Benutzeroberfläche unterscheidet, ist es möglicherweise sinnvoll, eine XIB nur für diese Bereiche zu erstellen.

Viele der oben beschriebenen Probleme könnten von Apple behoben werden, und ich hoffe, dass sie dies tun werden.

Nur meine zwei Cent.

Update : In Xcode 5 hat Apple die Option zum Erstellen eines Projekts ohne Storyboard entfernt. Ich habe ein kleines Skript geschrieben, das die Vorlagen von Xcode 4 (mit der Option zum Deaktivieren des Storyboards) auf Xcode 5 portiert: https://github.com/jfahrenkrug/Xcode4templates

Storyboards wurden erstellt, um Entwicklern die Visualisierung ihrer Anwendung und des Ablaufs der Anwendung zu erleichtern. Es ist viel wie ein Haufen xib, aber in einer einzigen Datei.

Es gibt eine ähnliche Frage. Was ist der Unterschied zwischen einer .xib-Datei und einem .storyboard? .

Sie können auch benutzerdefinierte Übergänge über Code erstellen, der sich bei Bedarf dynamisch ändert, ähnlich wie bei .xibs.

PROS:

• Sie können den Ablauf einer Anwendung nachahmen, ohne viel oder gar keinen Code zu schreiben.
• Es ist viel einfacher, Ihre Übergänge zwischen Bildschirmen und Ihrem Anwendungsfluss zu erkennen.
• Kann bei Bedarf auch .xibs mit Storyboards verwenden.

Nachteile:

• Funktioniert nur mit iOS 5+. Funktioniert nicht mit iOS4.
• Kann leicht überladen werden, wenn Sie eine sehr ansichtsintensive Anwendung haben.

Es gibt wirklich kein Richtig / Falsch, wann man das eine oder das andere verwendet, es ist nur eine Frage der Präferenz und der iOS-Versionen, die Sie verwenden möchten.

Ich werde erklären , nur 4 einfache Gründe , warum Sie sollten Storyboards, vor allem in einer produktiven Umgebung verwenden , wo Sie in einem Team von Produktbesitzern zur Arbeit haben, Produktmanager, UX - Designer, usw.

1. Apple hat die Arbeit mit Storyboards erheblich verbessert. Und sie ermutigen dich, mit ihnen zu arbeiten. Dies bedeutet, dass Ihre vorhandenen Projekte nicht durch Updates beschädigt werden. Sie stellen sicher, dass Storyboards für neuere XCode / iOS-Versionen zukunftssicher sind.
2. Mehr sichtbare Ergebnisse bedeuten weniger Zeit für die Produktbesitzer und -manager, selbst während der Erstellungsphase. Sie können das Storyboard selbst sogar als Bildschirmablaufdiagramm verwenden und in Besprechungen diskutieren.
3. Selbst nachdem eine App fertig ist (und in der Regel beginnt dort ihr Lebenszyklus) , können kleine Anpassungen in Zukunft schneller und einfacher vorgenommen werden . Und diese können sehr gut mehrere Aspekte Ihres Layouts gleichzeitig ändern, die Sie wahrscheinlich auf WYSIWYG-Weise sehen möchten. Die Alternative wäre, Änderungen der Benutzeroberfläche im Code von Hand zu schreiben und zwischen der IDE und dem Simulator hin und her zu wechseln, um sie zu testen, wobei jedes Mal auf Kompilieren und Erstellen gewartet wird.
4. Nicht-Entwicklern kann beigebracht werden , Layouts in Storyboards einzurichten und die erforderlichen Hooks für die Entwickler (IBOutlets und IBActions) zu erstellen. Das ist ein sehr großes Plus, da sich die Entwickler auf die Logik konzentrieren können und die UX-Designer ihre Änderungen visuell anwenden können, ohne überhaupt Code schreiben zu müssen.

Ich werde keine CONS aufschreiben, da Johannes in seiner Antwort wahrscheinlich bereits alle brauchbaren aufgeführt hat. Und die meisten von ihnen sind definitiv nicht realisierbar, insbesondere nicht mit den wesentlichen Verbesserungen von XCode6.

Ich glaube nicht, dass es eine richtige Antwort auf Ihre Frage gibt, es ist nur eine Frage der persönlichen Erfahrung und dessen, womit Sie sich wohler fühlen.

Meiner Meinung nach sind Storyboards eine großartige Sache. Es ist wahr, es ist wirklich schwer herauszufinden, warum Ihre App zur Laufzeit auf mysteriöse Weise abstürzt, aber nach einiger Zeit und Erfahrung werden Sie feststellen, dass es immer mit einem IBOutlet zusammenhängt, das irgendwo fehlt, und Sie werden es leicht beheben können.

Das einzige wirkliche Problem ist die Arbeit im Team unter Versionskontrolle mit Storyboards. In den frühen Entwicklungsstadien könnte es ein echtes Durcheinander sein. Nach dieser ersten Phase sind UI-Updates, die das Storyboard vollständig ändern, sehr selten. In den meisten Fällen kommt es zu Konflikten in den letzten Teilen der XML-Datei. Hierbei handelt es sich um Segue-Referenzen, die sich normalerweise beim erneuten Öffnen des Storyboards automatisch fixieren . In unserer Teamarbeit haben wir es vorgezogen, uns damit zu befassen, anstatt schwere View-Controller mit tonnenweise View-Code.

Ich habe viele Kommentare zum automatischen Layout gelesen. Mit XCode5 wurde es wirklich verbessert. Es ist sogar für das Autorotieren von Layouts wirklich gut. In einigen Fällen müssen Sie etwas im Code tun, aber Sie können einfach die Einschränkung, die Sie bearbeiten müssen, auslassen und an diesem Punkt das tun, was Sie in Ihrem Code benötigen. Animiere sie sogar.

Ich denke auch, dass die meisten Leute, die Storyboards nicht mögen, nicht vollständig versucht haben, die Leistungsfähigkeit eines benutzerdefinierten manuellen Segues zu verstehen, bei dem Sie (in einer einzigen Datei) die Art und Weise, wie Sie von einem Weg zu einem anderen wechseln, und auch (mit) vollständig anpassen können Einige Tricks) verwenden einen zuvor geladenen Ansichts-Controller sogar wieder, indem sie nur den Ansichtsinhalt aktualisieren, anstatt das Ganze vollständig neu zu laden. Am Ende können Sie wirklich die gleichen Dinge wie im Code tun, aber ich denke, Sie haben eine bessere Trennung von Bedenken in Bezug auf Storyboards, aber ich stimme zu, dass ihnen in vielen Dingen Funktionen fehlen (Schriftarten, Bild als farbiger Hintergrund, usw.) ).

Ich verwende in keiner App StoryBoard oder XIBs, sondern erstelle alles programmgesteuert.

∆ Vorteile:

√ Sie können jede Art von komplexer Benutzeroberfläche oder Übergangsanimationen für UIView's erstellen .

√ Unterstützt alle iOS-Versionen. Sie müssen sich keine Sorgen um <iOS 5 machen.

√ * Ihre App unterstützt alle iPhone / iPod / iPad-Geräte in Ihrem Code.

√ Sie werden immer aktualisiert, wenn Sie den Code kennen, der immer funktioniert.

√ * Funktioniert auf jedem (neuen) Gerät, das gestartet wurde - Code muss nicht geändert werden.

√ Alles liegt bei Ihnen. An einer bestimmten Stelle möchten Sie etwas ändern - Sie müssen nicht in Storyboard oder Xib schauen. Suchen Sie einfach in einer bestimmten Klasse danach.

√ Last but not the list - Sie werden nie vergessen, wie Sie alles programmgesteuert verwalten. Dies ist das Beste, da Sie eine Kontrolle kennen, die sehr tief ist als jede andere.

_{Ich habe nie ein Problem gefunden, wenn ich keine SB oder XIBs verwendet habe, da ich damit gut bin.}

_{* Wenn Sie die Objektrahmen von UIKit entsprechend der Bildschirmgröße festgelegt haben.}

_{PS Wenn Sie diese Sache noch nicht getan haben - Sie haben möglicherweise Schwierigkeiten (oder fühlen sich langweilig), aber sobald Sie sich damit vertraut gemacht haben - ist es wirklich eine Süßigkeit für Sie.}

Wenn Sie sich für die Leistung des Storyboards interessieren, schauen Sie sich die WWDC 2015-Sitzung 407 an

Bauzeit

Wenn der Interface Builder ein Storyboard kompiliert, werden zwei Dinge ausgeführt: Erstens wird versucht, die Leistung Ihrer Anwendung zu maximieren, und zweitens wird die Anzahl der erstellten NIB-Dateien minimiert.

Wenn ich einen Ansichtscontroller mit einer Ansicht und einer Reihe von Unteransichten, Interface Builder, habe, erstellt die Erstellungszeit eine NIB-Datei für den Ansichts-Controller und eine NIB-Datei für die Ansicht.

Durch separate NIB-Dateien sowohl für den View Controller als auch für die View kann die View-Hierarchie bei Bedarf geladen werden.

Laufzeit

Wenn Sie eine Storyboard-Instanz mithilfe der UI-Storyboard-API zuweisen, weisen Sie zunächst nur die UI-Storyboard-Instanz selbst zu.

Keine View Controller noch keine Views.

Wenn Sie Ihren anfänglichen Ansichts-Controller instanziieren, wird die Schreibfeder für diesen anfänglichen Ansichts-Controller geladen, aber es wurde noch keine Ansichtshierarchie geladen, bis tatsächlich jemand danach fragt.

Ich habe an einem Projekt von angemessener Größe gearbeitet (> 20 Szenen im Storyboard-Sprachgebrauch), bin auf viele Einschränkungen gestoßen und muss wiederholt zur Dokumentation und zur Google-Suche gehen, um Dinge zu tun.

1. Die Benutzeroberfläche befindet sich in einer Datei. Selbst wenn Sie mehrere Storyboards erstellen, befinden sich in jedem Storyboard viele Szenen / Bildschirme. Dies ist ein Problem in mittelgroßen Teams.

2. Zweitens spielen sie nicht gut mit benutzerdefinierten Container-Controllern, in die andere Container-Controller usw. eingebettet sind. Wir verwenden MFSlideMenu in einer Anwendung mit Registerkarten, und die Szene verfügt über eine Tabelle. Mit einem Storyboard ist das fast unmöglich. Nachdem ich Tage verbracht habe, habe ich auf die XIB-Methode zurückgegriffen, bei der die vollständige Kontrolle besteht.

3. Die IDE erlaubt keine Auswahl von Steuerelementen im verkleinerten Zustand. In einem großen Projekt dient das Herauszoomen hauptsächlich dazu, eine Ansicht auf hoher Ebene zu erhalten, und nicht mehr.

Ich würde Storyboards für kleinere Anwendungen mit kleinen Teamgrößen verwenden und den XIB-Ansatz für mittelgroße Teams / Projekte verwenden.

Wenn Sie eine Benutzeroberfläche in mehreren Ansichtscontrollern wiederverwenden möchten, sollten Sie XIBs verwenden