ich mache alles im Code
ich empfinde IB/Storyboard als umständlich

Hallo,

ich habe mich auch schon öfters geoutet, dass aus meiner Sicht XIB, gerade bei komplexen Projekten, keinen Vorteil bringen.

Leider bin ich gerade auf dem Sprung, aber ein paar Worte:

Im Code sind zukünftige Änderungen viel leichter zu verwalten.
Eben genau dann, wenn man viele individuelle Elemente hat.
Die Zuweisungen im XIB sind dann aufwändig, wenn man die Lokalisierungen berücksichtig.

Die Abneigung kommt bei mir auch daher, dass seit dem es XIB gibt keine Suche mehr möglich war.
Bei Xcode 1 und 2 konnte damals in den NIB gesucht werden.
Mit Xcode 3 und neuer war das dann alles nicht mehr möglich.

Wurde dann eine Klasse, Bild, Methode etc. umbenannt, dann war man am Kotzen.
Jetzt können natürlich die Schlauen mit Struktur etc. argumentieren, aber der Praxisalltag ist nun mal anders.

Die Wartung und vor allem das Reinfinden bei XIB ist echt mühsam.
Hat man viel dynamische Elemente, z.B. ist in den Einstellungen das aktiviert und der Anwender dort eingeloggt, dann zeige das Subview oder verrutsche etc. ist dann eh nur via Code möglich.
Aber die Elemnte liegen im XIB und stiften Verwirrung.

Mit XIB kommt man auch schnell auf die Bindings, die toll sind und super funktionieren.
Da war ich früher ein Fan von.
Aber auch hier wieder, so bald es Abhängigkeit gibt ist Code notwendig.
Methode umbenannt oder eine Attribut und man ist am Rotieren.

Das hat schon alles seine Attraktivität, aber für mich nicht mehr vorteilhaft.
Wer fit ist, der ist mit Code genauso schnell.
Zumal man sich entsprechende Schnippsel hinterlegt hat und über die Erfahrung schon die Struktur im Kopf hat.

Jeder ViewController bekommt bei mir eine -prepare: -prepareUserInterface: etc Methode.

Und Ruck Zuck kommt man auf den Trichter, dass das immer das Gleiche ist und man schreibt sich einfach eine abstrakte Klasse und die Ableitungen sind dann kinderleicht zum Individualisieren.

Ich habe es schon mal in einem anderen Thread geschrieben, dass ich neulich ein Probekt hatte mit Storyboard.
Mein Rechner war beim öffnen am Limit, es hat viele Sekunden gedauert und das Ding war einige MB groß.
Auch das Endprodukt war mehrere MB.
Ich habe das Gleiche Zeugs dann als Code implementiert und zum einen war das Build super schnell erstellt und das Produkt war am Ende einige KB.
Klar kann man argumentieren egal wie groß es ist, wer hat kein Breitband, aber ich sehe das anders.
Apple ja mittlerweile auch, da sie App Thining einführen.
Das ist zwar derweil nicht mit Lokalisierung zu begründen, aber Speicher bzw. Traffic ist doch wieder ein "Problem".

Wenn Du die Muse hast, dann mache doch mal eine Tabelle in einem ViewCobtroller mit drei unterschiedlichen Arten von Zellen.
Einmal via Code und das andere mit XIB.

Achso, oben habe ich kritisiert, dass via Xcode nicht in XIB gesucht werden konnte.
Seit Xcode 6 ist das wieder möglich und natürlich eine extreme Hilfe.
Das muss ich zur Vollständigkeit erwähnen. Aber mehr Aufwand bleibt aus meiner Sicht dennoch, also bei der zukünftigen Wartung.

Viele Grüße

Ich mag es, gerade bei komplexen Projekten, im Storyboard dem Flow der App nachvollziehen zu können. Alle Anpassungen, custom views, etc werden auch bei mir im Code gemacht.

Das ist natürlich eine Geschmacks- und Gewöhnungsfrage. Wie alle komplexeren Tools braucht auch der Interface-Builder eine gewisse Einarbeitungs- und Gewöhnungszeit.

Ich verwende in allen Projekten Storyboards und ggf. XIBs. Ich finde die Erstellung von Views per Code ungleich aufwändiger und unübersichtlicher. Dank Auto-Layout und Base-Internationalization ist inzwischen auch die Lokalisierung der App für mich kein Argument mehr gegen NIBs, und auch das Refactoring funktioniert inzwischen damit recht gut.

Die mit Xcode 6 eingeführten Features (IB_DESIGNABLE und IBInspectable) nutze ich sehr intensiv. Sehr praktisch ist auch die Preview-Ansicht im Assistant-Editor gerade zum Testen von Auto-Layout-Einstellungen.

Ich bin gerade am überlegen mal testweise den umgekehrten Weg zu gehen und mal eine App komplett ohne IB zu testen.
Bin mir aber eigentlich sicher, für mich selbst mit dem IB normal besser zu fahren.

Wenn man mit Anderen zusammen an einem Projekt arbeitet, ist der IB sicher eher hinderlich, allein schon weil Diffs anzeigen in der Versionsverwaltung nicht wirklich möglich ist.
Zudem können schlecht 2 Leute gleichzeitig UI Änderungen machen, was im Code absolut kein Problem ist. Erst recht nicht, wenn die Änderungen in verschiedenen Files liegen.
Im Storyboard liegt halt meist fast alles in einer Datei.

Da ich aber als Einziger an meinen Projekten arbeite, tangiert mich das eher wenig.

Ist sicher auch eine Typ-Frage, aber ich bin ein sehr visueller Mensch und muss die Dinge vor mir sehen.
Würde ich alles im Code machen, müsste ich wahrscheinlich weit mehr Arbeit in gescheite Mockups stecken um klarzukommen.

Wie macmoonshine nutze auch ich IBDesignable und IBInspectable sehr intensiv.
In diesem Interface Builder Screenshot ist keine einzige Bilddatei verwendet, das ist alles per Code gezeichnet (PaintCode).

Bildschirmfoto 2015-09-27 um 15.20.05.png

Dennoch sieht der ViewController fast identisch zum finalen Produkt aus.:
phone.png

Mit der Technik lässt sich auch ein gesunder Mix leben:
Z.B. Setup von Views die man wiederverwenden will im Code erledigen und dennoch die Auswirkungen im Interface Builder sehen.

Am Mac nutze ich den IB sehr viel, da aber nur xibs, keine Storyboards. Unter iOS das meiste im Code und ab und an xibs, Storyboards zwingen mir ein Konzept auf, welches nicht gut zu meinen Vorlieben passt. Autolayout nutze ich extensiv, aber ebenfalls im Code, im IB ist es mir zu lästig, ständig mit irgendwelchen Bugs oder nicht aktualisierten Frames zu kämpfen. Das was der IB da eigtl verspricht, hält er für mich nicht...

Ich verwende für jeden View Controller gerne ein eigenes NIB/XIB. Ein Storyboard war bisher nicht nötig, von daher habe ich damit noch nicht wirklich beschäftigt.

Ich finde es jedoch sehr schade, dass man mit Xcode 6 bei neuen Projekten ein Storyboard aufgedrückt bekommt. Oder habe ich da etwas übersehen?

Mir ist es jedoch bisher nicht gelungen, ein neues Projekt ohne Storyboard anzulegen.

Gerade beim tvOS habe ich mich dadrüber aufgeregt. Ich sehe da gar kein Weg es derweil ohne zu implementieren.
Ich habe es derweil als "Eingang" zum eigentlichen Code verbogen. Hinweise, wie es ohne möglich ist sind auch bei mir willkommen.

Viele Grüße

Du kannst das Storyboard rausschmeißen und stattdessen XIBs anlegen. Oder du legst im App-Delegate das Hauptfenster an und weist ihm den Rootviewcontroller zu. Das geht zumindest unter iOS alles wie früher auch. Nur die Templates fehlen.

Und beim WatchOS kommt es noch dicker. Da muss alles, was man auf der "Uhr" anzeigen will, im IB angelegt werden. Da ist man fast schon wieder froh, dass das dafür noch recht limitiert ist ...

Ich persönlich schwöre ja auf Storyboards, man sollte allerdings schon ungefähr eine Idee haben, wie die Dinger funktionieren.
Natürlich sind sie größer als kompilierter Bytecode, es sind ja schließlich XML Ressourcen, die da im Projekt landen und dynamisch in entsprechende Objektgraphen umgewandelt werden.
Natürlich ist ein einzelnes Storyboard riesengroß und benötigt ∞-1 Minuten zum Laden, extrahieren und Darstellen.
Natürlich bricht das System bei einem SCM nahezu zusammen, wenn sich Änderungen eingeschlichen haben.

Mit ein paar Regeln ist das alles aber ziemlich simpel lösbar.

• Es ist XML!
  Und zwar ziemlich geschwätziges XML.
  Merge–Konflikte sind dort eigentlich kein allzu großes Problem. Klar, wenn das Label nur 'UILabel' heißt wird die Zuordnung schwierig – das wird sie dann aber auch bei Autolayout Problemen. Ansonsten sieht man bei einem Diff schon ziemlich genau, was geändert wurde und wohin. Nicht graphisch, sondern nur im XML, aber man sieht es genau.
  Versionsnummer angepasst – mir doch egal. Attribut 'misplaced=YES' drin – interessiert mich nicht. Einzige Änderung an der ID des Views – was kümmert's mich? Größenänderung – Autolayout, mir doch egal…
  
  
• Jeder nur ein Kreuz, pardon, UI File.
  Wenn fünf Leute gleichzeitig an einer UI schrauben (im Übrigen seit Xcode 1 das Argument pro Code und contra Nib), dann stimmt da doch was im Prozessablauf nicht.
  Es ist mehr als sinnvoll, in einem Team die entsprechenden Aufgaben entsprechend aufzuteilen.
  Spielt jemand aktiv an den Settings der App wird er am Besten wissen, was er wann und wie benötigt.
  Es gibt keinen Grund für Andere, ebenfalls im UI der Settings herumzufingern.
  
  
• Ein Storyboard je Flow.
  Die Grundidee der Storyboards existiert ja nicht erst seit 1939, als Disney ihr Schneewittchen herausgebracht hat. Im Allgemeinen gibt es dieses Prinzip schon seit Jahrzehnten in allen Bereichen, die eine Geschichte erzählen wollen.
  Ein Storyboard zeigt genau eine Szene dieser Geschichte auf. Eine Abhängigkeit zwischen anderen Szenen existiert nicht, es existieren nur Abhängigkeiten zwischen den einzelnen für diesen Teil der Geschichte wichtigen Panels.
  Genau so sollte sich das Storyboard der App verhalten: Ich habe einen TabView Controller, der unterschiedliche Ansichten verwaltet? Fein, initialer ViewController verweist auf andere Storyboards. (Geht seit iOS 9 sogar direkt in den Storyboards und ohne Code.)
  Startseite – eigene Szene, eigenes Storyboard. Settings – eigene Szene, eigenes Storyboard. Jeder weitere Tab eine eigene Szene und ein eigenes Storyboard.
  Auch das mindert die Gefahr, dass zwei unterschiedliche Teams am selben Storyboard arbeiten müssen.
  
  
• Eine Version der IDE und alle UI Warnings beheben.
  Bei jedem Laden eines Storyboards passt Xcode nicht nur die Versionsnummern der verwendeten Tools an, es aktualisiert auch Änderungsinformationen wie beispielsweise fehlplatzierte Views im Storyboard. Das führt dazu, dass das Storyboard verändert aussieht obwohl man nix daran geändert hat.
  Wenn jeder die identische Version verwendet und jeder darauf achtet, dass es sauber und richtig platziert gespeichert wird, löst man damit eine Menge Änderungskonflikte im Vorfeld.
  Im Zweifel gilt: Weg damit. Hat man selbst am Storyboard nichts verändern müssen und SCM markiert es als 'bearbeitet', hau die Änderungen einfach weg.
  
  
• Git Flow, Alter.
  Sofern jeder in seinem eigenen kleinen Feature/Hotfix Branch rumfuhrwerkt treten eventuelle Probleme mit dem Xib nur noch beim Merge auf.
  Mergeprobleme existieren ja bekanntlich auch bei ganz normalen Codefiles, es ist also kein Voodoo für ihre Behebung notwendig.
  

Wenn man sequentiell am selben Projekt arbeitet haben Storyboards den Vorteil, dass man sich die Struktur einer App schnell erschließen kann: "ah, ich hab' hier einen TabBarController, und da sind diese fünf Ansichten drin" statt sich durch einen Wust von VC-Sourcen zu wühlen; irgendeine Form von Übersicht ist bei einer halbwegs komplexen App schon hilfreich, und nebenher irgendwelche UML-Diagramme pflegen ist auch Arbeit (mhh, eigentlich müsste man die Struktur ja auch programmatisch erzeugen können... kann da mal wer was bauen?
Wahrscheinlich sind sich aber alle einig, dass Storyboards keinen Spaß machen, wenn mehrere Leute zur gleichen Zeit Änderungen durchführen.

Der Vorteil der Übersichtlichkeit kann auch schnell verloren gehen, wenn man viele Container benutzt:
Eine iPhone-App, bei der man sich mit Navigation-Controllern von Screen zu Screen hangelt, kann man wunderbar verstehen, aber sobald man anfängt, mehrere eigene Viewcontroller gleichzeitig anzuzeigen geht die Verbindung zwischen App und Storyboard verloren (man hat Szenen im Storyboard, die man in der App so nie erlebt).

Einen Vorteil sehe ich noch für den Verzicht auf den IB:
Wenn man einen kompletten VC ohne Nib erzeugen kann, lässt er sich einfacher wiederverwenden, weil man nur eine Lib mit dem Source braucht (und keine Resource).

Ich nutze bevorzugt XIB files auf iOS: meist ein XIB file pro ViewController. Storyboards habe ich in kleinen Projekten getestet aber ab einer gewissen Anzahl an ViewControllern wird das Öffnen träge und man bekommt auf kleineren Monitoren nur einen Bruchteil angezeigt.

Bei der programmatischen Erstellung der Views fehlt mir irgendwie die "Vorschau der Views".

Zumindest mit Swift kannst du dafür nen Playground nehmen, das funktioniert hervorragend.

Hier gibt's auch nen Objective-C Port, aber nicht getestet


github.com/krzysztofzablocki/KZPlayground

Oh je, noch ein verlorener Thread

Bisher bin ich ja davon ausgegangen, der Wechsel (NSArray -> Array, NS... -> ...) hat nur mit NextStep zu tun, aber wenn jetzt Objective-C Projekte mit "KZ" assoziiert werden kommt man ins Grübeln

Ja, hab mich auch erst nicht getraut zu schreiben
Okay, KZ ist schon rau. Garnicht aufgefallen

Hm, ein KZ als Prefix entspricht doch der allgemeinen Namenskonvention für Klassennamen, oder habe ich Dein Smilie nicht richtig gedeutet?