Wie der Titel vermuten lässt habe ich ab und an ein paar Fälle, in denen ich ruckizucki an die Grenzen des Interface Builder im Allgemeinen bzw. der Storyboards im Speziellen stoße.
Eventuell kennt ihr Methoden, mit denen sich solche Fälle bequem anpassbar und für jeden schnell ersichtlich umsetzen lassen. Andernfalls bin ich auf Meinungen gespannt, welche Variante ihr warum vorziehen würdet.

Ich nehme hier beispielhaft ein UITableView im UITableViewController, welchem ich gern eine Zusammenfassung voranstellen möchte.


Ansatz 1: SummaryView und ContainerView
Der erste Ansatz beläuft sich darauf, zunächst im oberen Bereich das View zu designen und dann im unteren Bereich einen Container einzupassen, der die UITableView darstellt.
Das Ganze geht genau so lange gut wie sich das iPhone im Portraitmodus befindet. Im Landscape rutscht die UITableView arg nach unten, ist noch ungefähr eine Zelle hoch und nur der Bereich lässt sich scrollen: Miserable UX.
Die erste Idee, beides in einen UIScrollView zu packen, habe ich ebenso schnell wieder verworfen. Das UITableView hat schließlich schon einen UIScrollView, und UIScrollView in UIScrollView klingt total falsch.

Ansatz 2: SummaryView als TableViewHeaderView
Dieser Ansatz fühlt sich für mich zunächst richtig an. Da die Zusammenfassung über der Tabelle stehen soll und mitscrollen soll, ist der TableViewHeader der genau richtige Ort.
Nur kann ich das Ding natürlich im Interface Builder nicht setzen. Genausowenig wie Section Header/Footer Views, wobei man erstere im IB wenigstens noch vermuten kann.

Jedenfalls haben sich mir dafür vier Optionen aufgetan, die alle ihre Vor– und Nachteile haben.


Option 1: SummaryView in ContentView und programmatisch umhängen
Ich könnte das View im ContentView oberhalb der TableView designen. Im Code müsste ich das dann aber von seinem Superview lösen und als TableViewHeaderView setzen.
Ansonsten hätte ich nicht nur das View 2x in der View Hierarchy, nein, das direkt im Content View hängende View skaliert auch noch äußerst dämlich und unberechenbar bei Rotationen.
(Natürlich so, dass es den TableViewHeaderView überdeckt…)
Vorteil: View ist im Storyboard sichtbar.
Vorteil: View ist im Storyboard editierbar.
Nachteil: Manipulation der View Hierarchy im Code, Ersetzungen des Views können zu unerklärlichem, schwer auffindbarem Verhalten führen.
Nachteil: TableViewController ist für die Manipulation des Header Views verantwortlich.

Option 2: SummaryViewController außerhalb des ContentView verschieben und programmatisch einhängen
Ich könnte das fertig erstellte View auch aus dem ContentView ziehen, so dass es der ViewHierarchy gar nicht zugefügt wird. Damit erspare ich mir dann das Umhängen und das Verändern der View Hierarchy 'hintenrum'.
Vorteil: View ist losgelöst der initialen Hierarchie.
Nachteil: View im Storyboard nicht als HeaderView erkennbar.
Nachteil: View im Storyboard erst nach Ziehen in den ContentView editierbar.
Nachteil: TableViewController ist für die Manipulation des Header Views verantwortlich.

Option 3: SummaryViewController im Storyboard erstellen und programmatisch einhängen
Ich könnte einen weiteren ViewController für die SummaryView im Storyboard erstellen.
Dieses kann ich dann im TableViewController Code einfach als TableHeaderView setzen.
Vorteil: View im Storyboard editierbar.
Vorteil: ViewController kümmert sich um die Darstellung im SummaryView.
Nachteil: View im Storyboard nicht als HeaderView erkennbar.
Nachteil: Storyboard markiert ViewController als 'unerreichbar', da keine Segue hin führt.

Option 4: SummaryViewController mit eigenen Xib im Code erstellen und programmatisch einhängen
Diese Option fühlt sich für mich logisch an. Ich erstelle meinen SummaryViewController im Code und das dazugehörige SummaryView im dazugehörigen .xib File.
Dann muss ich den Controller im TableViewController nur noch instanzieren und sein View als TableHeaderView einhängen.
Vorteil: View im Interface Bulder editierbar.
Vorteil: ViewController kümmert sich um die Darstellung im SummaryView.
Nachteil: View im Storyboard nicht als HeaderView erkennbar.


Das Vorteils–/Nachteilsverhältnis ist bei Option 4 mit 2/1 natürlich am Besten.
Unter Berücksichtigung der Tatsache, dass ein Storyboard gemäß Definition aus der Film– und Spielebranche eine grobe Skizze ist, kann ich damit leben, dass auf dem ersten Blick nicht erkennbar ist, ob das TableView jetzt einen (eigenen) TableViewHeaderView hat oder nicht.
Allerdings wäre es schon schön, wenn man zumindest visualisieren könnte, dass es einen gibt. (Wie der aussieht wäre für die Skizze ja unerheblich… Vergleiche Section Header.)

Nun ja, wie würden Sie entscheiden?