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

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

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

Antworten auf diese Frage, ob explizit oder implizit, neigen dazu anzunehmen, dass eine sich gegenseitig ausschließende Entscheidung getroffen werden muss, 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 es mich an einem Off-Topic-Beispiel erklären. Angenommen, ich möchte ein Auto kaufen, und ich 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 zum Beispiel:

• Was ist Ihr Budget?
• Wie viele Sitzplätze benötigen Sie?
• Ist dir der Spritverbrauch egal?
• Wie stehst du zu Sportwagen?

Es ist offensichtlich, dass es kein gutes oder schlechtes Auto gibt, es sei denn, es wird in den richtigen Kontext gestellt – es gibt nur ein gutes oder schlechtes Auto, das auf bestimmten Bedürfnissen basiert.

Zurück zum Design der iOS-Benutzeroberfläche

Genau wie bei unserer Autoanfrage fehlt der Frage „Was ist der beste Weg, um eine iOS-Benutzeroberfläche zu entwickeln“ der Kontext. Und überraschenderweise muss die Antwort kein Catch-all-Case sein.

Im Großen und Ganzen gibt es drei Arten von Ansätzen für das Design von Benutzeroberflächen, die Sie verfolgen können, jeder mit seinen Vor- und Nachteilen, seinen Fans und Hassern:

• iOS-Storyboards : Ein visuelles Tool zum Anordnen 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, wodurch es auch zu einem visuellen Werkzeug wird. Beachten Sie, dass der Name „NIB“ von der Dateierweiterung abgeleitet ist (früher .nib und jetzt .xib, obwohl die alte Aussprache beibehalten wurde).
• Benutzerdefinierter Code : dh keine GUI-Tools, sondern vielmehr die programmgesteuerte Handhabung aller benutzerdefinierten Positionierungen, Animationen usw.

Keine dieser Optionen ist allgemein besser als andere (ungeachtet dessen, was Sie vielleicht hören).

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

Warum sollten Sie sich außerdem statisch an eine einzige Option halten, wenn Sie sie alle (im selben Projekt) verwenden und den Mechanismus auswählen können, 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 ganz oben steht: Es gibt keine universelle Sprache, kein Framework oder keine Technologie, die für jeden die universell beste Wahl ist Softwareentwicklungsproblem. Dasselbe gilt für das Design der iOS-Benutzeroberfläche.

In diesem iOS-Entwicklungstutorial werden wir jede dieser Methoden untersuchen und Anwendungsfälle vorstellen, in denen sie verwendet 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 ein verlockender Weg ist).

Wie der Name schon sagt, ist ein Storyboard ein Board mit einer Geschichte, die erzählt werden soll . Es sollte nicht verwendet werden, um nicht zusammenhängende Geschichten in einem großen Band zu mischen. Ein Storyboard sollte View-Controller enthalten, die logisch miteinander verbunden sind – was nicht jeden View-Controller bedeutet.

Sinnvoll ist der Einsatz von Storyboards beispielsweise bei der Handhabung von:

• Eine Reihe von Ansichten für die Authentifizierung und Registrierung.
• Ein mehrstufiger Auftragseingangsablauf.
• Ein assistentenähnlicher (dh Tutorial-) Ablauf.
• Ein Master-Detail-Satz von Ansichten (z. B. Profillisten, Profildetails).

In der Zwischenzeit sollten große Storyboards vermieden werden, einschließlich einzelner App-weiter Storyboards (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 schwierig zu durchsuchen und zu warten, sondern fügen einer Teamumgebung auch eine Ebene der Komplexität hinzu: Wenn mehrere Entwickler gleichzeitig an derselben Storyboard-Datei arbeiten, sind Konflikte bei 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 betrachten, schreiben sie ihm eine semantische Bedeutung zu. Beim manuellen Zusammenführen können sie also beide Seiten eines Konflikts lesen und verstehen und entsprechend handeln. Ein Storyboard hingegen ist eine von Xcode verwaltete XML-Datei, und die Bedeutung jeder Codezeile ist nicht immer leicht zu verstehen.

Nehmen wir ein sehr einfaches Beispiel: Nehmen wir an, zwei verschiedene Entwickler ändern die Position eines UILabel (unter Verwendung von Autolayout), und letzterer drückt seine Änderung, was zu einem Konflikt wie diesem führt (beachten Sie die widersprüchlichen id -Attribute):

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

Die id selbst gibt keinerlei Hinweis auf ihre wahre Bedeutung, Sie müssen also nicht damit arbeiten. 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 Probleme beim Design der iOS-Schnittstelle zu lösen, ist die Verwendung mehrerer Storyboards im selben Projekt der empfohlene Ansatz.

Wann man Storyboards verwendet

Storyboards werden am besten mit mehreren miteinander verbundenen Ansichtscontrollern verwendet, da ihre Hauptvereinfachung im Übergang zwischen Ansichtscontrollern liegt. Bis zu einem gewissen Grad können sie als eine Zusammensetzung von NIBs mit visuellen und funktionalen Flüssen zwischen Ansichtscontrollern betrachtet werden.

Neben der Vereinfachung des Navigationsflusses besteht ein weiterer entscheidender Vorteil darin, dass sie den Boilerplate-Code eliminieren, der zum Öffnen, Drücken, Präsentieren und Schließen von Ansichtscontrollern erforderlich ist. Darüber hinaus werden Ansichtscontroller automatisch zugewiesen, sodass keine manuelle alloc und init erforderlich ist.

Obwohl Storyboards am besten für Szenarien mit mehreren View-Controllern verwendet werden, ist es aus drei Gründen auch vertretbar, ein Storyboard zu verwenden, wenn mit einem einzelnen Table-View-Controller gearbeitet wird:

• Die Möglichkeit, Tischzellen-Prototypen vor Ort zu entwerfen, hilft, die Teile zusammenzuhalten.
• Innerhalb des Controllers für übergeordnete Tabellenansichten können mehrere Zellenvorlagen 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 unter Verwendung von NIBs entworfen werden können. In Wahrheit ist dies nur eine Frage der Vorlieben: Einige Entwickler ziehen es vor, alles an einem Ort zu haben, während andere sich nicht darum kümmern.

Wann Sie iOS-Storyboards nicht verwenden sollten

Ein paar Fälle:

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

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

Allgemeine Vor- und Nachteile

Nachdem wir nun ein Gespür dafür haben, wann Storyboards beim Design der iOS-Benutzeroberfläche nützlich sind, und bevor wir in diesem Tutorial zu NIBs übergehen, gehen wir ihre allgemeinen Vor- und Nachteile durch.

Pro: Leistung

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

Pro: Prototypen

Storyboards vereinfachen das Prototyping und Mockup von Benutzeroberflächen und Abläufen. Tatsächlich kann eine vollständig funktionierende Prototypanwendung mit Ansichten und Navigation einfach mithilfe von Storyboards und nur wenigen Codezeilen implementiert werden.

Nachteil: Wiederverwendbarkeit

Beim Verschieben oder Kopieren sind iOS Storyboards schlecht aufgestellt. Ein Storyboard muss zusammen mit allen seinen abhängigen View-Controllern verschoben werden. Mit anderen Worten, ein einzelner Ansichtscontroller kann nicht einzeln extrahiert und an anderer Stelle als einzelne unabhängige Entität wiederverwendet werden. es ist vom Rest des Storyboards abhängig, um zu funktionieren.

Nachteil: Datenfluss

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

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

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

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

NIBs

NIBs sind die alte (ere) Art, iOS-Schnittstellendesign 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 NIBs sind; sie vereinfachen in manchen Fällen lediglich die UI-Implementierung.

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

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

NIBs teilen die Konfliktprobleme beim Zusammenführen, die wir bei Storyboards gesehen haben, jedoch in geringerem Maße, da NIB-Dateien in einem kleineren Maßstab arbeiten.

Wann sollten NIBs für das iOS-UI-Design verwendet werden?

Eine Teilmenge aller Anwendungsfälle wäre:

• Modale Ansichten
• Einfache Anmelde- und Registrierungsansichten
• Einstellungen
• Popup-Fenster
• Wiederverwendbare Ansichtsvorlagen
• Wiederverwendbare Vorlagen für Tabellenzellen

Inzwischen…

Wann man NIBs nicht verwenden sollte

Sie sollten die Verwendung von NIBs vermeiden für:

• Ansichten mit dynamischen Inhalten, bei denen sich das Layout je nach Inhalt stark ändert.
• Ansichten, die naturgemäß nicht einfach im Interface Builder gestaltet werden können.
• Zeigen Sie Controller mit komplizierten Übergängen an, die mit Storyboarding vereinfacht werden könnten.

Allgemeine Vor- und Nachteile

Lassen Sie uns ganz allgemein die Vor- und Nachteile der Verwendung von NIBs durchgehen.

Pro: Wiederverwendbarkeit

NIBs sind praktisch, wenn dasselbe Layout von mehreren Klassen gemeinsam genutzt wird.

Als einfacher Anwendungsfall könnte eine Ansichtsvorlage, die einen Benutzernamen und ein Passwort-Textfeld enthält, mit den hypothetischen Ansichten TTLoginView und TTSignupView implementiert werden, die beide von derselben NIB stammen könnten. Die TTLoginView müsste das Passwortfeld ausblenden, und beide müssten entsprechende statische Bezeichnungen angeben (z. B. „Geben Sie Ihren Benutzernamen ein“ vs. „Geben Sie Ihr Passwort ein“), aber die Bezeichnungen hätten dieselbe grundlegende Funktionalität und ähnliche Layouts.

Pro & Contra: Leistung

NIBs werden träge geladen, sodass sie keinen Speicher verwenden, bis sie müssen. Dies kann zwar ein Vorteil sein, aber der verzögerte Ladevorgang ist mit einer Latenz verbunden, was ihn auch zu einem Nachteil macht.

Benutzerdefinierter iOS-Code (programmatische Benutzeroberflächen)

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

Vielleicht noch wichtiger ist, dass das, was mit NIBs und Storyboards nicht möglich ist, immer mit Code implementiert werden kann – vorausgesetzt natürlich, dass es technisch machbar ist. Eine andere Sichtweise ist, dass NIBs und Storyboards mit Code implementiert werden, sodass ihre Funktionalität natürlich eine Teilmenge ist. Kommen wir direkt zu den Vor- und Nachteilen.

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 auf NIBs und Storyboards zutrifft.

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

Dies ist nicht auf iOS beschränkt, sondern auf jedes visuelle RAD-Tool (z. B. Visual Studio und Delphi, um nur einige zu nennen). Visuelles 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 die manuelle Handhabung des rohen HTML und CSS zu modularerem, effizienterem Code führt.

Die Beherrschung der Codierung von iOS-Benutzeroberflächen gibt Ihnen also mehr Kontrolle darüber und ein größeres 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. Typische Beispiele sind dynamische Layouts, bei denen Ansichtselemente verschoben werden und sich der Fluss oder das Layout je nach Inhalt erheblich anpasst.

Pro: Konflikte zusammenführen

Während NIBs und Storyboards erheblich unter Zusammenführungskonflikten litten, hat Code nicht denselben Fehler. Der gesamte Code hat eine semantische Bedeutung, daher ist das Lösen von Konflikten nicht schwieriger als gewöhnlich.

Nachteil: Prototyping

Es ist schwierig herauszufinden, wie ein Layout aussehen wird, bis Sie es in Aktion gesehen haben. Darüber hinaus können Sie Ansichten und Steuerelemente nicht visuell positionieren, sodass das Übersetzen von Layoutspezifikationen in eine konkrete Ansicht viel länger dauern kann als bei NIBs und Storyboards, die Ihnen eine sofortige Vorschau darauf geben, wie die Dinge gerendert werden.

Nachteil: 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 NIBs dem Overhead des Ladens und Analysierens; und am Ende werden sie indirekt in Code übersetzt. Unnötig zu erwähnen, dass dies bei Code-erstellten UIs nicht passiert.

Pro: Wiederverwendbarkeit

Jede programmgesteuert implementierte Ansicht kann wiederverwendbar entworfen werden. Sehen wir uns ein paar 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, mit dem Ziel, eine einzige Codebasis zu erstellen, aber zwei (oder mehr) verschiedene Anwendungen mit jeweils spezifischen Anpassungen zu generieren.

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

• Duplizieren Sie die NIB- 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. Starke Überschreibungen mit Code können auch das visuelle Design unbrauchbar machen und sich zu einer ständigen Quelle von Kopfschmerzen entwickeln, z. B. wenn ein bestimmtes Steuerelement im Interface Builder eine Richtung anzeigt, aber völlig anders aussieht, wenn die App läuft.

Wann Code verwendet werden sollte

Es ist oft eine gute Idee, benutzerdefinierten Code für das Design der iOS-Benutzeroberfläche zu verwenden, wenn Sie Folgendes haben:

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

Wann Sie Code nicht verwenden sollten

Im Allgemeinen können immer Code-erstellte UIs verwendet werden. Sie sind selten eine schlechte Idee, also würde ich eine setzen Hier.

Obwohl NIBs und Storyboards einige Vorteile auf den Tisch 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 das Glück, sie zu haben. Fanatiker programmatischer UIs werden die anderen beiden Optionen wahrscheinlich nicht in Betracht ziehen: Code lässt 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-Armeemesser drei Tools, die alle gleichzeitig im selben Projekt effektiv verwendet werden können.

Wie, fragen Sie? Wie immer du magst. 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 direkt mit einem Storyboard im Tabellenansichts-Controller.
• Entwerfen Sie wiederverwendbare Tabellenzellen in NIBs, um die Wiederverwendung zu fördern und Wiederholungen zu vermeiden, aber laden Sie diese NIBs durch benutzerdefinierten Code.
• Entwerfen Sie mithilfe von NIBs benutzerdefinierte Ansichten, Steuerelemente und Zwischenobjekte.
• Verwenden Sie Code für hochdynamische Ansichten und allgemeiner für Ansichten, die nicht einfach über Storyboards und NIBs implementiert werden können, während Sie Ansichtsübergänge in einem Storyboard unterbringen.

Schauen wir uns zum Abschluss noch ein letztes Beispiel an, das alles zusammenhält.

Ein einfacher Anwendungsfall

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

• Eine Liste verfolgter Freunde (mit einer wiederverwendbaren Zellenvorlage, um die Benutzeroberfläche in zukünftigen 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, die die verschiedenen Tags anzeigt, die in Benutzernachrichten verwendet werden, wobei die Größe jedes Tags proportional zur Häufigkeit ist, mit der es verwendet wurde.

Außerdem möchten wir, dass die Ansichten wie folgt fließen:

• Durch Klicken auf ein Element in der Liste der verfolgten Freunde 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, sind alle drei unserer UI-Tools praktisch, da wir sie verwenden können:

• Ein Storyboard mit vier Ansichtssteuerelementen (Liste, Details, Nachrichtenliste und Formular für neue Nachrichten).
• Eine separate NIB-Datei für die Zellenvorlage für die wiederverwendbare Profilliste.
• Drei separate NIB-Dateien für die Profildetailansicht, eine für jeden der separaten Abschnitte, aus denen sie besteht (Profildetails, Statistiken, die letzten drei Nachrichten), um eine bessere Wartbarkeit zu ermöglichen. Diese NIBs 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 nicht im Interface Builder entworfen werden kann, weder durch StoryBoards noch durch NIBs. 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 dem Ansichtscontroller hinzu. Natürlich könnte die Ansicht auch innerhalb des View-Controllers anstatt als eigenständige Ansicht implementiert werden, aber wir halten sie zur besseren Wiederverwendung getrennt.

Ein wirklich einfaches Mock-up könnte so aussehen:

Damit haben wir den grundlegenden Aufbau einer einigermaßen anspruchsvollen 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 Tutorial untersucht, fügen Storyboards dem Design und dem visuellen Fluss der iOS-Benutzeroberfläche eine spürbare Vereinfachung hinzu. Sie eliminieren auch Boilerplate-Code; All dies hat jedoch seinen Preis, der in Flexibilität bezahlt wird. NIBs hingegen 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 anzuschauen, 55 Minuten, die gut angelegt sind für eine Diskussion über NIBs, Storyboards und Code-erstellte UIS.

Abschließend möchte ich eines betonen: Vermeiden Sie unbedingt das unsachgemäße iOS-UI-Design-Tool . Wenn eine Ansicht nicht mit einem Storyboard gestaltet oder mit NIBs oder Code auf einfachere Weise implementiert werden kann, verwenden Sie kein Storyboard. Wenn eine Ansicht nicht mit NIBs gestaltet werden kann, verwenden Sie keine NIBs. Diese Regeln sind zwar einfach, werden aber in Ihrer Ausbildung als Entwickler einen großen Beitrag leisten.