Soll View-Logik in eine UIView oder (falls vorhanden) ihren UIViewController gehen?

Question

Ich habe kürzlich entdeckt, dass UIView s nur UIViewController s haben sollte, wenn sie das gesamte Fenster ausfüllen (oder von einem anderen UIViewController wie einem UINavigationController oder UISplitViewController verwaltet werden). Dieses Angebot stammt aus der Dokumentation für UIViewController:

Sie sollten keine View-Controller verwenden, um Ansichten zu verwalten, die nur einen Teil ihres Fensters füllen - also nur einen Teil des durch das Rechteck des Anwendungsinhaltes definierten Bereichs. Wenn Sie eine Benutzeroberfläche mit mehreren kleineren Ansichten haben möchten, betten Sie sie alle in einer einzigen Stammansicht ein und verwalten Sie diese Ansicht mit Ihrem Ansichtscontroller.

Normalerweise lege ich meine Ansichtslogik in die UIView, selbst wenn sie von einem UIViewController verwaltet wird, aber oft muss ich auf die Eigenschaften von UIViewController wie die Eigenschaft navigationController zugreifen. UIViews sollten jedoch ihren UIViewController nicht kennen.

Meine Schlussfolgerung ist, dass View-Logik in einem UIView UIViewController gehen sollte, wenn eine existiert, und in der UIView selbst sonst.

Alternativ ist es besser, eine Controller-Klasse für eine Ansicht zu erstellen, die nicht eine Unterklasse von UIViewController ist? UIPopoverController (eine NSObject-Unterklasse) scheint diesem Muster zu folgen, obwohl in den meisten Fällen (UIButton usw.) keine dedizierten Controller-Klassen angezeigt werden.

Answer 1

Anwendungslogik sollte niemals in UIView gehen. Zeitraum. Der Zweck einer UIViewController ist die Verwaltung einer Ansicht und ihrer Untersichten und in den meisten Fällen der geeignete Ort für die Logik. UIKit hält sich an das Model-View-Controller-Paradigma. Modelle halten die Daten, Ansichten zeigen sie an und akzeptieren Eingaben, und Controller verwalten die Interaktion zwischen den anderen beiden Schichten. Aus diesem Grund ist der Controller der logische Ort für die Anwendungslogik. In iOS sind UIViewController und seine Unterklassen die üblichen Controller-Klassen. Ich würde vorschlagen, reading up on Apple's guidance, um dieses Muster und wie es in iOS verwendet wird, besser zu verstehen.

Das Zitat aus der Dokumentation von Apple sagt Ihnen, dass Sie kein UIViewController für jedes Etikett oder Knopf erstellen. Sie erstellen einen für jede "Seite" oder "Bildschirm" Ihrer Anwendung und Sie verwenden es, um die Steuerelemente in dieser Ansicht zu verwalten. Beachten Sie, dass UIKit über Klassen verfügt, um Tabellensichten, Registerkartenansichten und Navigationsansichten zu verwalten. Das ist die Ebene des Objekts, die Sie verwenden würden UIViewController zu verwalten.

Ich würde empfehlen, die im SDK enthaltenen iOS-Beispiele zu durchsuchen. Sie sollten Ihnen eine gute Vorstellung davon geben, wie das Framework erwartet, dass Anwendungen strukturiert werden.

Answer 2

Ich kam aus der Win32 + .NET + Java Swing GUI Welt und ich habe das gleiche getan. Aber dann habe ich meine bösen Wege korrigiert. Jetzt lege ich den Code in UIView nur dann fest, wenn ich die VIEW SELSELF anpassen möchte (zB OpenGL-Zeichnung).

Controller legen den Status der Ansicht fest. Die Ansicht macht ihren Status verfügbar.