6

Recientemente descubrí que UIView s solo deberían tener UIViewController s cuando llenan toda la ventana (o están gestionados por otro UIViewController como UINavigationController o UISplitViewController). Esta cita es de la documentación para UIViewController:¿Debería visualizarse la lógica en una UIView o (cuando corresponda) su UIViewController?

No debe usar los controladores de vista para administrar vistas que llenen solo una parte de su ventana, es decir, solo parte del área definida por el rectángulo de contenido de la aplicación. Si desea tener una interfaz compuesta por varias vistas más pequeñas, incrústelas todas en una sola vista de raíz y administre esa vista con su controlador de vista.

Normalmente pongo mi lógica de vista en la UIView incluso cuando es administrada por un UIViewController, pero a menudo me resulta necesario acceder a las propiedades de UIViewController, como su propiedad navigationController. Sin embargo, se supone que las UIViews no están al tanto de su UIViewController.

Mi conclusión es que la lógica de vista debe ir en un UIView's UIViewController cuando exista, y en la UIView de lo contrario.

Alternativamente, ¿es una mejor práctica crear una clase de controlador para una vista que es no una subclase de UIViewController? UIPopoverController (una subclase NSObject) parece seguir este patrón, aunque en la mayoría de los casos (UIButton, etc.) las vistas no parecen tener clases de controlador dedicadas.

+0

Además, ¿debería UIViewControllers utilizarse alguna vez sin un archivo nib/xib (es decir, un UIView creado en código)? – titaniumdecoy

+0

Personalmente, rara vez uso archivos NIB, así que sí, puede usar UIViewController y amigos sin ellos. – Alex

+0

El hecho de que -initwithNibName: bundle: es el inicializador designado de UIViewController parece indicar que no está destinado a ser utilizado sin un plumín. – titaniumdecoy

Respuesta

3

La lógica de la aplicación nunca debe ir en un UIView. Período. El propósito de un UIViewController es administrar una vista y sus subvistas y, en la mayoría de las circunstancias, es el lugar apropiado para la lógica. UIKit se adhiere al paradigma Modelo-Vista-Controlador. Los modelos contienen los datos, las vistas lo muestran y aceptan entradas, y los controladores gestionan la interacción entre las otras dos capas. Es por eso que el controlador es el lugar lógico para la lógica de la aplicación. En iOS, UIViewController y sus subclases son las clases de controlador habituales. Sugeriría reading up on Apple's guidance para comprender mejor este patrón y cómo se usa en iOS.

La cita de la documentación de Apple le dice que no crea un UIViewController para cada etiqueta o botón. Usted crea uno para cada "página" o "pantalla" de su aplicación y lo usa para administrar los controles en esa vista. Tenga en cuenta que UIKit tiene clases para administrar vistas de tablas, vistas de pestañas y vistas de navegación. Ese es el nivel de objeto que usaría UIViewController para administrar.

Recomiendo examinar los ejemplos de iOS incluidos con el SDK. Deben darle una buena idea de cómo el marco espera que las aplicaciones se estructuren.

+0

¿Qué tal un UISwitch (o cualquier otro control)? Es una subclase UIView que administra su propio estado. – titaniumdecoy

+0

Gestionar su propio estado no es lo que quiero decir con lógica. Me refiero a la lógica de la aplicación, como decidir mostrar un diálogo al usuario o guardar un archivo. Un 'UISwitch' debe saber si está activado o desactivado, pero no debería ser responsable de guardar su valor en el archivo de preferencias del usuario, por ejemplo. Ese es el trabajo de un controlador de vista. – Alex

3

Vengo del mundo de la interfaz gráfica de usuario Win32 + .NET + Java Swing y solía hacer lo mismo. Pero luego arreglé mis malos caminos. Ahora, la única vez que pongo el código en UIView es si deseo personalizar el VER MISMO (dibujo OpenGL, por ejemplo).

Los controladores establecen el estado de la vista. La vista representa su estado.

Cuestiones relacionadas