¿Por qué Apple no permite la subclasificación de UINavigationController? ¿Y cuáles son mis alternativas para crear subclases?

Question

Actualmente estoy construyendo una aplicación de iPhone con pestañas donde el controlador de vista de cada pestaña es una instancia de UINavigationController, y donde cada subcontrolador de cada una de las instancias UINavigationController es una instancia de UITableViewController. Idealmente, me gustaría crear la subclase UINavigationController para que el controlador de cada pestaña sea una subclase de UINavigationController que (además de tener todas las funciones estándar UINavigationController, obviamente) sirve como fuente de datos y delegado para cada una de las vistas de tabla asociadas con sus subcontratistas. Intentar hacer esto parece romper la funcionalidad básica UINavigationController en la subclase.

En vista de que Apple dice en su documentación iPhone que no se debe subclase UINavigationController, y las cosas parecen romperse cuando uno hace, me pregunto cómo debería ir sobre la que se extiende UINavigationController's funcionalidad sin subclases, y en términos generales, cómo uno debería trabajar alrededor de las limitaciones de subclases al hacer el desarrollo de Cocoa.

Gracias!

Answer 1

Como referencia, tenga en cuenta que desde iOS 6, UINavigationController puede ser subclasificado legalmente.

Esta clase se usa generalmente como está pero se puede subclasificar en iOS 6 y posterior. UINavigationController Class Reference

Por supuesto, eso no significa que siempre debe. Pero puedes.

Answer 2

Porque quieren evitar la incoherencia de UI que afecta a las demás plataformas.

Answer 3

¿Por qué desea que el UINavigationController actúe como fuente de datos para la tabla? El punto entero de UITableViewController es que usted lo subclase, y actúa como el origen de datos para el UITableView que también coloca y completa la vista principal.

Answer 4

Según tengo entendido, no se recomienda la creación de subclases porque Objective C permite que una subclase tenga demasiado acceso al funcionamiento interno de su superclase.

La alternativa sugerida para escribir una subclase es escribir un delegado, en este caso un UINavigationControllerDelegate. A continuación, puede encapsular el comportamiento específico que desea extender a esta clase de delegado y vincularlo al UINavigationController cada vez que lo necesite.

Answer 5

Si la jerarquía de controlador disponible no satisface sus necesidades en términos de manejo de datos (mi suposición, ya que no sabemos por qué quiere que un objeto sea el origen de datos para múltiples vistas), siempre puede crear datos adicionales y/o clases de controlador (subclases de NSObject al menos).

Puede hacer que persistan datos u otros objetos al cambiar las vistas de varias maneras. (1) una propiedad de la clase de delegado de su aplicación. Cualquier objeto en su aplicación puede obtener la instancia de delegado de la aplicación con

[[UIApplication sharedApplication] delegate] 

uso con moderación ya que es esencialmente la creación de variables globales.

(2) Puede pasar datos u otros objetos desde el controlador al controlador a medida que presiona ver las subclases del controlador o las coloca dentro de las pestañas.

(3) Core Data es otra forma, pero requiere una gran cantidad de cacao en tu haber, y aún tienes que administrar la (s) instancia (s) de contexto.

Answer 6

Voy a seguir adelante y decir que su idea tiene algún mérito, si en cada nivel usted realmente está utilizando el mismo tipo de datos y cada nivel tal vez tenga un delegado diferente para manejar la creación de células.

Básicamente no hay ninguna razón por la que no pueda subclase el controlador UINavigation para agregar una capa de datos totalmente ortogonal encima, porque no tiene nada que ver con la UI o el comportamiento que UINavigationController está administrando (que es lo que Apple está preocupando con). Para aquellos que se oponen a la idea, piense en ello como un almacén de datos por ficha al que pueden acceder todas las páginas en una pestaña, en lugar de tener que ir a AppDelegate en cada página del sistema, o tener un grupo de singletons. Bueno, básicamente es un singleton, pero al menos uno que ya está allí y obtiene la referencia transmitida automáticamente.

Dicho todo esto, finalizaré con una propuesta de diseño alternativa: creo que lo que probablemente desee hacer es profundizar en varias capas reutilizando el mismo código para generar celdas y eso porque tiene el mismo tipo de datos en cada capa. Un mejor enfoque para manejar eso es tener un controlador de vista que alimente el subconjunto de datos para mostrar, y cuando un usuario profundiza simplemente crea otra instancia del mismo controlador de vista con ese nuevo subconjunto de datos. Ese enfoque es mucho mejor que la idea de que el controlador de navegación actúe como un delegado de la mesa para cada nivel, ya que tendrías que hacer una tonelada de recableado moviéndose hacia adelante y hacia atrás y requeriría aún más trabajo para recordar la posición de desplazamiento en cada nivel para arrancar. Es por eso que desea mantener desgloses utilizando varias instancias de controladores de vista, pero varias instancias no tienen que significar múltiples clases.