Sind diese immer noch negative Argumente gegen die Verwendung von Storyboards bei der Entwicklung von iOS 6-Anwendungen?

Question

Die Verwendung von Storyboards anstelle der traditionellen .xib-Strategie ist etwas, mit dem ich immer noch rumtrete, da es etwas Zögern gibt, etwas zu übernehmen, das so viel unter die Decke tut, ohne wirklich zu verstehen, was es macht und welche Kontrolle ich habe. Ich verliere wirklich.

Das BNR iOS Programming Book hebt einige "Nachteile" der Verwendung von Storyboards hervor. Ich habe sie unten aufgelistet, und meine Frage ist: Sind diese Negative immer noch gültig mit iOS 6?

1. Storyboards sind nur schwer mit in einem Team arbeiten
2. Storyboards vermasseln Versionskontrolle
3. Storyboards stören den Fluss der Programmierung
4. Storyboards opfern Flexibilität und Kontrolle für einfache Bedienung
5. Storyboards immer Erstellen Sie neue Ansicht Controller-Instanzen

Ich bin auf der Suche nach Antworten von Leute, die tatsächlich bauen und vorzugsweise echte iOS-Anwendungen einsetzen und selbst mit den "Storyboards vs .xib" -Ding zu kämpfen haben.

Danke

Answer 1

Ich glaube nicht, dass iOS 6 irgendwelche dieser Situationen behebt. Mehr noch, xcode 4.5 behebt sie nicht oder versucht es sogar. Die aufgelisteten Probleme scheinen Meinungen oder stilistische Vorlieben und vielleicht einige Fehlinformationen widerzuspiegeln. Dies sind nicht die Art von Dingen, die in Code behoben werden können.

Ich benutze Storyboards für eine umfangreiche App und finde sie als echten Produktivitätsschub. Ich ermutige Sie, sie zu versuchen, um zu sehen, wenn Sie nicht einverstanden sind.

Ein paar Kommentare auf der Liste Themen:

1. ich mit Teams und SBs nicht bekannt, dass Fragen bin, aber wenn 2 wahr wären (was es nicht ist), dass diese Sorge erklären würde, . Ich denke, das ist ein Missverständnis basierend auf 2.
2. Nicht wahr. Ich benutze Git religiös und begehe häufig. Kein Problem. Während des Commits werden SBs in ihrer Quellcodeform (XML) angezeigt. Die Diffs funktionieren perfekt und bieten einen Einblick in die Implementierung von SBs. Dies reduziert das Gefühl von mysteriösen "unter der Decke" Verhaltensweisen, was zu einem Nicht-Problem mit Vertrautheit wird.
3. nicht einverstanden. Sie stören den Fluss nicht, sie bieten einen anderen Fluss - dort bekommen sie ihre Kraft. Viele Programmierer finden Wert in der Trennung, die durch die MVC Disziplin auferlegt wird. SBs führen eine Trennung zwischen der Platzierung von UI-Elementen und dem unterstützenden Code ein. Es ist eine natürliche Trennung und eliminiert jede Menge sinnlosen Code (der die Möglichkeit von Tippfehlern beseitigt und den verbleibenden REAL-Code "entstopft").
4. Teilweise stimme zu - sie verbessern definitiv die Benutzerfreundlichkeit. Aber ich finde überhaupt kein Opfer. Auch wenn Sie SBs verwenden, können Sie bei Bedarf jederzeit die Codierung von Objekten rückgängig machen. Es gibt keinen Verzicht auf Flexibilität oder Kontrolle.
5. Nicht sicher, was das bedeutet, und warum es ein Problem sein könnte. Natürlich erstellen wir verschiedene VCs für verschiedene Szenen - das ist natürlich. Aber es ist sicherlich möglich, VC-Klassen in SBs wiederzuverwenden. Dieses Element kann ein Missverständnis darüber sein, wie die Klasse für ein SB-Objekt festgelegt wird. Es ist leicht zu vergessen, diesen Schritt zu tun, und es verunsichert manchmal Anfänger.Aber es ist trivial, zu korrigieren, und das Setzen der Klasse wird schnell zur Gewohnheit.

Für mich sind die wirklichen Anliegen sind:

1. Mit SBs viel Bildschirmfläche für die Entwicklung verlangt. Die Verwendung von SBs kann auf einem kleinen Display frustrierend sein.
2. Hochkomplexe UIs mit vielen vielen Szenen sollten in mehrere SBs aufgeteilt werden. Mehrere SBs werden vollständig unterstützt, aber es ist einfach, dies nicht zu tun. (Es ist wie eine Methode Refactoring, die zu groß wird. In der Regel merke ich, dass ich Code Refraktor muß, nachdem schon etwas chaotisch worden ist.)

Die Bequemlichkeit der SBs während des Layouts und die Beseitigung der so viel von dem Standardcode Das macht VC-Objekte zu einem großen Vorteil. (Jede Codezeile, die ich eliminiere, ist eine Zeile, die ich nicht vermasseln kann, und eine Zeile, die den echten Code nicht verdecken kann.)

Kurz gesagt, ich kann mir nicht vorstellen, ohne zu leben SBs. Ja, es ist eine Veränderung. Aber ich habe keinen wirklich ernsten Nachteil gefunden. Es ist besonders wichtig zu bedenken, dass selbst bei Verwendung von SBs alle Nicht-SB-Codiertechniken noch funktionieren. Gib SB's einen Versuch und berichte deine eigene Erfahrung. Viel Glück!

Answer 2

Ich stimme generell mit jbbenni überein. Die einzige "gültige" Kritik, die ich in deinen Punkten sehe, ist, dass "Storyboards immer eine neue Instanz erstellen". Im Grunde genommen bedeutete dies, dass Sie, obwohl Sie eine Taste drücken konnten, um einen View-Controller auf den Stack zu schieben, keine Taste anschließen konnten, um den Stack ohne zusätzlichen Code zurückzuspeichern. Dies wurde in Xcode 4.5 mit "exit segues" behoben, mit dem Sie angeben können, dass Sie zu einem früheren Controller zurückkehren möchten, anstatt eine neue Instanz zu erstellen.

Die andere Einschränkung von Storyboards, über die sich viele beklagten, war, dass Sie keine Kinderansicht-Controller in das Storyboard integrieren konnten. Dies wurde auch in Xcode 4.5 angesprochen.

Storyboards sind ein bedeutender Schritt vorwärts für iOS-Entwicklung. Beschwerden wie "es macht hart zusammen" sind unbegründet; Storyboards sind nicht schwieriger zu verschmelzen als anderer Code; Sie müssen sich nur die Zeit nehmen, um das Diff tatsächlich zu lesen, anstatt es zu beschönigen, wie "nicht Obj-C; kann nicht lesen."

Ich habe seit ihrer Einführung in einer Teamumgebung erfolgreich Storyboards verwendet. Lass dich nicht vom Uninformierten abschrecken. Sie sind großartig.