View Controller/NIB-Architektur für Nichtvernichtung mit Übergängen?

Question

Ich bastle an einer iPad -App, die (wie viele iPad -Apps) das UinAvigation Root View -Steuerungssystem nicht verwendet, sodass ich für jede App "Ansicht" nicht natürliches Eigentum habe. Ich habe im Wesentlichen zwei grundlegende Ansichten: eine Dokumentlisteansicht und eine Dokument -Bearbeitungsansicht.

Ich spiele mit UIView -Animation, um von einem ausgewählten Dokument bis zur Bearbeitungsansicht zu erhalten.

Ich habe auch eine Symbolleiste darüber, die in beiden "Ansichten" existiert (mit verschiedenen Schaltflächen).

Da ich die Show für mich nicht ausführen kann, neige ich dazu, einfach immer mehr Dinge in eine NIB- und einen View -Controller zu werfen, der den gesamten Container besitzt. Aber jetzt versuche ich herauszufinden, wie man aus der Dokumentlistenansicht zur Bearbeitungsansicht übergeht, wenn die Bearbeitungsansicht in einer anderen NIB lebt und auch die Symbolleiste beibehält.

Hat jemand Gedanken oder Erfahrungen zu solchen App -Strukturen? Ich finde, dass die Dokumente für Best Practices rund um die Code-/UI-Struktur für irgendetwas außer trivialen Ein-Bildschirm-Apps oder Vollnavigations-Apps fehlen.

Sie sind nicht "angenommen", über Eltern/Kinderansicht zu haben, die Unterkomponenten desselben "Bildschirms" gemäß den Dokumenten besitzen, aber dies impliziert einen massiven Hupen -View -Controller, der im Grunde die gesamte App enthält, und das kann nicht richtig sein.

Ich bin mir nicht sicher, ob es eine "richtige Antwort" hat; Ich suche einige intelligente Beispiele oder Vorschläge. Niemand hat diese Frage seit Monaten berührt, also füge ich ein Kopfgeld hinzu, um ein gutes Geschwätz zu erzeugen. :)

Vielen Dank!

AKTUALISIEREN: Ich spreche nicht von einer geteilten Ansicht, die von einem Split View -Controller eindeutig gut behandelt wird. Schauen Sie sich stattdessen die iWork -Apps von Apple (z. B. Seiten) an, die eine Dokumentlistenansicht und eine unabhängige Bearbeitungsansicht haben. Diese sind jedoch durch Animation zusammengefasst.

Vielleicht lautet die eigentliche Frage hier: Wie würden Sie (oder könnten Sie sogar?) Einen "Container" -Ansichtskontroller wie die geteilte Ansicht oder den Navigationscontroller selbst erstellen? Müssen Sie das ganze verdammte Ding von Grund auf bauen? Ich spüre, dass Sie es sind, weil Sie in der Interaktion zwischen Ansichtsregeln versteckt zu sein scheint. Wenn ja, Gedanken dazu?

Answer 1

Ich denke, die einzige versteckte Verkabelung in View Controllers ist das Einstellen von ParentViewController, die zur Unterstützung der für Split und Navigation deklarierten Kategorien erforderlich sind.

Die Ansichtscontroller sind so ausgelegt, dass sie verschachtelt sind, wobei jeder Controller einen Teil der View -Hierarchie besitzt. Das einzige Designziel ist, dass kein Ansichtscontroller in die View -Hierarchie eines anderen Controllers eingeht. Ein übergeordneter Ansicht Controller hat normalerweise einen Aufruf zum Hinzufügen von untergeordneten Controllern, damit er den Rahmen der Ansicht innerhalb der Ansichtshierarchie festlegen kann, die er besitzt. Ein Child View Controller sollte nichts in der Übersicht über die Ansicht tun, die er steuert, da dies einem anderen Controller gehört. Sollte es nicht die Mitte oder den Rahmen der Ansicht einstellen, die es steuert.

Beispielsweise hat ein Navigationscontroller eine Push -Methode, bei der die vorherige Controller -Ansicht entfernt wird, die neue Controller -Ansicht hinzufügt und den Frame der neu hinzugefügten Ansicht festlegt. Im Allgemeinen kann ein übergeordneter Ansichtsregler den Rahmen der Ansicht eines Kindercontrollers, nicht jedoch der Grenzen, festlegen.

Wenn Sie die Animation eines Navigationscontrollers ändern möchten, würden Sie zunächst jede Methode mit einem animierten: Argument implementieren. Richten Sie Ihre Animation ein und rufen Sie Super mit der animierten Flagge an, bevor Sie die Animation begehen.

Answer 2

Ich habe das Ding mit mehreren Ansichten nicht außerhalb der von UIKIT bereitgestellten (Navigation/Tab-Bar/Modal/etc) ausprobiert, aber ich verstehe nicht, warum es nicht funktionieren sollte. Unter der Motorhaube ist alles eine Ansicht, obwohl ich feststellen werde, dass UIKIT spezielle Ansichten für Ansichtscontroller hat, die zweifellos eine spezielle Handhabung des Systems haben (UIViewController hat eine Wrapper -Ansicht, UinavigationController hat eine uinAvigationStransitionView oder etwas. .).

Ich würde raten, mich nicht zu sehr um "bewährte Praxis" zu kümmern - nur etwas zu codieren, was das tut, was Sie wollen. Ein paar Optionen:

• Logik in Sichtklassen (ewwww!) Sehen. Eine unserer Apps erledigt dies, damit sie die Rotation auf benutzerdefinierte Weise verarbeiten kann (Ansichten gleiten Sie ein/aus, anstatt sich zu rotieren). Wir hätten stattdessen wahrscheinlich unsere eigene Ansichts -Controller -Logik implementieren sollen.
• Teilen Sie das Modell in Komponenten, die Ansichten entsprechen. Lassen Sie jede Ansicht wissen, wie Sie ihre Komponente laden und die Unterkomponenten rekursiv laden. Dann muss sich der View -Controller nur um "Big -Ganze" -Material Sorgen machen.

Beachten Sie auch, dass Sie mehrere Nibs in denselben Ansichtsregler laden können, indem Sie ihn an eine Outlet namens EditView verbinden. Der große Unterschied besteht darin

-(EditView*)editView {
  if (!editView) {
    // Loads EditView into the outlet editView
    [NSBundle loadNibNamed:@"EditView" owner:self];
  }
  return editView;
}

Sie müssen sich auch Sorgen machen, dass Sie es Ihrer Ansichtshierarchie hinzufügen, sie entladen -(void) viewDidunload (iPhone OS 3.0+), es in -(void) viewDidload aufstellen, falls es eine Speicherwarnung während des Bearbeitungsmodus gab, etc...

Es ist nicht einfach, aber UI ist es nie.

Answer 3

Sie benötigen eine Master-Detail-Ansicht, die mit einem Split-View/Popover-View implementiert und mit einem UiSplitViewController kontrolliert wird.

Die Master -Ansicht ist die Dokumentliste und die Detailansicht ist die Bearbeitungsansicht. Jeder hat seinen eigenen Controller. Die beiden Controller selbst werden vom UiSplitViewController verwaltet.

Wenn Sie den SplitView -Controller nicht verwenden, werden Sie einfach etwas kodieren, das ihm sehr ähnelt. Dies ist wirklich die einzige Möglichkeit, das zu tun, was Sie in der API leicht wollen, und es ist das Layout, das iPad -Benutzer erwarten werden.

Sehen Erstellen einer Split -View -Schnittstelle In der iPad -Programmierhandbuch für Details.