Warum ich Interface Builder nicht verwende – Sam Soffes
Gepostet am
Für die iOS-Entwicklung verwende ich Interface Builder nicht. Ich habe seit iOS 2.0 nicht mehr absichtlich eine NIB verwendet (wenn ich NIB sage, meine ich die Interface Builder-Datei, nicht das spezifische Format). In der Vergangenheit habe ich mit einigen Leuten zusammengearbeitet, denen die Verwendung von Interface Builder sehr gut gefallen hat. Das ist ein Streit, den ich immer wieder hatte.
Anstatt gedankenlos über die eine oder andere Seite zu streiten, gehe ich hier auf Punkte ein, wenn ich versuche, jemanden für mich zu gewinnen.
Explizit statt implizit wählen
Die Entscheidung, explizit zu sein, ist für mich der Hauptgrund, Dinge stattdessen im Code zu erledigen. Wenn jemand, der neu im Team ist, eine Ansicht oder einen Ansichtscontroller öffnet, kann er sofort sehen, wo sich alles befindet, und muss sich nicht fragen, ob diese Datei eine NIB hat.
Ich habe unzählige Stunden damit verbracht, nach der Ursache eines Fehlers zu suchen, nur um herauszufinden, dass es sich um ein Kontrollkästchen in einem der halben Dutzend Inspektoren im Interface Builder handelt. Wenn es sich um einen Code handelte, ist es einfach, einen Blick auf den Ansichtscode zu werfen und die Ursache des Problems viel schneller zu erkennen.
Enge Kopplung
Es ist viel schwieriger, Interface Builder für wiederverwendbare Ansichten zu verwenden. Ich erstelle ständig kleine Ansichten und verwende sie überall wieder. Das ist sozusagen der Sinn der Arbeit in einer objektorientierten Umgebung. Wenn Sie Interface Builder verwenden und über Steckdosen verfügen und bei der zweiten Verwendung vergessen, die Steckdose anzuschließen, kommt es zur Laufzeit zum Absturz. Das ist schrecklich. Dies führt zu einer völlig neuen Klasse von Fehlern.
Jetzt haben wir dieses Ding, das einfach abstürzt, weil wir Interface Builder statt Code verwenden. Wenn es im Code genau dasselbe wäre, würde es nicht abstürzen. Schlimmer noch: Der Compiler kann dies für Sie überprüfen.
Ganz zu schweigen davon, dass Ihre NIBs nur ein Haufen unsichtbarer Kästchen sind, wenn Sie viele benutzerdefinierte Ansichten verwenden. Jetzt haben Sie also diese enge Kopplung, die noch schwieriger zu handhaben ist, wenn Sie sie nur im Code auslegen würden.
Haben Sie jemals auf einen Code gestarrt und sich gefragt, warum er nicht funktioniert, und dann festgestellt, dass Sie die Steckdose oder Aktion nicht angeschlossen haben? Ich hasse das.
Mit anderen zusammenarbeiten
Hatten Sie jemals einen Zusammenführungskonflikt in einer NIB? Es ist das Schlimmste. (Zugegeben, das XIB-Format hat geholfen, aber es ist jetzt einfach schrecklich statt unmöglich.) Wenn Sie an einer großen Anwendung mit mehreren Entwicklern arbeiten, werden Sie enorm viel Zeit damit verschwenden, sich mit diesem Problem zu befassen.
Das Schlimmste daran ist, dass Sie es möglicherweise erst zur Laufzeit bemerken, wenn es automatisch falsch zusammengeführt wird. Mit Code können Sie den Unterschied lesen und verstehen, was passiert. NIBs (in beiden Formaten) sind nicht für Menschen lesbar. Dadurch ist es auch nutzlos, den Verlauf einer Datei einzusehen. Wenn es Code war, ist es nur Objective-C. Darin sind wir gut.
Es ist Teil von Xcode
Früher war das ein größeres Problem, aber ich denke, es ist immer noch erwähnenswert. Um es vorsichtig auszudrücken: Xcode ist nicht die stabilste Software der Welt. Der Textbearbeitungsteil funktioniert ziemlich gut. Jedes Mal, wenn beim Bearbeiten einer NIB ein Absturz auftritt, grummele ich vor mich hin und wünschte, es wäre noch mehr Code.
Je seltener ich Xcode für mehr als alles andere außer einem Texteditor mit Vervollständigung und einem Compiler verwenden muss, desto glücklicher bin ich.
Standort, Standort, Standort
Der Layoutcode ist nicht schwer. Auto-Layout ist etwas mehr Code als herkömmliches Layout, aber es ist immer noch nicht schlecht. Der Versuch, im Interface Builder mit dem automatischen Layout zu arbeiten, ist wahnsinnig. Das Festlegen von Steckdosen zur Steuerung integrierter Einschränkungen ist einfach nur Albernheit.
Es ist so einfach, es einfach zu überschreiben layoutSubviews und mach dein Ding. Persönlich finde ich es für die meisten Dinge viel einfacher, damit zu arbeiten als das automatische Layout.
Ich denke, die größte Angst vieler Menschen besteht darin, mit Layouts im Code zu arbeiten. Sobald man den Dreh raus hat, ist es ganz einfach. Die universelle Gestaltung Ihrer App wird viel trivialer als die Erstellung separater NIBs für iPhone und iPad. Sie können Ihren Code einfach wiederverwenden, anstatt diese enge Kopplung zu erstellen.
Fazit
Interface Builder selbst ist nicht schlecht. Es fördert schlechte Praktiken, verhindert die Wiederverwendbarkeit, erschwert die Zusammenarbeit mit anderen und verlangsamt Ihren Arbeitsablauf. Persönlich vermeide ich die Verwendung von Interface Builder (einschließlich Storyboards) so weit wie möglich. Alle Projekte, an denen ich seit 2009 gearbeitet habe, hatten keine NIBs, es sei denn, es lag außerhalb meiner Kontrolle.
Ich denke, Sie sollten sich etwas Zeit sparen, ein paar Dinge lernen und mit dem Umstieg auf Code beginnen. Wir sind schließlich Programmierer.
Aktualisieren: Ganz zu schweigen von der Lokalisierung. Es ist ein großer Schmerz mit IB. Am Ende stellt man Verbindungen zu allem her. So viel einfacher im Code.
