Ich arbeite in einer Firma, in der wir mehrere iOS-Entwickler haben und wir verwenden GIT, um in denselben Projekten zusammenzuarbeiten. Wir verwenden in unserem Entwicklungsprozess niemals Storyboards oder .xib-Dateien, da es nahezu unmöglich ist, sie korrekt zusammenzuführen.
Mit der Einführung von iOS7 habe ich über die grundlegenden Unterschiede zwischen Storyboards und der Programmierung der gesamten Benutzeroberfläche nachgedacht, ohne die Verwendung von Interface Builder.
Gibt es jemanden, der genau das tut? Und was ist am wichtigsten, gibt es etwas, was Sie in Storyboards tun können, was Sie in Code in XCode 5 nicht tun können?
Ich werde Ihre Frage in zwei aufteilen: NIBs und Storyboards.
Was NIBs angeht, können Quellcodeverwaltungsprobleme zwar schmerzhaft, aber beherrschbar sein, hauptsächlich weil Sie normalerweise eine NIB-Datei pro View-Controller haben. Sie können sich eine Situation vorstellen, in der zwei Entwickler an zwei verschiedenen Abschnitten Ihrer NIB-basierten App arbeiten, ohne dass Probleme auftreten. Storyboards unterscheiden sich, da Sie eine einzige Datei haben, die die meisten - wenn nicht alle - der Benutzeroberfläche Ihrer Anwendung beschreibt. Offensichtlich gibt es dort ein viel größeres Potenzial für Konfliktfragen.
NIBs können sehr nützlich und zeitsparend sein, wenn sie richtig verwendet werden. Hier ein Beispiel: Die iPhoto App auf dem iPad hat eine sehr komplexe Benutzeroberfläche. Die große Mehrheit dieser Benutzeroberfläche ist programmatisch angelegt. Allerdings verwendet die App auch NIBs, um grafische Elemente zu laden, die dann im Code angeordnet werden. So funktioniert das Pinselfenster - alle Pinsel werden in einer NIB erstellt. Dies bedeutet, dass Apple nicht Dutzende identischer image / image view alloc / init-Codeteile haben muss. Die gesamte Erstellung kann in einer NIB erfolgen (dies wurde in einer WWDC 2012-Sitzung auf der iPhoto-Benutzeroberfläche ausführlich besprochen - es lohnt sich, diese zu finden).
So NIBs - manchmal gut, können Sie eine Menge Zeit sparen, und während sind Probleme zusammenführen können sie in vielen Fällen einfach verwaltet und behandelt werden.
Dann kommen wir zu Storyboards. Storyboards sind interessant. Auf der einen Seite sind sie extrem hilfreich und nützlich für einfache Apps und Entwickler, die neu auf der Plattform sind. Ich habe gerade eine UINavigationController -basierte App von NIBs in Storyboards konvertiert und dabei einige Zeit gespart (besonders bei Tabellenansichten, da man mit Storyboards Prototypenzellen nutzen kann).
Wenn Sie jedoch an einem großen Projekt mit mehreren Entwicklern arbeiten, bin ich nicht davon überzeugt, dass Storyboards von Vorteil sind. Es gibt, wie Sie sagen, große Probleme mit Zusammenführungskonflikten, und im Gegensatz zu NIBs ist es nicht einfach, sie zu lösen, da diese einzelne Storyboard-Datei alle Ihrer Anwendungsbenutzeroberfläche steuert.
Hier ist, was ich vorschlagen würde (und zögern Sie mich nicht zu ignorieren!) - wenn Sie gerade entwickeln Apps und Ihr Layout / UI ganz in Code tun, überlegen, ob NIBs Zeit sparen könnte. Sie mögen es nicht - sie sind nicht für jeden - aber es lohnt sich, darüber nachzudenken. Sie werden überrascht sein, wie viele große Apps tatsächlich NIBs verwenden (iPhoto, wie ich bereits erwähnt habe, aber auch viele integrierte Apps von Apple sowie viele beliebte Apps von großen Teams). Ich würde wahrscheinlich Storyboards nicht in Betracht ziehen, es sei denn, Sie wären ein einziger Entwickler, der an einer App mit relativ einfacher Navigation arbeitet. Das ist nichts mit Storyboards zu tun - ich liebe es, sie zu verwenden - sie sind einfach nicht wirklich für die Zusammenarbeit geeignet.
Jemand hat diesen Kommentar als Antwort auf Ihre Frage gepostet - ich wollte darüber sprechen:
Es gibt nichts, was Sie im Storyboard tun können, und Sie können nicht im Code tun. Objekte, Gestenerkenner, Segues, sogar Constraints - all das steht Ihnen zur Verfügung, um sie programmatisch zu erstellen
Dies ist technisch wahr, aber in Wirklichkeit gibt es Dinge in Storyboards / NIBs, die viel einfacher sind als Code. Ein gutes Beispiel dafür ist das automatische Layout. Während Sie Ihre Auto-Layout-Einschränkungen vollständig im Code verwalten können, ist die harte Realität, dass die automatische Layout-Darstellung von ASCII ist viel schwieriger zu arbeiten als die visuelle Darstellung, die Sie in IB erhalten. Das ist besonders wahr bei XCode 5, wo das automatische Layout in IB massiv verbessert wurde (ich kann es nicht zu sehr beschreiben, da es immer noch unter NDA steht, aber Apple redet öffentlich ein wenig über ändert sich hier ).
Für mich ist der einzige große Nachteil von Storyboards die langsame Ladezeit und die übliche Verzögerung beim Navigieren im Storyboard. Ich spreche nicht über 2-5 View Controller Apps. Ich spreche von 10 und mehr ...
Meine persönliche Vorliebe sind kleinere Storyboards, wenn ich sie wirklich benutzen muss (UITableView-Prototypzellen) oder einfach xibs.
Es ist nur eine Frage von ... in einfachem Code zu tun ... hast du genug Zeit auf deinen Händen? :) Normalerweise wird man davon nicht viel gewinnen.
Sie sollten diese Probleme in Ihrer Besprechung berücksichtigen:
Entwicklungszeit -
Offensichtlich ist die Arbeit mit dem xcode-UI-Designer viel schneller und einfacher zu erlernen, wenn neue Anwendungen von Grund auf neu erstellt werden. Auf programmatische Weise müssen Sie jede Elementeigenschaft definieren, die Sie festlegen möchten. Die Arbeit mit dem Storyboard wird den Entwicklungsprozess viel schneller machen.
Wiederverwendung von Codes -
Wenn Sie mit dem Storyboard arbeiten, müssen Sie Elemente der Benutzeroberfläche mit dem Controller verbinden, um zusätzlichen versteckten Code in der Storyboard-Datei hinzuzufügen. Die gleichen Stubs werden hinzugefügt, wenn Segmente zwischen Controllern erstellt werden. Durch diesen zusätzlichen versteckten Code wird es schwieriger, die Controller in anderen Apps wiederzuverwenden, die Sie erstellen. Wenn Sie eine Massenwiederverwendung Ihres Controller-Codes planen, ist die programmgesteuerte Erstellung der UI-Elemente besser geeignet.
Integration von Quellcode -
Das Auflösen von Konflikten ist eine häufige Sache, wenn mehrere Entwickler Änderungen an der Datei vornehmen. Das Erstellen und Ändern von UI-Elementen mit Storyboard-Zusatzänderungen wird der Storyboard-Datei hinzugefügt, wodurch die Konflikte manchmal schwierig gelöst werden können. Wenn Sie dagegen UI-Elemente programmatisch ändern, werden nur die Änderungen, die Sie vornehmen, der Controller-Datei hinzugefügt.
Tags und Links iphone ios xcode ipad cocoa-touch