¿Por qué UIPopoverController no es una subclase UIViewController?

Question

¿Puede pensar en algunas razones por las cuales Apple eligió implementar UIPopoverController como una subclase de NSObject simple? Para mí, una subclase UIViewController tendría mucho más sentido, para implementar la contención UIViewController adecuada.

Pero quizás haya razones por las que no pensé, ¿por qué los brillantes ingenieros de Apple hicieron su elección?

Answer 1

Supongo que es porque, como UIAlertView, se presenta en una nueva ventana UI, por lo que la propiedad windowLevel garantiza que se presente sobre todo el contenido.

Independientemente de si está en una nueva ventana UI, en lo que respecta a la contención del controlador de vista, no debería tener problemas para utilizar jerarquías complejas de contenedor padre-hijo en los controladores de vista que presente en un UIPopoverController. Tengo controladores de vista con al menos tres niveles de anidación en Pillboxie para algunos de los popovers, sin ningún problema.

ACTUALIZACIÓN: he comprobado la jerarquía ingresando las clases de los tres primeros niveles de la jerarquía de vistas en un proyecto de ejemplo, y es como sigue cuando un popover es visible (mi controlador de vista raíz tenía dos UIButtons) :

A VENTANA:

_SUBVIEW CLASE: UIView

___SUBSUBVIEW CLASE: UIRoundedRectButton

_ _SUB SUBSUBVIEW CLASE: UIButtonLabel

___SUBSUBVIEW CLASE: UIRoundedRectButton

_ _SUBSUBSUBVIEW CLASE: UIButtonLabel

_SUBVIEW CLASE: UIDimmingView

___SUBSUBVIEW CLASE: _UIPopoverView

_ _SUBSUBSUBVIEW CLASE: _UIPopoverStandardChromeView

_ _SUBSUBSUBVIEW CLASE: UIView

documentación de Apple afirma que la opinión del controlador de vista raíz en una UIWindow no debe tener ningún hermano Vistas a las gestionado por otros controladores de vista, porque esos controladores de vista de hermanos no van a recibir eventos de rotación (ver here , segunda viñeta).

Por lo tanto, si Apple hubiera convertido a UIPopoverController en una subclase UIViewController, tendría que agregarla como una subvista secundaria/hijo de la jerarquía de rootViewController. Pero, ¿qué sucede si el controlador de vista raíz (que es su código, de todos modos) decide presentar una vista que interfiere con la jerarquía de la vista de UIPopoverController? En lugar de dejarnos estallar, parece que Apple decidió administrar la presentación del UIPopoverController por completo, pero de tal manera que no tuvieron que otorgarse una excepción a la política de UIWindow de no-sibling-view-controllers.

Answer 2

porque los UIPopoverController objetos no interactúan con el usuario, es por ello que no es parte de la vista capa , su UIViewController es capaz de comunicarse con el usuario, el UIPopoverController no hace trabajos del mismo dentro de sí mismo.

echar un rápido vistazo el genérico definition de la Controller:

un controlador puede enviar comandos a su vista asociada a cambiar la presentación de la vista del modelo (por ejemplo, desplazándose a través de un documento). Puede enviar comandos al modelo para actualizar el estado del modelo (por ejemplo, edición de un documento).

que explica por qué no es parte de la Ver capa, espero que ayude.