iOS Benutzeroberflächen: Storyboards vs. NIBs vs. benutzerdefinierter Code

Ich höre oft, dass iOS-Entwickler eine Variante derselben Schlüsselfrage stellen:

Was ist der beste Weg, um eine Benutzeroberfläche in iOS zu entwickeln: über Storyboards, Schreibfedern oder Code?

Antworten auf diese Frage, explizit oder implizit, neigen dazu anzunehmen, dass es eine sich gegenseitig ausschließende Wahl gibt, die oft im Voraus vor der Entwicklung angesprochen wird.

Ich bin der Meinung, dass die Antwort stattdessen in Form einer oder mehrerer Gegenfragen erfolgen sollte.

Was ist das „beste“ Auto?

Lassen Sie mich mit einem Off-Topic-Beispiel erklären. Angenommen, ich möchte ein Auto kaufen und stelle Ihnen eine einfache Frage: „Was ist die beste Wahl?“

Können Sie wirklich antworten, indem Sie ein Modell oder sogar eine Marke vorschlagen? Wahrscheinlich nicht, es sei denn, Sie schlagen einen Ferrari vor. Stattdessen würden Sie wahrscheinlich mit ein paar anderen Fragen antworten, wie:

• Was ist Ihr Budget?
• Wie viele Plätze benötigen Sie?
• Interessieren Sie sich für den Kraftstoffverbrauch?
• Was hältst du von Sportwagen?

Es ist offensichtlich, dass es kein gutes oder schlechtes Auto gibt, wenn es nicht in einen richtigen Kontext gestellt wird — es gibt nur ein gutes oder schlechtes Auto, das auf spezifischen Bedürfnissen basiert.

Zurück zum Design der iOS-Benutzeroberfläche

Genau wie bei unserer Autoanfrage fehlt der Frage „Wie entwickle ich am besten eine iOS-Benutzeroberfläche?“ der Kontext. Und überraschenderweise muss die Antwort kein Catch-All-Fall sein.

Im Großen und Ganzen gibt es drei Arten von Ansätzen für das Design von Benutzeroberflächen, von denen jeder seine Vor- und Nachteile, seine Fans und Hasser hat:

• iOS Storyboards: Ein visuelles Werkzeug zum Auslegen mehrerer Anwendungsansichten und der Übergänge zwischen ihnen.
• NIBs (oder XIBs): Jede NIB-Datei entspricht einem einzelnen Ansichtselement und kann im Interface Builder angelegt werden, was sie auch zu einem visuellen Werkzeug macht. Beachten Sie, dass der Name „NIB“ von der Dateierweiterung abgeleitet ist (zuvor.nib und jetzt .xib, obwohl die alte Aussprache beibehalten hat).
• Benutzerdefinierter Code: dh keine GUI-Tools, sondern die gesamte benutzerdefinierte Positionierung, Animation usw. programmgesteuert.

Keine dieser Optionen ist universell besser als jede andere (trotz allem, was Sie vielleicht hören).

Storyboards sind beispielsweise die neueste Ergänzung des iOS UI Toolkit. Mir wurde gesagt, dass sie die Zukunft sind, dass sie Schreibfedern und benutzerdefinierte Code-Benutzeroberflächen ersetzen werden. Ich sehe Storyboards als nützliches Werkzeug, aber nicht so sehr als Ersatz als Ergänzung für Schreibfedern und benutzerdefinierten Code. Storyboards sind in einigen, aber nicht allen Situationen die richtige Wahl.

Warum sollten Sie sich statisch an eine einzige Option halten, wenn Sie sie alle (im selben Projekt) verwenden können, indem Sie den Mechanismus auswählen, der am besten zu dem jeweiligen Problem passt?

Dies ist eine Frage, die meiner Meinung nach auf einer höheren Ebene verallgemeinert werden kann und deren Antwort in meiner Liste der Softwareentwicklungsprinzipien einen hohen Stellenwert einnimmt: Es gibt keine universelle Sprache, kein Framework oder keine Technologie, die für jedes Softwareentwicklungsproblem die universelle beste Wahl ist. Das gleiche gilt für iOS UI-Design.

In diesem Tutorial zur iOS-Entwicklung werden wir jede dieser Methoden untersuchen und Anwendungsfälle vorstellen, in denen sie eingesetzt werden sollten und nicht, sowie Möglichkeiten, wie sie miteinander kombiniert werden können.

iOS Storyboards

Ein klassischer Anfängerfehler besteht darin, ein riesiges projektweites iOS Storyboard zu erstellen. Auch ich habe diesen Fehler gemacht, als ich anfing, mit Storyboards zu arbeiten (wahrscheinlich, weil es eine verlockende Route ist).

Wie der Name schon sagt, ist ein Storyboard ein Board mit einer Geschichte zu erzählen. Es sollte nicht verwendet werden, um nicht verwandte Geschichten in einem großen Band zu mischen. Ein Storyboard sollte Ansichtscontroller enthalten, die logisch miteinander verknüpft sind — was nicht jeden Ansichtscontroller bedeutet.

Zum Beispiel ist es sinnvoll, Storyboards zu verwenden, wenn:

• Eine Reihe von Ansichten für die Authentifizierung und Registrierung.
• Ein mehrstufiger Auftragseingabefluss.
• Ein Wizard-ähnlicher (d. H. Tutorial-) Ablauf.
• Ein Master-Detailsatz von Ansichten (z. B. Profillisten, Profildetails).

In der Zwischenzeit sollten große Storyboards vermieden werden, einschließlich Storyboards für einzelne Apps (es sei denn, die App ist relativ einfach). Bevor wir tiefer gehen, wollen wir sehen, warum.

Die Torheit großer iOS-Storyboards

Große Storyboards sind nicht nur schwer zu durchsuchen und zu pflegen, sondern erhöhen auch die Komplexität einer Teamumgebung: Wenn mehrere Entwickler gleichzeitig an derselben Storyboard-Datei arbeiten, sind Konflikte mit der Quellcodeverwaltung unvermeidlich. Und während ein Storyboard intern als Textdatei (eigentlich eine XML-Datei) dargestellt wird, ist das Zusammenführen normalerweise nicht trivial.

Wenn Entwickler Quellcode anzeigen, schreiben sie ihm semantische Bedeutung zu. Wenn sie also manuell zusammenführen, können sie beide Seiten eines Konflikts lesen und verstehen und entsprechend handeln. Ein Storyboard ist stattdessen eine XML-Datei, die von Xcode verwaltet wird, und die Bedeutung jeder Codezeile ist nicht immer leicht zu verstehen.

Nehmen wir ein sehr einfaches Beispiel: angenommen, zwei verschiedene Entwickler ändern die Position eines UILabel (mithilfe von Autolayout), und letzterer drückt seine Änderung aus und erzeugt einen Konflikt wie diesen (beachten Sie die widersprüchlichen id -Attribute):

<layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/></layoutGuides><layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/></layoutGuides>

Das id selbst gibt keinerlei Hinweis auf seine wahre Bedeutung, sodass Sie nichts zu tun haben. Die einzig sinnvolle Lösung besteht darin, eine der beiden Seiten des Konflikts zu wählen und die andere zu verwerfen. Wird es Nebenwirkungen geben? Wer weiß? Nicht du.

Um diese iOS-Schnittstellendesignprobleme zu lösen, wird empfohlen, mehrere Storyboards im selben Projekt zu verwenden.

Verwendung von Storyboards

Storyboards werden am besten mit mehreren miteinander verbundenen Ansichtscontrollern verwendet, da ihre Hauptvereinfachung darin besteht, zwischen Ansichtscontrollern zu wechseln. Bis zu einem gewissen Grad können sie als eine Komposition von Schreibfedern mit visuellen und funktionalen Flüssen zwischen Ansichtscontrollern betrachtet werden.

Neben der Vereinfachung des Navigationsflusses besteht ein weiterer deutlicher Vorteil darin, dass sie den Standardcode eliminieren, der zum Öffnen, Drücken, Präsentieren und Schließen von Ansichtscontrollern erforderlich ist. Darüber hinaus werden Ansichtscontroller automatisch zugewiesen, sodass alloc und init nicht manuell zugewiesen werden müssen.

Während Storyboards am besten für Szenarien mit mehreren Ansichtscontrollern verwendet werden, ist es aus drei Gründen auch vertretbar, ein Storyboard zu verwenden, wenn Sie mit einem einzelnen Tabellenansichtscontroller arbeiten:

• Die Fähigkeit, Tischzellenprototypen an Ort und Stelle zu entwerfen, hilft, die Teile zusammenzuhalten.
• Innerhalb des übergeordneten Tabellenansicht-Controllers können mehrere Zellvorlagen entworfen werden.
• Es ist möglich, statische Tabellenansichten zu erstellen (eine lang erwartete Ergänzung, die leider nur in Storyboards verfügbar ist).

Man könnte argumentieren, dass mehrere Zellvorlagen auch mit NIBs entworfen werden können. In Wahrheit ist dies nur eine Frage der Präferenz: Einige Entwickler bevorzugen es, alles an einem Ort zu haben, während es anderen egal ist.

Wann Sie iOS Storyboards nicht verwenden sollten

Einige Fälle:

• Die Ansicht hat ein kompliziertes oder dynamisches Layout, das am besten mit Code implementiert werden kann.
• Die Ansicht ist bereits mit NIBs oder Code implementiert.

In diesen Fällen können wir die Ansicht entweder aus dem Storyboard herauslassen oder in einen View Controller einbetten. Ersteres unterbricht den visuellen Fluss des Storyboards, hat jedoch keine negativen funktionalen oder entwicklungspolitischen Auswirkungen. Letzteres behält diesen visuellen Fluss bei, erfordert jedoch zusätzlichen Entwicklungsaufwand, da die Ansicht nicht in den Ansichtscontroller integriert ist: Sie ist nur als Komponente eingebettet, daher muss der Ansichtscontroller mit der Ansicht interagieren, anstatt sie zu implementieren.

Allgemeine Vor- und Nachteile

Nachdem wir nun ein Gefühl dafür haben, wann Storyboards im iOS-UI-Design nützlich sind, und bevor wir in diesem Tutorial zu NIBs übergehen, gehen wir deren allgemeine Vor- und Nachteile durch.

Pro: Performance

Intuitiv können Sie davon ausgehen, dass beim Laden eines Storyboards alle Ansichtscontroller sofort instanziiert werden. Glücklicherweise ist dies nur eine Abstraktion und gilt nicht für die tatsächliche Implementierung: Stattdessen wird nur der anfängliche View Controller erstellt, falls vorhanden. Die anderen Ansichtscontroller werden dynamisch instanziiert, entweder wenn ein Übergang ausgeführt wird oder manuell aus dem Code.

Pro: Prototypen

Storyboards vereinfachen das Prototyping und Verspotten von Benutzeroberflächen und -flows. Tatsächlich kann eine vollständige funktionierende Prototypanwendung mit Ansichten und Navigation mithilfe von Storyboards und nur wenigen Codezeilen einfach implementiert werden.

Con: Wiederverwendbarkeit

Beim Verschieben oder Kopieren sind iOS-Storyboards schlecht positioniert. Ein Storyboard muss zusammen mit allen abhängigen View Controllern verschoben werden. Mit anderen Worten, ein einzelner View Controller kann nicht einzeln extrahiert und an anderer Stelle als einzelne unabhängige Entität wiederverwendet werden.

Con: Datenfluss

Beim Übergang einer App müssen häufig Daten zwischen Ansichtscontrollern übergeben werden. Der visuelle Fluss des Storyboards ist in diesem Fall jedoch unterbrochen, da im Interface Builder keine Spur davon vorhanden ist. Storyboards kümmern sich um den Fluss zwischen Ansichtscontrollern, nicht jedoch um den Datenfluss. Daher muss der Zielcontroller mit Code konfiguriert werden, der die visuelle Erfahrung überschreibt.

In solchen Fällen müssen wir uns auf ein prepareForSegue:sender mit einem if/else-if-Skelett wie folgt verlassen:

- (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { NSString *identifier = ; if ("segue_name_1"]) { MyViewController *vc = (MyViewController *) ; ; } else if ("segue_name_2"]) { ... } else if ...}

Ich finde diesen Ansatz fehleranfällig und unnötig ausführlich.

NIBs

NIBs sind die alte (er) Art, iOS-Interface-Design durchzuführen.

In diesem Fall bedeutet „alt“ nicht „schlecht“, „veraltet“ oder „veraltet“. Tatsächlich ist es wichtig zu verstehen, dass iOS-Storyboards kein universeller Ersatz für Schreibfedern sind.

Mit NIBs kann jede beliebige Ansicht entworfen werden, die der Entwickler dann nach Bedarf an einen View Controller anhängen kann.

Wenn wir objektorientiertes Design auf unsere Benutzeroberflächen anwenden, ist es sinnvoll, die Ansicht eines View Controllers in separate Module zu unterteilen, die jeweils als Ansicht mit einer eigenen NIB-Datei (oder mit mehreren Modulen) implementiert sind in derselben Datei gruppiert). Der klare Vorteil dieses Ansatzes besteht darin, dass jede Komponente einfacher zu entwickeln, zu testen und zu debuggen ist.

NIBs teilen die Probleme mit Mergekonflikten, die wir bei Storyboards gesehen haben, jedoch in geringerem Maße, da NIB-Dateien in kleinerem Maßstab ausgeführt werden.

Verwendung von Schreibfedern für das iOS-UI-Design

Eine Teilmenge aller Anwendungsfälle wäre:

• Modale Ansichten
• Einfache Anmelde- und Registrierungsansichten
• Einstellungen
• Popup-Fenster
• Wiederverwendbare Ansichtsvorlagen
• Wiederverwendbare Tabellenzellenvorlagen

Inzwischen…

Wenn Sie keine Schreibfedern verwenden

Sie sollten die Verwendung von Schreibfedern für:

• Ansichten mit dynamischem Inhalt, bei denen sich das Layout je nach Inhalt erheblich ändert.
• Ansichten, die von Natur aus im Interface Builder nicht einfach gestaltet werden können.
• View-Controller mit komplizierten Übergängen, die mit Storyboarding vereinfacht werden könnten.

Allgemeine Vor- und Nachteile

Lassen Sie uns allgemeiner die Vor- und Nachteile der Verwendung von Schreibfedern durchgehen.

Pro: Wiederverwendbarkeit

Schreibfedern sind praktisch, wenn dasselbe Layout für mehrere Klassen freigegeben ist.

Als einfacher Anwendungsfall könnte eine Ansichtsvorlage mit einem Benutzernamen und einem Kennworttextfeld mit den hypothetischen Ansichten TTLoginView und TTSignupView implementiert werden, die beide von derselben FEDER stammen könnten. Das TTLoginView müsste das Passwortfeld ausblenden, und beide müssten entsprechende statische Beschriftungen angeben (z. B. ‚Geben Sie Ihren Benutzernamen ein‘ vs ‚Geben Sie Ihr Passwort ein‘), aber die Beschriftungen hätten die gleiche Grundfunktionalität und ähnliche Layouts.

Pro & Con: Leistung

Schreibfedern werden träge geladen, sodass sie erst dann Speicher verwenden, wenn sie es müssen. Dies kann zwar ein Vorteil sein, aber der verzögerte Ladevorgang hat eine Latenzzeit, was ihn auch zu einem Nachteil macht.

Benutzerdefinierter iOS-Code (programmatische Benutzeroberflächen)

Jedes iOS-Schnittstellendesign, das mit Storyboards und Schreibfedern erstellt werden kann, kann auch mit Rohcode implementiert werden (es gab natürlich eine Zeit, in der Entwickler nicht den Luxus eines so umfangreichen Tools hatten).

Was mit Schreibfedern und Storyboards nicht möglich ist, lässt sich vielleicht noch viel wichtiger immer mit Code umsetzen — vorausgesetzt natürlich, es ist technisch machbar. Eine andere Sichtweise ist, dass NIBs und Storyboards mit Code implementiert werden, sodass ihre Funktionalität natürlich eine Teilmenge ist. Lassen Sie uns direkt in die Vor- und Nachteile springen.

Pro: Unter der Haube

Der größte Vorteil der programmgesteuerten Erstellung einer iOS-Benutzeroberfläche: Wenn Sie wissen, wie man eine Benutzeroberfläche codiert, wissen Sie, was unter der Haube passiert, während dies nicht unbedingt für Schreibfedern und Storyboards gilt.

Zum Vergleich: Ein Taschenrechner ist ein nützliches Werkzeug. Aber es ist keine schlechte Sache zu wissen, wie man Berechnungen manuell durchführt.

Dies ist nicht auf iOS beschränkt, sondern auf jedes Visual RAD-Tool (z. B. Visual Studio und Delphi, um nur einige zu nennen). Visuelle HTML-RAD-Umgebungen stellen einen typischen Grenzfall dar: Sie werden verwendet, um (oft schlecht geschriebenen) Code zu generieren, wobei behauptet wird, dass keine HTML-Kenntnisse erforderlich sind und dass alles visuell erledigt werden kann. Aber kein Webentwickler würde eine Webseite implementieren, ohne sich die Hände schmutzig zu machen: Sie wissen, dass der manuelle Umgang mit dem rohen HTML und CSS zu mehr modularem, effizienterem Code führt.

Wenn Sie also die Codierung von iOS-Benutzeroberflächen beherrschen, haben Sie mehr Kontrolle und ein besseres Bewusstsein dafür, wie diese Teile zusammenpassen, was Ihre Obergrenze als Entwickler erhöht.

Pro: Wenn Code die einzige Option ist

Es gibt auch Fälle, in denen benutzerdefinierter iOS-Code die einzige Option für das UI-Design ist. Dynamische Layouts, bei denen Ansichtselemente verschoben werden und der Fluss oder das Layout basierend auf dem Inhalt erheblich angepasst wird, sind typische Beispiele.

Profi: Zusammenführungskonflikte

Während NIBs und Storyboards erheblich unter Zusammenführungskonflikten litten, hat Code nicht den gleichen Fehler. Der gesamte Code hat eine semantische Bedeutung, sodass die Lösung von Konflikten nicht schwieriger als üblich ist.

Con: Prototyping

Es ist schwierig herauszufinden, wie ein Layout aussehen wird, bis Sie es in Aktion gesehen haben. Außerdem können Sie Ansichten und Steuerelemente nicht visuell positionieren, sodass das Übersetzen von Layoutspezifikationen in eine greifbare Ansicht im Vergleich zu Schreibfedern und Storyboards, die Ihnen eine sofortige Vorschau auf das Rendern der Dinge geben, viel länger dauern kann.

Con: Refactoring

Das Refactoring von Code, der vor langer Zeit oder von jemand anderem geschrieben wurde, wird ebenfalls viel komplizierter: Wenn Elemente mit benutzerdefinierten Methoden und magischen Zahlen positioniert und animiert werden, können Debugging-Sitzungen mühsam werden.

Pro: Leistung

In Bezug auf die Leistung unterliegen Storyboards und Schreibfedern dem Overhead des Ladens und Analysierens. und am Ende werden sie indirekt in Code übersetzt. Unnötig zu erwähnen, dass dies bei Code-Benutzeroberflächen nicht der Fall ist.

Profi: Wiederverwendbarkeit

Jede programmgesteuert implementierte Ansicht kann wiederverwendbar gestaltet werden. Sehen wir uns einige Anwendungsfälle an:

• Zwei oder mehr Ansichten haben ein gemeinsames Verhalten, unterscheiden sich jedoch geringfügig. Eine Basisklasse und zwei Unterklassen lösen das Problem elegant.
• Ein Projekt muss gegabelt werden, um eine einzige Codebasis zu erstellen, aber zwei (oder mehr) verschiedene Anwendungen mit jeweils spezifischen Anpassungen zu generieren.

Der gleiche UI-Designprozess wäre mit NIBs und Storyboards viel komplizierter. Vorlagendateien erlauben keine Vererbung, und die möglichen Lösungen sind auf Folgendes beschränkt:

• Duplizieren Sie die FEDER- und Storyboard-Dateien. Danach haben sie getrennte Leben und keine Beziehung zur Originaldatei.
• Überschreiben Sie das Aussehen und Verhalten mit Code, der in einfachen Fällen funktionieren kann, in anderen jedoch zu erheblichen Komplikationen führen kann. Schwere Überschreibungen mit Code können auch visuelles Design unbrauchbar machen und sich zu einer ständigen Quelle von Kopfschmerzen entwickeln, z., wenn ein bestimmtes Steuerelement in eine Richtung im Interface Builder angezeigt wird, aber völlig anders aussieht, wenn die App ausgeführt wird.

Wann Code zu verwenden ist

Es ist oft ein guter Aufruf, benutzerdefinierten Code für das Design der iOS-Benutzeroberfläche zu verwenden, wenn Sie:

• Dynamische Layouts.
• Ansichten mit Effekten wie abgerundeten Ecken, Schatten usw.
• Jeder Fall, in dem die Verwendung von Schreibfedern und Storyboards kompliziert oder nicht durchführbar ist.

Wenn kein Code verwendet werden soll

Im Allgemeinen können Code-Benutzeroberflächen immer verwendet werden. Sie sind selten eine schlechte Idee, also würde ich hier eine setzen.

Obwohl NIBs und Storyboards einige Vorteile mit sich bringen, gibt es meiner Meinung nach keinen vernünftigen Nachteil, den ich in eine Liste aufnehmen würde, um die Verwendung von Code zu verhindern (außer vielleicht Faulheit).

Ein Projekt, mehrere Tools

Storyboards, NIBs und Code sind drei verschiedene Tools zum Erstellen einer iOS-Benutzeroberfläche. Wir haben Glück, sie zu haben. Fanatiker programmatischer Benutzeroberflächen werden die beiden anderen Optionen wahrscheinlich nicht berücksichtigen: Mit Code können Sie alles tun, was technisch möglich ist, während die Alternativen ihre Grenzen haben. Für den Rest der Entwickler da draußen bietet das Xcode Army Knife drei Tools, die alle gleichzeitig im selben Projekt effektiv verwendet werden können.

Wie, fragst du? Wie du willst. Hier sind einige mögliche Ansätze:

• Gruppieren Sie alle zugehörigen Bildschirme in separate Gruppen und implementieren Sie jede Gruppe mit einem eigenen Storyboard.
• Entwerfen Sie nicht wiederverwendbare Tabellenzellen an Ort und Stelle mit einem Storyboard innerhalb des Tabellenansicht-Controllers.
• Entwerfen Sie wiederverwendbare Tabellenzellen in Schreibfedern, um die Wiederverwendung zu fördern und Wiederholungen zu vermeiden.
• Entwerfen Sie benutzerdefinierte Ansichten, Steuerelemente und Zwischenobjekte mithilfe von Schreibfedern.
• Verwenden Sie Code für hochdynamische Ansichten und allgemeiner für Ansichten, die nicht einfach über Storyboards und Schreibfedern implementiert werden können, während Sie Ansichtsübergänge in einem Storyboard anzeigen.

Um zu schließen, schauen wir uns ein letztes Beispiel an, das alles zusammenhält.

Ein einfacher Anwendungsfall

Angenommen, wir möchten eine grundlegende Messaging-App mit verschiedenen Ansichten entwickeln:

• Eine Liste der verfolgten Freunde (mit einer wiederverwendbaren Zellvorlage, um die Benutzeroberfläche für zukünftige Listen konsistent zu halten).
• Eine Profildetailansicht, die in separate Abschnitte unterteilt ist (einschließlich Profilinformationen, Statistiken und einer Symbolleiste).
• Eine Liste von Nachrichten, die an einen Freund gesendet und von ihm empfangen wurden.
• Ein neues Nachrichtenformular.
• Eine Tag-Cloud-Ansicht, in der die verschiedenen Tags angezeigt werden, die in Benutzernachrichten verwendet werden.

Außerdem sollen die Ansichten wie folgt fließen:

• Wenn Sie auf ein Element in der Liste der verfolgten Freunde klicken, werden die Profildetails des entsprechenden Freundes angezeigt.
• Die Profildetails zeigen den Profilnamen, die Adresse, Statistiken, eine kurze Liste der neuesten Nachrichten und eine Symbolleiste.

Um diese iOS-App zu implementieren, werden alle drei unserer UI-Tools nützlich sein, da wir sie verwenden können:

• Ein Storyboard mit vier View-Controllern (Liste, Details, Liste der Nachrichten und neues Nachrichtenformular).
• Eine separate NIB-Datei für die wiederverwendbare Vorlage für Profilistenzellen.
• Drei separate NIB-Dateien für die Profildetailansicht, eine für jeden der separaten Abschnitte, aus denen sie besteht (Profildetails, Statistiken, letzte drei Nachrichten), um eine bessere Wartbarkeit zu ermöglichen. Diese Schreibfedern werden als Ansichten instanziiert und dann dem Ansichtscontroller hinzugefügt.
• Benutzerdefinierter Code für die Tag-Cloud-Ansicht. Diese Ansicht ist ein typisches Beispiel für eine Ansicht, die im Interface Builder weder über StoryBoards noch über Schreibfedern entworfen werden kann. Stattdessen wird es vollständig durch Code implementiert. Um den visuellen Fluss des Storyboards beizubehalten, fügen wir dem Storyboard einen leeren Ansichtscontroller hinzu, implementieren die Tag Cloud-Ansicht als eigenständige Ansicht und fügen die Ansicht programmgesteuert zum Ansichtscontroller hinzu. Natürlich könnte die Ansicht auch im View Controller und nicht als eigenständige Ansicht implementiert werden, aber wir halten sie zur besseren Wiederverwendung getrennt.

Ein wirklich einfaches Modell könnte so aussehen:

Damit haben wir den grundlegenden Aufbau einer einigermaßen ausgefeilten iOS-App skizziert, deren Kernansichten unsere drei primären Ansätze für das UI-Design miteinander verbinden. Denken Sie daran: Es gibt keine binäre Entscheidung, da jedes Tool seine Stärken und Schwächen hat.

Einpacken

Wie in diesem Turtorial untersucht, Storyboards Fügen Sie eine spürbare Vereinfachung iOS UI-Design und visuellen Fluss. Sie beseitigen auch Boilerplate-Code; aber all dies hat seinen Preis, bezahlt in Flexibilität. Schreibfedern bieten mehr Flexibilität, indem sie sich auf eine einzelne Ansicht konzentrieren, jedoch ohne visuellen Fluss. Die flexibelste Lösung ist natürlich Code, der eher unfreundlich und von Natur aus nicht visuell ist.

Wenn Sie dieser Artikel fasziniert hat, empfehle ich Ihnen dringend, sich die großartige Debatte von Ray Wenderlich anzusehen, die 55 Minuten lang gut mit einer Diskussion über Schreibfedern, Storyboards und Code-UIS verbracht wurde.

Abschließend möchte ich eines betonen: Vermeiden Sie um jeden Preis die Verwendung des falschen iOS-UI-Design-Tools. Wenn eine Ansicht nicht mit einem Storyboard entworfen werden kann oder wenn sie mit NIBs oder Code auf einfachere Weise implementiert werden kann, verwenden Sie kein Storyboard. Wenn eine Ansicht nicht mit Schreibfedern gestaltet werden kann, verwenden Sie keine Schreibfedern. Diese Regeln sind zwar einfach, tragen jedoch wesentlich zu Ihrer Ausbildung als Entwickler bei.