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.
ios
xcode
uistoryboard
xcode-storyboard
Affian
quelle
quelle
Antworten:
Ich habe XIBs ausgiebig genutzt und zwei Projekte mit Storyboards abgeschlossen. Meine Erkenntnisse sind:
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.
quelle
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
UITableViewController
in a ändernUICollectionViewController
? Oder in eine EbeneUIViewController
? 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ügen
UIImageView
: 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
init
beispielsweise benutzerdefinierte Methoden erstelleninitWithCustomer:
. Auf diese Weise können Sie dascustomer
Innere Ihres View Controllers unveränderlich machen und sicherstellen, dass dieser View Controller nicht ohnecustomer
Objekt erstellt werden kann. Dies ist bei Verwendung von Storyboards nicht möglich. Sie müssen warten, bis dieprepareForSegue:sender:
Methode aufgerufen wird, und dann müssen Sie diecustomer
Eigenschaft auf Ihrem Ansichtscontroller festlegen. Dies bedeutet, dass Sie diese Eigenschaft veränderbar machen und zulassen müssen, dass der Ansichtscontroller ohnecustomer
Objekt 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
quelle
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:
Nachteile:
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.
quelle
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.
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.
quelle
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.) ).
quelle
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.
quelle
Wenn Sie sich für die Leistung des Storyboards interessieren, schauen Sie sich die WWDC 2015-Sitzung 407 an
Bauzeit
Laufzeit
quelle
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.
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.
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.
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.
quelle
Wenn Sie eine Benutzeroberfläche in mehreren Ansichtscontrollern wiederverwenden möchten, sollten Sie XIBs verwenden
quelle