ViewController

앱 화면의 콘텐츠를 표시하는 로직과 관리를 담당하는 객체

앱 구조의 뼈대로 모든 앱에는 반드시 하나 이상의 ViewController로 이루어져 있다. 

주요한 데이터의 변화에 응답으로 뷰들의 콘텐츠들을 업데이트한다.

뷰와 함께 사용자에 응답하며 이벤트를 핸들링한다.

뷰들의 사이즈 재조정과 인터베이스들의 레이아웃을 관리

다른 객체들과 함께 앱을 구성한다.

 

ViewController의 역할

1. 뷰 계층 관리

모든 ViewController마다 RootView를 지니고 있으며, 화면에 표시하기 위해서는 해당 RootView계층에 속해야 한다.

View Controller의 종류

모든 뷰를 단독으로 관리

: UIViewController, UITableViewController, UICollectionVIewController

 

자체 뷰와 하나 이상의 자식 뷰 컨트롤러가 가진 루트 뷰를 관리
컨테이너는 콘텐츠를 관리하는 것이 아닌, 루트 뷰만 관리하며 컨터이너 디자인에 따라 크기 조정

: UINavigationController, UITabbarController, UIPageViewController 등

2. 데이터 중개자 역할

 MVC(Model - View - Controller)에서 자신이 관리하는 View와 Data(Model) 사이 중간 역할

3. User Interactions

View에서 일어나는 모든 사용자 이벤트는 ViewController가, 그 후 각 뷰에 따라 관련 Action 메서드나 Delegate를 통해 처리.

ViewController는 Responder 객체로써 직접 이벤트를 받아 처리하는 것이 가능하나 일반적으로는 지양.

View가 자신의 Touch Event를 연관된 객체(보통 뷰 컨트롤러)에 Action메서드나 delegate로 전달

4. Resource Management

ViewController가 생성한 모든 뷰와 객체들은 ViewController의 책임이다.

UIViewController의 LifeCycle에 따라 생성되었다가 자동 소멸되기도 하지만 ARC 개념에 맞게 관리 필요.

메모리 부족시 didReceiveMemoryWarning 메서드에서 캐시 메모리 등 꼭 유지하지 않아도 되는 메모리들은 정리가 필요하다.

5. Adaptivity

ViewController는 뷰의 표현을 책임지고, 현재 환경에 적절한 방법으로 적용되도록 할 책임을 가진다.

ViewController의 생명주기

init

Storyboard나 Xib를 통해 ViewController를 만들 경우 ViewController의 객체가 생성될 때 초기화 작업을 하는 메서드가 바로 init

객체를 ByteStream으로 바꾸어 디스크에 저장하거나 네트워크를 통해 전송하는 직렬화 작업을 하지 않는 이상 매개변수로 넘어오는 NSCoder는 무시해도 무방 

loadView()

본격적으로 화면에 띄워질 View를 만드는 메서드로 View를 만들고 메모리에 올려준다.

일반적인 사용자는 이 메서드를 직접 호출하면 안 된다.

직접 코딩하여 만드는 경우를 제외하고서는 직접 호출하지 않는 것을 권장한다.

outlet과 action들이 이 메서드에서 생성되고 연결

viewDidLoad()

뷰의 로딩이 완료되었을 때 시스템에 의해 자동으로 호출된다. (loadView() 직후 호출됨)

그러므로 사용자에게 화면이 보이기 전 데이터를 뿌려주는 행위, 백그라운드에서 처리해주어야 하는 작업(네트워크 호출)들이 위치하기 좋다. 

이 메서드는 생에 오로지 한 번만 호출되기 때문에 한 번만 일어날 행위들에 대해서 정의해주고 주기적으로 데이터가 변경되는 행위는 다른 메서드에서 정의해준다.

viewWillAppear()

viewController의 RootView가 로드된 이후에 Window의 View계층으로 더해지기 직전 호출되는 메서드이다.

첫 화면이 띄워질 때 호출이 되는 것은 viewDidLoad()와 동일하지만, 화면 전환을 통해 다시 다시 현재의 화면으로 돌아올 때도 호출되기 때문에 다른 View에 갔다가 다시 돌아오는 상황에 해주고 싶은 처리를 이 메서드 내부에 작성해준다.

viewWillAppear와 viewDidAppear 사이에 Constraints와 layout이 적용된다.

 

didReceiveMemoryWarning()

iOS 기기들은 제한된 메모리 크기와 전원을 갖고 있는데 메모리가 채워지기 시작하면 일반적인 컴퓨터의 운영체제와는 다르게 메모리가 부족해지면 메모리의 데이터를 하드디스크로 옮기는 작업을 하지 않기 때문에 애플리케이션이 너무 많은 메모리를 사용한다면 iOS는 이를 알리게 된다.

 

ViewController가 자원 관리를 하고 있는 동안 이러한 알람들은 이 메서드를 통해 전달받는다.

이러한 방식을 통해 몇몇의 메모리를 해지하는 등의 메모리를 관리할 수 있는데, 이러한 경고 알림을 무시하고 메모리의 일정 한계치를 넘어가게 된다면 iOS는 애플리케이션을 강제로 종료하기 때문에 주의해야 한다.

viewDidAppear()

window의 rootView가 View 계층으로 더해진 직후 호출되는 메소드

ViewController의 뷰가 데이터와 함께 완전히 화면에 나타나면 호출되는 메소드

View가 나타났다는 것을 컨트롤러에게 알리는 역할을 하며, UI 내의 애니메이션을 실행하거나, 비디오나 소리를 재생하는 행위, 그리고 뿌려지는 데이터의 업데이트를 수행하게 된다.

viewWillDisappear()

window의 rootView가 View 계층에서 제거되기 직전에 호출되는 메소드

view가 삭제되려고 하는 것을 ViewController에 통지한다.

viewDidDisappear()

window의 rootView가 View계층에서 제거된 직후 호출되는 메소드

view가 제거되었음을 알려준다.

화면에서 ViewController가 사라진 이후에 멈추어야 할 작업들을 이 메서드에 작성해준다.

deinit()

다른 모든 객체와 마찬가지로 ViewController가 메모리에서 사라지기 전 이 메서드가 호출된다.

이 메서드를 할당받은 자원중 ARC에 의해 해지가 불가능한 자원들을 해제하기 위해 호출할 수 있다.

또한, 백그라운드에서 돌리기 위해 이전의 메서드에서 멈추지 못했던 행위들을 이 메소드에 멈출 수 있다.

 

ViewController가 화면에서 사라지는 것이 메모리에서 해제되는 것을 의미하지 않는다는 것을 명심해야 한다. 즉, 화며에서 사라진다고 메모리에서 해지되는 것이 아니다. 많은 ContainerViewController들이 그들의 ViewController들을 메모리에서 유지하고 있다.