Buscando comprender el ciclo de vida del UIViewController de iOS

este problema se puede resolver de diversas formas, pero nosotros te damos la que para nosotros es la resolución más completa.

Solución:

Todos estos comandos son llamados automáticamente por iOS en los momentos apropiados cuando carga / presenta / oculta el controlador de vista. Es importante tener en cuenta que estos métodos se adjuntan a UIViewController y no a UIViews mismos. No obtendrá ninguna de estas funciones solo con un UIView.

Hay gran documentación en el sitio de Apple aquí. Poniendo en simplemente sin embargo:

• ViewDidLoad – Se llama cuando crea la clase y la carga desde xib. Excelente para la configuración inicial y el trabajo de una sola vez.

• ViewWillAppear – Llamado justo antes de que aparezca su vista, bueno para ocultar / mostrar campos o cualquier operación que desee que ocurra cada vez antes de que la vista sea visible. Debido a que puede estar yendo y viniendo entre vistas, esto se llamará cada vez que su vista esté a punto de aparecer en la pantalla.

• ViewDidAppear – Llamado después de que aparece la vista: excelente lugar para iniciar animaciones o la carga de datos externos desde una API.

• ViewWillDisappear/DidDisappear – Misma idea que ViewWillAppear/ViewDidAppear.

• ViewDidUnload/ViewDidDispose – En Objective-C, aquí es donde haces tu limpieza y liberación de cosas, pero esto se maneja automáticamente, por lo que no es mucho lo que realmente necesitas hacer aquí.

ACTUALIZACIÓN: ViewDidUnload quedó obsoleto en iOS 6, por lo que actualizó la respuesta en consecuencia.

El ciclo de vida de UIViewController está diagramado aquí:

La ventaja de usar Xamarin Native / Mono Touch es que usa las API nativas, por lo que sigue el mismo ciclo de vida de ViewController que encontraría en la documentación de Apple.

Esto es para las últimas versiones de iOS (modificadas con Xcode 9.3, Swift 4.1). A continuación se muestran todas las etapas que hacen que el ciclo de vida de un UIViewController completo.

• loadView()

• loadViewIfNeeded()

• viewDidLoad()

• viewWillAppear(_ animated: Bool)

• viewWillLayoutSubviews()

• viewDidLayoutSubviews()

• viewDidAppear(_ animated: Bool)

• viewWillDisappear(_ animated: Bool)

• viewDidDisappear(_ animated: Bool)

Déjame explicarte todas esas etapas.

1. loadView

Este evento crea / carga la vista que administra el controlador. Puede cargarse desde un archivo nib asociado o desde un archivo vacío. UIView si null fue encontrado. Esto lo convierte en un buen lugar para crear sus vistas en código mediante programación.

Aquí es donde las subclases deben crear su jerarquía de vista personalizada si no están usando una plumilla. Nunca debe llamarse directamente. Solo anule este método cuando cree vistas mediante programación y asigne la vista raíz a la view propiedad No llamar al supermétodo cuando anula loadView

2. loadViewIfNeeded

Si en caso de que la vista de la corriente viewController aún no se ha configurado, entonces este método cargará la vista, pero recuerde, esto solo está disponible en iOS> = 9.0. Entonces, si es compatible con iOS <9.0, no espere que entre en escena.

Carga la vista del controlador de vista si aún no se ha configurado.

3. viewDidLoad

los viewDidLoad El evento solo se llama cuando la vista se crea y se carga en la memoria, pero los límites de la vista aún no están definidos. Este es un buen lugar para inicializar los objetos que va a utilizar el controlador de vista.

Se llama después de que se haya cargado la vista. Para los controladores de vista creados en código, esto es después de -loadView. Para los controladores de vista desarchivados de una plumilla, esto es después de que se establece la vista.

4. viewWillAppear

Este evento notifica al viewController siempre que la vista aparezca en la pantalla. En este paso, la vista tiene límites que están definidos pero la orientación no está establecida.

Se llama cuando la vista está a punto de hacerse visible. Default no hace nada.

5. viewWillLayoutSubviews

Este es el primer paso del ciclo de vida en el que se finalizan los límites. Si no está utilizando restricciones o diseño automático, probablemente desee actualizar las subvistas aquí. Esto solo está disponible en iOS> = 5.0. Entonces, si es compatible con iOS <5.0, no espere que entre en escena.

Se llama justo antes de que se invoque el método layoutSubviews de la vista del controlador de vista. Las subclases se pueden implementar según sea necesario. El valor predeterminado es nop.

6. viewDidLayoutSubviews

Este evento notifica al controlador de vista que se han configurado las subvistas. Es un buen lugar para realizar cambios en las subvistas después de que se hayan establecido. Esto solo está disponible en iOS> = 5.0. Entonces, si es compatible con iOS <5.0, no espere que entre en escena.

Se llama justo después de que se invoca el método layoutSubviews de la vista del controlador de vista. Las subclases se pueden implementar según sea necesario. El valor predeterminado es nop.

7. viewDidAppear

los viewDidAppear El evento se activa después de que la vista se presenta en la pantalla. Lo que lo convierte en un buen lugar para obtener datos de un servicio de backend o una base de datos.

Se llama cuando la vista se ha transferido completamente a la pantalla. El valor predeterminado no hace nada

8. viewWillDisappear

los viewWillDisappear evento se dispara cuando la vista de presentado viewController está a punto de desaparecer, descartar, cubrirse o esconderse detrás de otros viewController. Este es un buen lugar donde puede restringir sus llamadas de red, invalidar el temporizador o liberar objetos que están vinculados a eso viewController.

Se llama cuando la vista se descarta, se cubre o se oculta.

9. viewDidDisappear

Este es el último paso del ciclo de vida que cualquiera puede abordar, ya que este evento se activa justo después de la vista de presentado. viewController ha sido desaparecido, despedido, cubierto u oculto.

Llamado después de que la vista fue descartada, cubierta u oculta de otra manera. El valor predeterminado no hace nada

Ahora según manzana cuando esté implementando estos métodos, debe recordar llamar super implementación de ese método específico.

Si crea una subclase de UIViewController, debe llamar a la superimplementación de este método, incluso si no está utilizando un NIB. (Para su comodidad, el método init predeterminado hará esto por usted y especificará nil para los argumentos de ambos métodos). En el NIB especificado, el proxy del propietario del archivo debe tener su clase configurada en su subclase del controlador de vista, con la salida de vista conectado a la vista principal. Si invoca este método con un nombre de plumilla nulo, entonces esta clase ‘ -loadView El método intentará cargar un NIB cuyo nombre sea el mismo que el de la clase de su controlador de vista. Si no existe tal NIB, entonces debe llamar -setView: antes de -view se invoca, o anula el -loadView método para configurar sus vistas programáticamente.

Espero que esto haya ayudado. Gracias.

ACTUALIZAR – Como @ThomasW señaló dentro del comentario viewWillLayoutSubviews y viewDidLayoutSubviews también se llamará en otros momentos cuando se carguen subvistas de la vista principal, por ejemplo, cuando se carguen celdas de una vista de tabla o vista de colección.

ACTUALIZAR – Como @Maria señaló dentro del comentario, descripción de loadView fue actualizado

Si entiendes que ha sido provechoso nuestro artículo, nos gustaría que lo compartas con el resto desarrolladores y nos ayudes a difundir este contenido.

---

---

Utiliza Nuestro Buscador