Entender el uso de addChildViewController

Question

Estoy trabajando con un código que necesito para refactorizar. Un controlador de vista actúa como un contenedor para otros dos controladores de vista, y se intercambiará entre ellos, como se muestra en el siguiente código.

Este puede no ser el mejor diseño. Puede que no sea necesario intercambiar los controladores de vista de esta forma. Entiendo que. Sin embargo, a medida que trabajo con este código, quiero comprender mejor lo que sucede con la llamada addChildViewController. No he podido encontrar la respuesta en los documentos de Apple o en preguntas relacionadas, aquí (probablemente una indicación de que el diseño debe cambiar).

Específicamente: ¿cómo maneja el controlador de vista de contenedor una situación en la que se le pide que agregue un controlador de vista secundaria, que ya ha agregado? ¿Reconoce que ya ha agregado ese objeto controlador de vista?

E.g. si el código de abajo está dentro de un método - y que el método se llama dos veces ...

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

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

Gracias, Gavin

Answer 1

En general, their guidelines for view controller "containment", cuando uno contiene otra, se deben seguir para determinar si tendrá que implementar la contención.

En particular, preocuparse por agregar el mismo controlador de vista hijo dos veces es como preocuparse por presentar el mismo controlador de vista dos veces. Si realmente has pensado bien las cosas, no deberías enfrentar ese problema. Tu corazonada es correcta.

Estoy de acuerdo en que los documentos de Apple deben ser más directos sobre lo que sucede con parámetros extraños o cuando se llaman fuera de secuencia, pero también puede ser un caso de no querer vincularse a un diseño de corrección de errores que causará problemas en el camino. Cuando elabora un diseño que nunca llama a estos métodos de la manera incorrecta, resuelve el problema correctamente y se independiza de cualquier corrección de error que pueda o no tenga, incluso más importante si se tiene en cuenta que, dado que no es correcto. documentado, que la corrección de errores puede funcionar de manera diferente en el futuro, rompiendo su aplicación.

Yendo un poco más lejos, notará que los controladores de vista de contenedor de Apple no pueden entrar en un estado inválido (al menos no fácilmente con la API pública). Con un UITabViewController, cambiar de un controlador de vista a otro es una operación atómica y el controlador de vista de pestañas en cualquier momento sabe exactamente lo que está sucediendo. Lo máximo que tiene que hacer es eliminar el activo y mostrar el nuevo. El único momento en el que sopla todo lo que sale del agua es cuando le dices "deberías soplar todo fuera del agua y empezar a usar estos controles de vista".

Codificación para cualquier otra cosa, como la eliminación de todos puntos de vista o todos controladores de vista no importa lo que pase, en algunos casos parecerá conveniente o sólida, pero es todo lo contrario, ya que en efecto uno de los extremos de su código no confía el otro extremo de tu código para mantener su parte del trato. En cualquier situación en la que eso realmente lo ayude, significa que ha permitido que las personas agreguen controladores de vista de cualquier manera sin el control que usted debería desear, y en ese caso, que es, el problema que debe solucionar.