![[iOS] ViewController life cycle (feat. push(pop), present(dismiss) )](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FPgzYU%2FbtsnDxJaF6E%2FpSyBBVVxMliTWj8LAOAv0K%2Fimg.jpg)
ViewController Life Cycle
- loadView
- 뷰컨이 관리하는 뷰를 만들 때 호출된다.
- 현재 뷰가 없을 때 호출하고, 뷰가 다 만들어지면 해당 뷰를 뷰컨의 뷰로 설정한다.
- viewDidLoad
- View Controller가 생성될 때 처음 한 번만 호출된다.(VC의 라이프 사이클에서 한번 호출)
- 뷰컨의 뷰가 메모리에 올라가고 난 뒤에 호출된다.
- 해당 메소드는 Bounds가 결정되거나, 회전이 일어나기 전에 호출된다.
- viewWillAppear
- View 계층 구조에 추가되기 직전
- 다른 뷰에 갔다가 다시 돌아오는 상황에서 호출이된다.
- Bounds가 결정되고 난 후에 호출이된다.
- viewIsAppearing
- 메인 뷰의 레이아웃과 뷰 trait collection들이 업데이트 된 후 직후입니다.(+ 계층구조에 추가된 이후입니다.)
- trait collections ⇒ 앱의 인터페이스 및 레이아웃을 다양한 디바이스 및 환경에서 자동으로 조정하기 위한 속성의 집합, 사용자 interface 환경에 대한 정보를 제공하고, 화면 크기, 방향, 디스플레이 타입 등과 같은 특성을 포함한다. 앱은 해당 속성의 변경 사항을 감지하여 적절한 레이아웃 및 디자인 변경을 수행할 수 있습니다.
- 뷰가 계층 구조에 추가되어 정확한 모양(size, safe area)을 가졌을 때 호출됩니다.
- viewWillAppear와 동일한 CATransaction 내에서 호출이된다. 따라서 두 메소드에서 변경된 사항은 동시에 user에게 보이게 됩니다.
- CATransaction ⇒ Core Animation 프레임워크에서 제공하는 클래스로, 애니메이션 및 뷰 계층 구조의 변경과 같은 액션들을 트랜잭션으로 그룹화하여 관리하는 데 사용합니다. 즉, 한 메서드에서 설정한 애니메이션은 다른 메서드에서도 사용할 수 있습니다. 예를 들어, viewWillAppear에서 뷰의 애니메이션 속도를 설정하면, viewIsAppearing에서 설정한 애니메이션 속도와 동일하게 적용됩니다.
- 아래의 layoutSubviews와는 다르게 스타일 전환 중에 한 번만 호출이된다.
- 하위 뷰의 레이아웃이 필요 없어도 여전히 호출됩니다.(Layout이 잡힐 때만 호출되는 아래의 메소드들과는 다르게!)
- transition의 첫 프레임부터 변경이 들어가면서 view의 사이즈가 정확할 때이므로 view가 보이고 난 뒤에 UI를 업데이트하기에 최적의 장소이다.
- 메인 뷰의 레이아웃과 뷰 trait collection들이 업데이트 된 후 직후입니다.(+ 계층구조에 추가된 이후입니다.)
- viewWillLayoutSubviews
- 뷰의 bounds가 변경될 때, 자신의 서브 뷰들의 위치를 조정합니다.
- 뷰컨은 뷰가 자신의 서브 뷰들의 레이아웃을 결정하기 전에 변화를 주기위해서 사용할 수 있습니다.
- 여러 번(자주) 호출이되거나 나중에 뷰 가 보일 때 언제든지 일어날 수 있습니다.
→ 이 사이에 layoutSubViews가 실행되어 subview들의 레이아웃이 설정된다.
- viewDidLayoutSubviews
- 서브 뷰들의 레이아웃 설정이 완료된 후에 호출이된다.
- 여러 번(자주) 호출이되거나 나중에 뷰가 보일 때 언제든지 일어날 수 있습니다.
- viewDidAppear
- View 계층 구조에 추가된 후
- 데이터를 저장하거나, animation을 시작하거나, 비디오나 소리를 시작을 해당 메소드에서 하면 됩니다.
- viewWillDisappear
- View 계층 구조에서 사라지기 직전
- 키보드를 가리거나, 네트워크 요청을 취소하거나, 부모 UI를 변경하고 싶을 때 해당 메소드에서 하면 됩니다.
- 뷰 컨트롤러의 상태를 저장하기에도 적합니다.
- viewDidDisappaer
- View 계층 구조에서 사라진 직후
- Notification 및 디바이스 센서를 그만 수신하고 싶을 때 해당 메소드에서 하면 됩니다.
- viewWillTransition(to:with:)
- 인터페이스의 방향이 변경되었을 때 사이즈 변경이 일어나기 전에 해당 메소드를 호출합니다.
Modal의 View Life Cycle
First VC에서 Second VC로 present가 되었다가, 다시 dismiss되는 상황을 가정해보자!
현재 modal의 default는 .automatic이다.
- 세로 모드 -> pageSheet
- 가로 모드 -> fullScreen
.fullScreen시
- present가 되면, First VC가 없어진다!
- Second VC로 present마다 viewDidLoad() 호출!
- 그렇다고, 다시 SecondVC가 dismiss될 때 FirstVC의 viewDidLoad()가 되지는 않는다!
만약 A 컨트롤러에서 B 컨트롤러가 이동을 한다면 아래와 같은 순서로 진행된다.
- B viewDidLoad
- A viewWillDisappear
- B viewWillAppear
- B viewDidAppear
- A viewDidDisappear
- B viewWillDisappear
- A viewWillAppear
- A viewDidAppear
- B viewDidDisappear
.pagingSheet시
-First VC가 뒤에 보이기에 제거가 되지 않는다.
-Second VC로 갈 때마다 viewDidLoad() 호출
📌 First VC → Second VC → First VC → Second VC를 해도 똑같은 결과가 나온다!(즉, 반복해도 같은 결과)
만약 A 컨트롤러에서 B 컨트롤러가 이동을 한다면 아래와 같은 순서로 진행된다.
- B viewDidLoad
- B viewWillAppear
- B viewDidAppear
- B viewDidAppear
- B viewWillDisappear
- B viewDidDisappear
Navigation ViewController의 View life Cycle
- navigation view controller의 경우, push pop을 하므로 Second VC로 넘어갈 때마다 viewDidLoad()가 계속 불리게 된다
- pop이 되면 메모리에서 삭제가 되기 때문이다!
- First VC의 경우, root View Controller이므로 계속 메모리에 존재해야한다. 따라서 SecondVC에서 First VC로 pop이 되어도 viewDidLoad()가 호출되지 않는다!
만약 A 컨트롤러에서 B 컨트롤러가 이동을 한다면 아래와 같은 순서로 진행된다.(push, pop)
(fullScreen과 조금 다르다!)
- B viewDidLoad
- A viewWillDisappear
- B viewWillAppear
- A viewDidDisappear
- B viewDidAppear
- B viewWillDisappear
- A viewWillAppear
- B viewDidDisappear
- A viewDidAppear
'iOS' 카테고리의 다른 글
| [iOS] Queue 구현하기 (0) | 2023.02.04 |
|---|---|
| [iOS] Priority(Autolayout) (0) | 2023.02.03 |
| [iOS] prepareForReuse() (0) | 2023.02.03 |
| [iOS] TableView의 reloadData()란? (0) | 2023.02.03 |
| [iOS] iOS 프로젝트 파일 폴더링 (0) | 2023.02.03 |