¿Prácticas recomendadas de UIView y UIViewController?

Question

Actualmente tengo una aplicación de iPhone simple que carga una subclase personalizada de UIView. Solo hay un controlador en este momento para toda la aplicación, aunque hay varias UIView para separar el programa lógicamente.

Mi actual estructura es como la siguiente:

mainView : UIScrollView 
    \__ has one subView : myCustomUIView : UIView 
      \__ has many subSubView : myOtherCustomUIView : UIView 

Espero que esto está claro; un colon, por supuesto, representa la herencia.

Mi problema es este: necesito interceptar eventos en el nivel más bajo, subSubView. Probablemente pueda hacer esto en el controlador de la aplicación si es necesario, pero ¿debería tener un SubSubViewController en su lugar? ¿Debo tener un SubViewController también?

Si es así, ¿alguien me puede indicar algunas referencias para hacer esto a mano? Por supuesto, puedo crear las clases, pero conectarlas a vistas personalizadas no parece trivial. No estoy usando ningún constructor de interfaz aparte de la punta principal que contiene el objeto ventana.

Mi principal confusión surge de lo que sucederá cuando tenga una vista anidada en una vista con un controlador diferente. Entonces digamos que sí tengo un SubSubViewController, pero mainView todavía tiene su mainViewController. Como subSubView está contenido en mainView, ¿esto no causaría ningún problema?

¿Y debería utilizar delegados para nada de esto?

Cualquier empujón en la dirección correcta sería apreciado.

Answer 1

Las vistas y los controladores de visualización existen en pares. Cada controlador de vista controla una vista y las subvistas de la vista. Esto es necesario porque los controladores de vista están en la cadena de respuesta para eventos. Si hay múltiples controladores de vista activos dentro de la misma vista, la cadena de respuesta queda codificada.

Los controladores de vista estándar no tienen un atributo subController y no entienden si otro controlador está activo en la misma cadena. Los controladores de navegación y tabbar existen precisamente para manejar controladores jerárquicos. Sin embargo, lo hacen intercambiando un par de vista/controlador de vista por otro. No puede usar los controles de navegación o tabbar para proporcionar diferentes controladores para las subvistas.

Por lo tanto, independientemente de la cantidad de subvistas que pueda tener para cualquier persona, termina con un solo controlador por pantalla.

Es posible que desee reconsiderar su diseño. Si cada una de las subvistas necesita un comportamiento altamente personalizable, es posible que desee moverlas a vistas individuales en una jerarquía de controladores, como en el patrón de diseño de detalle maestro.

Si tiene que tener todas las subvistas en la misma pantalla, le sugiero que observe cómo una UITableView y UITableViewController manejan las cosas. (Es posible que solo pueda usar una tabla vista modificada). Una vista de tabla es una vista de desplazamiento que contiene múltiples subvistas para celdas, títulos de sección, encabezados y pies de página. Lo logra atrapando los toques de la vista de tabla y determinando qué vista de celda se tocó y luego tomando la acción adecuada.

Si necesita un comportamiento altamente personalizado para cada subvista, puede usar el patrón delegado y asignar a cada subvista un objeto delegado diferente. La vista podría atrapar sus propios toques y llamar a su propio delegado.

Scrollviews puede ser complicado para implementar el comportamiento táctil personalizado porque las capturas de desplazamiento de desplazamiento tocan en un nivel más alto que otras vistas para que pueda determinar si es necesario desplazarse o no.