Comunicación entre los controladores de vista

Question

Comunicación entre los controladores de vista

votos

3

Dada la sección de una aplicación que tiene un UINavigationController y 2 niveles de UITableViews (es decir, se selecciona una fila en el controlador raíz que empuja al segundo controlador a la pila de navegación) tengo las siguientes preguntas:

1) Hay un objeto Usuario que es requerido por ambos controladores. ¿Cuál es la mejor forma de comunicarse entre los dos controladores? He visto una publicación en este sitio que menciona la inyección de dependencias y que el controlador raíz podría pasar el objeto Usuario al controlador de segundo nivel de la siguiente manera:

@implementation SecondLevelViewController

-(void) initWithUser: (User *) user {
   // myUser is an instance variable
   myUser = user;
   [myUser retain];
}

En ese ejemplo, parece que el segundo controlador retiene al usuario, mientras que he visto otras fuentes (por ejemplo, el curso de desarrollo de iPhone de Stanford) que recomiendan que el usuario simplemente se asigne, y no se conserve, en esa situación (acoplamiento libre).

También he visto argumentos para una forma de delegación en la que se usaría un objeto de identificación asignado en el segundo controlador (en lugar de una variable de instancia de Usuario retenida como se indicó anteriormente).

Sería genial si alguien pudiera aclararme este puesto, ya que estoy extremadamente confundido por el consejo aparentemente contradictorio en esta área. ¿Cuál es la mejor forma de comunicación entre los controladores de visualización?

2) Mi segunda pregunta también se refiere a la estructuración de los controladores. He visto ejemplos donde el controlador raíz (en la disposición anterior) tiene una matriz de controladores de segundo nivel instanciados. ¿Es esto normal en una aplicación profesional o habría un impacto significativo en la memoria al hacer las cosas de esta manera (es decir, sin carga diferida)? Supongo que la ventaja de la matriz es una reducción de los tiempos de carga para los controladores de segundo nivel.

Gracias por cualquier respuesta, ya que estoy tratando de desarrollar las cosas correctamente en lugar de hackearlas.

iphone objective-c uiviewcontroller uinavigationcontroller communication

Publicado el 10/12/2009 a las 11:19
fuente por usuario Urizen

En otros idiomas...

2 respuestas

votos

1

En general, debe tratar de evitar el paso directo de datos entre los controladores.

Puede configurar su modelo al que cada controlador tiene acceso y luego puede implementar notificaciones para informar al otro controlador que sucedió algo. El otro controlador puede obtener los datos necesarios del modelo.

De esa forma mantienes separados tus controladores.

Respondida el 10/12/2009 a las 23:12
fuente por usuario stefanB

Ole Begemann · Accepted Answer · 2009-12-10 13:19

1) "¿Cuál es la mejor forma de comunicación entre los controladores de vista?"

No hay una sola "mejor" manera. Ciertamente puede pasar un objeto modelo al controlador de vista en la inicialización. En ese caso, el controlador generalmente debe retener el modelo. Ir con un delegado es una buena opción si está escribiendo una clase de controlador de vista general con un enfoque en la reutilización (como UITableViewController).

2) "He visto ejemplos en los que el controlador raíz (en la disposición anterior) tiene una matriz de controladores de segundo nivel instanciados. ¿Es esto normal en una aplicación profesional?"

En primer lugar, debe limitar sus publicaciones en SO a una pregunta por publicación. El impacto de la memoria de un controlador de vista en sí mismo es bastante bajo. Necesita solo unos cientos de bytes para sus variables de instancia. La parte de memoria intensiva son las vistas en sí mismas. Y el mecanismo de carga / descarga de la vista de UIViewController se encargará de descargar la vista de memoria intensiva cuando sea necesario (es decir, si recibe una advertencia de memoria y la vista no está actualmente en pantalla). Por lo tanto, mientras implemente viewDidLoad, viewDidUnloady didReceiveMemoryWarningcorrectamente, no me preocuparía demasiado por el consumo de memoria de una serie de controladores de visualización.

UITabBarController tiene una gran variedad de subcontroladores, así que no hay nada de malo en eso. Lo que debe evitar, sin embargo, es que un controlador mantenga toda una jerarquía de subcontroladores (es decir, no solo de segundo nivel, sino también de tercer nivel, etc.): no tanto por cuestiones de memoria como por evitar el acoplamiento innecesario.