Die Verwendung von addChildViewController verstehen

Question

Ich arbeite mit etwas Code, den ich umgestalten muss. Ein View-Controller fungiert als Container für zwei andere View-Controller und wechselt zwischen ihnen, wie im folgenden Code gezeigt.

Dies ist möglicherweise nicht das beste Design. Der Austausch der View-Controller auf diese Weise ist möglicherweise nicht erforderlich. Ich verstehe das. Wenn ich jedoch mit diesem Code arbeite, möchte ich weiter verstehen, was mit dem addChildViewController-Aufruf passiert. Ich konnte die Antwort in Apples Dokumenten oder in verwandten Fragen hier nicht finden (wahrscheinlich ein Hinweis darauf, dass das Design geändert werden muss).

Speziell - wie behandelt der Container-View-Controller eine Situation, in der er aufgefordert wird, einen Child-View-Controller hinzuzufügen, den er bereits hinzugefügt hat? Erkennt es, dass dieses View-Controller-Objekt bereits hinzugefügt wurde?

z. wenn der Code unten in einer Methode ist - und das Verfahren wird zweimal aufgerufen ...

[self addChildViewController:viewControllerB]; 
[self.view addSubview:viewControllerB.view]; 
[viewControllerB didMoveToParentViewController:self]; 

[viewControllerA willMoveToParentViewController:nil]; 
[viewControllerA.view removeFromSuperview]; 
[viewControllerA removeFromParentViewController]; 

Danke, Gavin

Answer 1

Im Allgemeinen their guidelines for view controller "containment", wenn man eine andere enthält, sollte beachtet werden, ob Sie zu bestimmen, müssen Eindämmung implementieren.

Insbesondere ist es zwei Mal wichtig, denselben Kind-View-Controller hinzuzufügen, um sich Gedanken darüber zu machen, denselben View-Controller zweimal zu präsentieren. Wenn Sie die Dinge wirklich durchdacht haben, sollten Sie sich diesem Problem nicht stellen müssen. Deine Vermutung ist richtig.

Ich stimme zu, dass Apples Dokumente sollten mehr im Voraus über das, was mit seltsamen Parameter passiert oder wenn außerhalb der Reihenfolge aufgerufen wird, aber es kann auch ein Fall sein, sich nicht an ein fehlerkorrigierendes Design binden zu wollen Ärger die Straße runter. Wenn Sie ein Design entwickeln, das diese Methoden niemals falsch aufruft, lösen Sie das Problem richtig und machen Sie unabhängig von der Fehlerkorrektur, die sie haben oder nicht haben können - noch wichtiger, wenn Sie das berücksichtigen, da dies nicht der Fall ist dokumentiert, dass die Fehlerkorrektur in Zukunft möglicherweise anders funktioniert und Ihre App dadurch beschädigt wird.

Noch ein bisschen weiter, Sie werden feststellen, dass Apples Container-View-Controller nicht in einen ungültigen Zustand (zumindest nicht leicht mit öffentlichen API) gelangen können. Bei einem UITabViewController ist der Wechsel von einem Ansichtscontroller zu einem anderen eine atomare Operation, und der Registerkarten-Controller weiß zu jedem Zeitpunkt genau, was vor sich geht. Das meiste, was es jemals tun muss, ist den aktiven zu entfernen und den neuen zu zeigen. Die einzige Zeit, wo es alles aus dem Wasser bläst, ist, wenn du sagst "Du solltest alles aus dem Wasser blasen und stattdessen diese View-Controller verwenden".

für etwas Codierung andere, wie das Entfernen all Ansichten oder alle View-Controller, egal, was in einigen Fällen zweckmäßig oder robust sein, aber es ist genau das Gegenteil, da in der Tat ein Ende des Codes nicht traut das andere Ende Ihres Codes, um seinen Teil des Geschäfts zu behalten. In jeder Situation, in der Ihnen das tatsächlich hilft, bedeutet das, dass Sie den View-Controllern ohne das gewünschte Steuerelement hinzufügen können, und in diesem Fall das ist das Problem, das Sie beheben sollten.