Los estados de guía Vista de programación de controladores uso de este controlador de vista en cuanto a:Usando vista personalizada controladores para gestionar diferentes porciones de la misma vista de jerarquía
Cada objeto controlador de vista personalizada que crea es responsable de la gestión de todos de la vistas en una sola vista jerarquía. En las aplicaciones de iPhone, las vistas en una jerarquía de vista cubren tradicionalmente toda la pantalla, pero en las aplicaciones de iPad pueden cubrir solo una parte de la pantalla. La correspondencia uno a uno entre un controlador de vista y las vistas en su jerarquía de vista es la consideración de diseño clave . No debe usar múltiples controles de vista personalizados a administrar diferentes porciones de la misma jerarquía de vista . Del mismo modo, no debe usar un único objeto de control de vista personalizado para administrar varias pantallas que valgan la pena el contenido.
entiendo que si utilizamos múltiples vista personalizada de controlar las partes de una vista (es decir, un controlador de vista para gestionar subvistas de una vista principal, que a su vez está gestionado por un controlador de vista) los métodos predeterminados como controlador:
didReceiveMemoryWarnings
viewWillAppear
viewWillDisappear
viewDidUnload
etc. etc. no serán llamados.
Aparte de esto, ¿hay alguna otra razón sólida por la que no deberíamos usar múltiples controladores de vista para administrar las respectivas subvistas de una vista?
La documentación también proporcionan una solución alternativa que dice así:
Nota: Si desea dividir una jerarquía de vistas en varias subáreas y administrar cada uno por separado, utilice objetos del controlador genérico (a medida objetos que descienden de NSObject) en lugar de ver los objetos del controlador en administrar cada subárea. A continuación, utilice un único objeto de controlador de vista para administrar los objetos de controlador genérico .
Pero no hay ninguna mención en cuanto a por qué no se debe preferir múltiples controladores de vista. Mi pregunta es:
¿Por qué no deberíamos preferirlo de esta manera?
Me preocupa porque prefiero usar la subclase de UIViewController para administrar mis vistas, ya que las cargo desde el plumín cada vez y segrego plumillas para cada controlador de vista. Resulta fácil atender los cambios en etapas posteriores del proyecto. ¿Esto esta mal? ¿Debo cambiar necesariamente mi estilo de programación, o está bien si sigo adelante con este enfoque?
Gracias,
Raj
Sí se puede hacer, puedo crear una subclase NSObject y designarla como el propietario de un archivo para ese plumín. Pero me preguntaba si hay otras razones específicas de por qué no hacerlo de esta manera. Tu explicación de que el objeto es "pesado" es suficiente, a partir de ahora. –
Bueno, creo que es bastante inútil. Dado que la única razón por la que dio fue para segregarlos en IB, y eso se puede hacer con un NSObject. No creo que uses ninguno de los métodos de UIViewController, entonces ¿por qué subclase este objeto específico? Quiero decir que también podría subclasificar cualquier otra subclase de UIResponder (como UIView o UIButton), pero como lo único interesante que utiliza es la vista IBOutlet, no necesita un objeto específico. – Julien
Sí, muy cierto. Convenido. –