Ich arbeite mit etwas Code, den ich umgestalten muss. Ein View-Controller fungiert als Container für zwei andere View-Controller und wechselt zwischen diesen, wie im folgenden Code gezeigt.
Dies ist vielleicht 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 sich das Design ändern 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 folgende Code innerhalb einer Methode ist - und diese Methode wird zweimal aufgerufen ...
%Vor%Danke, Gavin
Im Allgemeinen ihre Richtlinien für View Controller "containment" , wann Einer enthält einen anderen, sollte befolgt werden, um festzustellen, ob Sie eine Eindämmung implementieren müssen.
Insbesondere ist es zweifach problematisch, denselben Kind-View-Controller zweimal hinzuzufügen. Wenn Sie die Dinge wirklich durchdacht haben, sollten Sie sich diesem Problem nicht stellen müssen. Deine Ahnung ist richtig.
Ich stimme zu, dass Apples Dokumente mehr von vornherein aufpassen sollten, was mit seltsamen Parametern passiert oder wenn sie außerhalb der Reihenfolge aufgerufen werden, aber es könnte auch ein Fall sein, dass sie sich nicht an ein fehlerkorrigierendes Design binden wollen 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 der Zukunft möglicherweise anders funktioniert und Ihre App beschädigt.
Wenn Sie noch etwas weiter gehen, werden Sie feststellen, dass die Container-View-Controller von Apple nicht in einen ungültigen Zustand kommen können (zumindest nicht so einfach mit der öffentlichen API). Mit 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 benutzen".
Kodierung für alles andere, wie das Entfernen von allen Ansichten oder alle View-Controllern, egal was in einigen Fällen sinnvoll oder robust erscheint, aber es ist im Gegenteil das Gegenteil Ein Ende Ihres Codes traut dem anderen Ende Ihres Codes nicht, seinen Teil des Geschäfts zu behalten. In jeder Situation, in der Ihnen das tatsächlich hilft, bedeutet dies, dass Sie den View-Controllern ohne das gewünschte Steuerelement beliebig oft hinzufügen können. In diesem Fall ist das das Problem, das Sie beheben sollten.
Tags und Links objective-c ios viewcontroller