[iOS] View controller의 역할

이 글은 애플 공식 문서 "The Role of View Controllers"를 번역, 의역한 것으로, view controller이 하는 일들을 대략적으로 이해하기에 좋다.

View Controller Programming Guide for iOS: The Role of View Controllers

The Role of View Controllers

View Controller들은 앱 내부 구조의 근본이다. 모든 앱은 최소 하나 이상의 view controller를 가지고 있다. 각 view controller는 다음의 것들을 관리한다:

1. 사용자 인터페이스의 일부(간단하게 말해서 그냥 view다.) 
2. 인터페이스와 사용되는 데이터간의 상호작용 
3. 사용자 인터페이스 내의 전환 

View controller가 앱에서 중요한 역할을 하기 때문에, view controller는 앱에서 중심이 된다. UIViewController 클래스의 프로퍼티와 메서드를 사용해서 다음 작업들을 할 수 있다.

1. view를 관리
2. event handling
3. 한 view controller에서 다른 view controller로의 전환
4. 앱의 다른 부분과 연결

보면 모두 view controller가 관리하는 3가지를 다른 말로 표현한 것과 같다. 이런 작업을 하고 싶으면 UIViewController나 그 subclass를 상속받아서 앱의 동작에 맞게 custom 코드를 추가하면 된다.

Type 

View Controller에는 두 종류의 타입이 있다.

• Content view controller : 개발자가 생성한 view controller의 주 타입으로, 앱의 content의 일부를 관리한다.
• Container view controller : 다른 view controller(child view controller)에서 정보를 모으고, navigation이 가능한 방법으로 이를 보여주거나 이 view controller들의 content를 다르게 보여준다. 즉 child view controller들의 content를 모아서 보여주고, 이들 사이를 navigate할 수 있게 한다는 정도를 이해하면 될 것 같다.

보통 앱은 이 두 종류의 view controller를 섞어서 만든다.

View Management

View controller의 가장 중요한 역할은 view간의 계층을 관리하는 것이다. 모든 view controller는 모든 view controller의 content를 감싸는 하나의 root view controller를 가진다. 이 root view에 content를 보여주고 싶은 view들을 추가한다.

위 그림은 view controller와 view 간의 관계 예시를 보여준다. View controller는 항상 root view를 참조하고 있고, 각 view는 subview에 강한 참조를 갖고 있다.

 

참고
outlet을 사용해서 view controller의 view 계층 내의 다른 view에 접근하는 게 일반적이다. Outlet은 view controller가 화면에 보여줄 content view에 대한 참조를 갖고 있다. Outlet은 view가 스토리보드에 로드될 때 자동으로 실제 view 객체에 연결된다.

 

• Content view controller : 자기가 자신의 view들을 관리한다.
• Container view controller : 하나 이상의 child view controller의 view들과 root view를 관리한다. 다만 컨테이너는 자식의 content를 관리하지는 않는다. 컨테이너가 디자인 된 대로 root view의 크기와 위치를 관리할 뿐이다.

위 그림은 split view controller와 자식들간의 관계를 보여준다. Split view controller는 자식 view의 전체적인 크기와 위치를 관리하지만, 이 view들의 실제 content를 관리하는 것은 자식 view controller다.

Data Marshaling

Marshaling : 컴퓨터 프로그래밍에서 marshaling은 하나 이상의 프로그램 혹은 연속되지 않은 저장 공간에서 데이터를 모은 후 이를 버퍼에 집어넣고 특정 수신기나 인터페이스에 맞도록 데이터를 조직화하거나 다른 형태로 변환하는 것을 말한다.

View controller는 자신이 관리하는 view와 앱의 데이터 사이의 중개인 같은 역할을 한다. UIViewController 클래스의 메서드, 프로퍼티를 사용해서 앱이 시각적으로 어떻게 보일 지 관리할 수 있다. UIViewControler를 상속할 때, 보통 자식 클래스 안에 있는 데이터를 관리하기 위해 변수를 추가한다.

이런 custom 변수들을 추가하는 것은 위와 같은 관계를 형성하는데, view controller가 데이터와 그 데이터를 보여주기 위한 view들을 참조하는 형태가 된다.

 

항상 view controller와 data 객체의 책임을 명확하게 분리하는 것이 중요하다. 데이터 구조들을 관리하는 로직들은 data 객체 자신에게 속해야 한다. View controller는 view에 입력되는 값들을 검증하고 이 입력 값들을 data 객체에서 요구하는 형태로 변환해야 한다. 여기에서 view controller가 실제 데이터를 다루는 역할을 최대한 축소해야 한다. (View controller의 역할은 데이터를 관리하는 것이 아니기 때문에 view controller의 작업이 데이터 관리 작업에 중점을 두면 안된다는 말이다.)

 

UIDocument 객체는 데이터를 view controller와 분리해서 관리할 수 있게 해주는 방법중에 하나다. Document 객체는 persistent storage(non-volatile, 기기가 꺼져도 데이터가 유지되는 저장소)에서 데이터를 어떻게 읽고 쓰는지 아는 controller 객체다. 이걸 상속받을 때, view controller나 앱의 다른 부분에 데이터를 추출해서 전달하는 로직과 메서드를 추가하면 된다. View controller가 view를 업데이트 하기 쉽게 받는 데이터의 복사본을 만들어 저장할 수 있지만, document는 여전히 자기 자신만의 데이터(원본 데이터)를 가지고 있다.

User Interactions

View controller들은 responder 객체이고, responder 체인에서 내려오는 이벤트를 handling할 수 있다. View controller가 직접 이벤트를 처리할 수 있긴 하지만 직접 터치 이벤트를 처리하지는 않는다. 대신 view가 자신의 터치 이벤트를 처리하고 그 결과를 관련있는 delegate나 target 객체(주로 view controller다)에 알린다. 그래서 view controller의 대부분의 이벤트는 delegate 메서드나 action 메서드에 의해 핸들링된다.

 

View controller에 action 메서드를 구현하는 것에 대해 더 자세히 알아보려면 Handling User Interactions를 보면 된다.

Resource Management

View controller는 view들과 자신이 생성하는 모든 객체에 대한 책임이 있다. UIViewController 클래스는 대부분의 view 관리를 자동으로 해준다. 예를 들어, UIKit은 자동으로 view와 관련된 자원중에서 더 이상 필요 없는 자원들을 해제한다. 만약 개발자가 명시적으로 객체를 생성한다면 이를 따로 관리해줘야 할 필요가 있다. 

 

사용가능한 메모리가 적을 때, UIKit은 더 이상 사용하지 않는 자원들을 release 되게 한다. 임의로 didReceiveMemoryWarning 메서드를 호출해서 더 이상 필요없거나 나중에 다시 재생성할 수 있는 객체들에 대한 참조를 없앨 수도 있다. 예를 들어 캐시된 데이터를 제거할 수 있다. 메모리가 적은 상황에서는 가능한 많은 메모리를 해제하는 것이 중요하다. 너무 많은 메모리를 사용하는 앱은 메모리 확보를 위해 시스템에 의해 멈춰질 수 있다.

Adaptivity

View controller들은 view를 보여주는 것과 주어진 환경에 그 view를 맞게 노출하는 것에 대한 책임이 있다. 모든 iOS 앱은 iPad와 다양한 사이즈의 iPhone에서 실행할 수 있어야 한다. 각 디바이스마다 다른 view controller와 다른 view 계층을 제공하는 것보다, 다양한 사이즈에 맞춰 적절히 나타날 수 있는 하나의 view controller를 사용하는 것이 더 간단하다.

 

iOS에서, view controller는 coarse-grained 변화와 fine-grained 변화를 처리할 필요가 있다.

 

참고
"grained" 라는 말은 무언가가 여러 요소로 만들어졌다는 말이다. 만약 구성하는 요소가 클 때, "coarse-grained" 라 하고 요소가 작을 때는 "fine-grained" 라는 말을 쓴다. 만약 알고리즘이 "fine-grained"라면 알고리즘이 작고 많은 단계로 나뉠 수 있다는 뜻이고, "coarse-grained" 라면 크고 적은 단계로 나뉜다는 뜻이 된다.

 

Coarse-grained 변화는 view controller의 특성(trait)이 변할 때 일어난다. Trait은 display 크기와 같은 전반적인 환경을 설명하는 특성이다. 가장 중요한 trait 두 가지는 다음과 같다.

1. view controller의 수평 크기 클래스
2. view controller의 수직 크기 클래스

이 둘은 view controller가 주어진 차원에서 얼마나 공간이 있는지를 나타낸다.

위 그림에서 볼 수 있듯이 size 클래스를 바꿔서 뷰를 보여주는 방법을 바꿀 수 있다. 수평 size가 regular일 때, view controller는 추가적인 수평 공간을 사용해서 컨텐츠를 배열한다. 만약 수평 size 클래스가 compact일 때, view controller는 컨텐츠를 수직으로 배열한다.

Size 클래스가 주어졌다면, 어느 때든 fine-grained size 가 바뀌는 것을 적용할 수 있다. iPhone을 세로 방향에서 가로 방향으로 회전할 때, size 클래스는 바뀌지 않을 수 있지만 화면의 차원은 주로 바뀐다. UIKit은 새로운 차원에 view를 맞게 보여주게 하기 위해 크기와 위치를 조정한다.

 

---

• 참조

View Controller Programming Guide for iOS: The Role of View Controllers

마샬링(Marshaling)이란?

Fine-Grained vs. Coarse-Grained Urbanism