¿Cuáles son los beneficios de usar un UINavigationController para agregar una vista con addSubView?

Digamos que tengo dos páginas con dos UIViewControllers , UIViewController1 y UIViewController2 .

Si quiero mostrar un UIViewController2 en la parte superior de UIViewController1 , tengo tres opciones:

  1. utilizando UINavigationController pushViewController .
  2. usando presentViewController .
  3. addSubView : UIViewController1.view.addSubView(UIViewController2.view)

Si necesito una transición entre mis puntos de vista, prefiero la tercera opción porque me da mucho más control sobre las vistas.

¿Hay alguna diferencia entre estas tres opciones en términos de performance?

Solo para dos controlleres de vista, no creará una gran diferencia. UINavigationController se utiliza principalmente para mantener la stack de navigation.

Pero como solo tiene dos controlleres de vista, también puede usar una alternativa.

Si está buscando transiciones con NavigationController, puede utilizar UIView Transitions para la personalización de la animation push pop.

Consulte los siguientes enlaces para Transiciones UIView

https://www.objc.io/issues/12-animations/custom-container-view-controller-transitions/

http://www.raywenderlich.com/86521/how-to-make-a-view-controller-transition-animation-like-in-the-ping-app

https://www.captechconsulting.com/blogs/ios-7-tutorial-series-custom-navigation-transitions–more

http://applidium.github.io/ADTransitionController/

El uso de un controller de navigation mantendrá una stack de navigation dentro del self.navigationController navigation principal self.navigationController

Esto mantendrá el flujo de sus controlleres de vista y las salidas débiles y las references se ubicarán en ARC y mantendrán la memory.

Un enfoque similar sería hacer que su controller de vista actual sea su controller de vista de destino.

  [self presentModalViewController:viewController2 animated:YES]; 

Antes de iOS 6, se suponía que no debías hacer la opción 3. Los controlleres de vista tenían la intención de controlar toda la pantalla. En iOS 6, Apple agregó soporte para los controlleres de vista padre e hijo. Puede hacer que otra vista controle a su hijo y agregar sus vistas de contenido a la suya.

Si vas a usar la opción 3, entonces eso es lo que debes hacer. Si no lo hace, tendrá una variedad de problemas.

Incluso hay compatibilidad para el controller de vista padre / hijo integrado en storyboards. Puede agregar una vista de contenedor a un controller de vista y, a continuación, controlar el arrastre desde la vista de contenedor a la escena de otro controller de vista. Cuando lo hace, el sistema crea una "inserción segue" que configura el controller de vista secundario dentro de la vista de contenedor y configura la relación padre / hijo por usted.

Sus primeras 2 opciones son para cuando desee que el nuevo controller de vista reemplace, o al less cubra, el primer controller de vista. La opción 3 es para cuando desee que una región de su pantalla sea administrada por otro controller de vista.

La opción 3 (usar un controller de vista secundaria) significa que ambos controlleres de vista estarán activos y en memory al mismo time, por lo que no puede liberar el almacenamiento de datos del controller de vista cubierto mientras esté inactivo como puede hacerlo en una presentación push o modal . Sin embargo, a less que sus controlleres de vista contengan y presenten grandes estructuras de datos, esto no es una gran preocupación. Tanto en una presentación push como en una presentación modal, el controller de vista cubierto se mantiene en la memory de todos modos, a la espera de ser descubierto. Debe tomar medidas especiales para liberar memory mientras la vista de un controller de vista está cubierta y luego volver a asignarla cuando se muestre de nuevo, algo que es inusual.