뷰

 

목차

1장. 뷰콘트롤러의 개요

2장. 커스텀뷰 콘트롤러

3장. 네비게이션 콘트롤러

4장. 탭바 컨트롤러

5장. 모달뷰 컨트롤러

6장. 뷰컨트롤러 인터페이스의 조합

1장.

뷰콘트롤러의 종류

대부분의 아이폰 어플리케이션에는 적어도 하나의 뷰콘트롤러가 포함되어 있다. 복수의 뷰콘트롤러를 가지는 어플리케이션도 있다. 크게 이야기 하면 뷰콘트롤러는 어플리케이션에서 부가하는 역할에 응해서 크게 세개의 카테고리로 분류된다. 

커스텀뷰 컨트롤러는 무언가에 컨텐츠를 화면에 표시하는 목적으로 특별하게 정의된 컨트롤러 오브젝트이다. 대부분의 아이폰 어플리케이션에서는 표시방법이 다른 복수의 화면을 사용하여 데이터를 표시한다. 예를들면 어떤화면이 테이블 형식으로 항목의 리스트를 표시하고 별도의 화면은 그 리스트 안의 하나의 항목에 관한 상세정보를 표시한다. 이러한 어플리케이션에 대응하는 아키텍처에서는 화면의 타입별로 데이터의 마셜링 이라던지 표시를 관리하는 별도의 뷰콘트롤러를 작성할 필요가 있다.

컨테이너 콘트롤러는 별도의 뷰 콘트롤러를 관리하고 그것들 간의 네비게이션 관계를 정의하는 특수한 뷰 콘트롤러 오브젝트이다. 네비게이션 콘트롤러와 탭바 콘트롤러는 어느쪽도 콘테이너 뷰콘트롤러의 예이다. 통상은 컨테이너 뷰 콘트롤러를 개발자가 정의하는 일은 없다. 대신에 시스템이 제공하는 컨테이너 뷰 콘트롤러를 그대로 사용한다. 이것은 여러가지 컨테이너 뷰 콘트롤러가 특정한 타입의 인터페이스의 완전한 실장을 제공하기 때문이다. 

모달 뷰 콘트롤러는 별도의 뷰 콘트롤러에 의해 특정한 방법으로 표시되는 임의에 뷰 콘트롤러이다.(컨테이너이든지 커스텀이든지 관계없이) 모달 뷰 콘트롤러는 어플리케이션 안의 특정한 네이게이션 관계를 정의한다. 뷰 콘트롤러를 모달모드로 표시하는 가장 일반적인 목적은 유저에게 무언가의 데이터 입력을 요구할 때 이다. 예를 들면 유저에게 폼 입력을 받거나 피커로부터 옵션을 입력 받거나 할 때이다. 단 모달 뷰 콘트롤러에는 그 밖에 용도도 있다. 

커스텀 뷰 콘트롤러의 개요

커스텀 뷰 콘트롤러는 어플리케이션의 컨텐츠를 위해서 연계해서 동작하는 주요한 오브젝트이다. 대부분 모든 어플리케이션은 적어도 하나의 커스텀 뷰 콘트롤러를 가지고 있다. 복잡한 어플리케이션에서는 복수의 커스텀 뷰 콘트롤러를 가지는 일도 있다. 커스텀 뷰 콘트롤러에는 어플리케이션의 데이터와 뷰 사이의 통신을 지원하기 위해서 필요한 로직과 글루코드가 포함되어 있다.  뷰 콘트롤러는 어플리케이션 안의 다른 콘트롤 오브젝트(어플리케이션 델리게이트라든지 다른 뷰 콘트롤러 등)와 통신을 하는 일도 있다. 각각의 커스텀 뷰 콘트롤러 오브젝트는 딱 한 화면에 상당하는 컨텐츠의 관리를 담당한다. 뷰 콘트롤러와 화면이 일대일로 대응되는 일은 어플리케이션의 설계에 있어서 아주 중요하다. 같은 화면의 별개의 부분을 관리하기 위해서 복수의 커스텀 뷰 콘트롤러를 사용해야만 하는 건 아니다. 그와 같이 복수의 화면에 상당하는 컨텐츠를 관리하기 위해서 단독의 커스텀 뷰 콘트롤러를 사용해야만 하는 건 아니다. 

주)하나의 화면을 복수의 영역으로 분할하여 각 영역을 각각 관리하는 경우는 뷰 콘트롤러 오브젝트에서가 아니라 범용 콘트롤러 오브젝트(NSObject 에서 파생된 커스텀 오브젝트)를 사용하여 그 화면에 각 영역을 관리한다. 그리고 하나의 뷰 콘트롤러를 사용하여 범용 콘트롤러 오브젝트들을 관리한다. 이 뷰 콘트롤러는 화면전체의 조작통신을 조절 하지만 필요에 의해서 관리하에 있는 범용 콘트롤러 오브젝트에게 메시지를 전송한다. 

커스텀 뷰 콘트롤러를 작성하는 데에는 UIView 콘트롤러에서 직접 서브 클래스를 작성하여 그 서브 클래스에 커스텀 코드를 추가한다. 전형적인 UIView 콘트롤러의 서브 클래스 선언에는 다음과 같은 요소가 포함된다. 

-대응하는 뷰에 의해 표시되는 데이터를 포함하는 오브젝트를 가르키는 멤버변수

-이 뷰 콘트롤러가 통제하지 않으면 안되는 주요한 뷰 오브젝트를 가르키는 멤버변수(아웃렛)

-뷰 계층 안의 버튼이나 그 밖에 컨트롤러 관련된 테스크를 실행하는 액션 메서드 

-이 뷰 콘트롤러의 동작을 실장하기 위해서 필요한 추가 메서드 

이러한 종류의 뷰 콘트롤러의 대부분의 코드는 커스텀 컨텐츠를 관리하기 위해서 사용하는 일에서 부터 어플리케이션 고유의 것이 된다. 한편, 모든 뷰 콘트롤러가 서포트하는 공통의 동작도 있다. 이러한 공통의 동작에 대해서는 UIView 콘트롤러 클래스에 매서드가 정의되어 있다. 개발자는 희망하는 동작을 실장하기 위해서 이 메서드를 오브라이드 해서 사용할 수 있다. 공통의 동작에는 뷰의 관리, 인터페이스를 향한 관리 메모리 부족의 경고의 서포트가 포함된다. 

테이블 뷰 콘트롤러의 개요

UITable 뷰 콘트롤러 클래스는 테이블 형식의 데이터를 관리하기 위해서 특별히 설계된 커스텀 뷰 콘트롤러다. 테이블 뷰 콘트롤러를 사용하지 않아도 테이블 관리는 가능하지만 이 클래스는 선택의 관리, 행의 편집, 테이블의 설정 등의 표준적인 테이블 관련 동작에 대한 서포트기능을 자동적으로 추가한다. 이 추가 서포트 기능에 의해 테이블 베이스의 인터페이스 작성하여 초기화 하기 위한 기술하지 않으면 안되는 코드의 양을 최소한으로 줄이는 일이 가능하다. 테이블 뷰 콘트롤러는 커스텀 뷰 콘트롤러를 사용하는 것과 같은 장소에서 사용할 수 있다. 또 테이블 뷰 콘트롤러의 서브 클래스를 작성하여 추가적인 커스텀 동작을 실장하는 일도 가능하다. 물론, 이러한 뷰 콘트롤러에서 관리되는 뷰 계층에는 테이블 뷰 오브젝트가 하나 포함되어 있지 않으면 안된다.

네비게이션 콘트롤러의 개요

네비게이션 콘트롤러는 계층적으로 구성된 데이터를 표시하기 위해서 사용하는 컨테이너 뷰 콘트롤러이다. 네비게이션 콘트롤러는 UI네비게이션 클래스의 인스턴스이다. 이 클래스는 그대로 사용할 수 있기 때문에 서브 클래스를 작성할 필요가 없다. 이 클래스의 메서드는 커스텀 뷰 콘트롤러의 컬렉션을 스택베이스로 관리하는 기능을 지원하고 있다. 이 스택은 계층적인 데이터의 안을 유저가 통한 경로를 반영한다. 스택의 가장 아래는 출발점을 나타내고 스택의 가장위는 데이터 안의 유저의 현재위치를 나타낸다. 

네비게이션 컨트롤러의 주 기능은 다른 뷰 콘트롤러의 관리자로서 역할 이지만 몇개의 뷰 관리도 한다. 구체적으로 말하면 네비게이션 콘트롤러는 네비게이션 바를 하나 관리 한다. 네비게이션 바에는 데이터 계층 내의 유저의 현재 위치에 대한 정보, 전 화면 돌아가기 위한 현재 뷰 콘트롤러 에서 필요한 커스텀 콘트롤러가 표시된다. 또 네비게이션 콘트롤러는 현재의 화면에 관련된 커멘드를 표시하기 위한 사용하는 오브젝 옵션 툴바의 관리도 한다. 대부분의 경우 이 뷰들을 직접 변경할 필요는 없지만 UIView 콘트롤러 클래스에 정의 되어있는 서포트기능을 이용해서 이 뷰들을 설정하는 일이 가능하다.  

탭바콘트롤러 개요

탭바콘트롤러는 어플리케이션을 두 개 이상의 조작모드로 분할 하기 위해서 사용하는 컨테이너 뷰 콘트롤러이다. 탭바콘트롤러는 UI탭바콘트롤러 클래스의 인스턴스이다. 이 클래스는 그대로 사용이 가능하기 때문에 서브 클래스를 작성할 필요가 없다. 탭바 콘트롤러의 모드는 탭바 뷰를 사용해서 표시된다. 탭바 뷰에는 서포트하는 모드별로 하나의 탭이 표시된다. 탭을 선택하면 그것에 대응하는 뷰 콘트롤러에 의해 그 인터페이스가 화면에 표시된다. 

어플리케이션에서 다른 종류 데이터 표시 할 때라든지 같은 데이터 라도 전혀다른 방법으로 표시할 때 탭바콘트롤러를 사용한다. 탭바 콘트롤러에는 탭바 뷰 에서의 유저 의 탭에 응답하여 자동적으로 모드를 전환하는 기능이 있다. 모드 수가 너무 많아 탭 용의 스페이스 안에 들어가지 않을 때는 탭바 콘트롤러가 표준에서는 표시하지 않는 탭의 선택 이라든지 표시하는 탭의 커스텀마이즈 관리도 한다.

모달뷰 콘트롤러의 개요

모달뷰 콘트롤러라는 것은 특정한 종류의 뷰 콘트롤러 클래스가 아니라 뷰콘트롤러를 유저에게 표시하는 방법의 하나이다. 컨테이너 뷰 콘트롤러는 관리하의 있는 뷰콘트롤러간의 특정한 관계를 정의 하지만 모달뷰 콘트롤러를 이용하면 개발자가 이 관계를 정의할 수 있다. 어떤 뷰 콘트롤러 오브젝트도 다른 뷰 콘트롤러 오브젝트를 모달모드로 표시할 수 있다. 대부분의 경우는 유저로 부터 정보를 얻거나 특정한 목적으로 유저의 주의를 끌기위해서 뷰 콘트롤러를 모달모드로 표시한다. 그 목적이 달성되면 모달 뷰 콘트롤러를 닫고 유저가 어플리케이션 안의 이동할 수 있게 한다. 

모달모드로 표시되는 뷰콘트롤러 자신이 다른 뷰 콘트롤러를 모달모드로 표시할 수 있는 것도 주목할 만 하다. 모달 뷰 콘트롤러를 연쇄시키는 일이 가능한 기능은 복수의 모달액션을 순번으로 실행할 필요가 있을 때 도움 된다. 

아이폰 어플리케이션 용의 템플릿의 대부분은 적어도 하나의 뷰 콘트롤러 클래스를 처음부터 제공한다. 그리고 복수의 뷰 콘트롤러를 제공하는 템플릿도 있다. 이 초기 클래스들은 전형적인 뷰 콘트롤러에 필요한 코드를 제공하여 어플리케이션을 바로 쓰기 시작할 수 있게 설계 되어 있다. 그러나 템플릿은 단지 출발점에 지나지 않는다.

템플릿 어플리케이션의 목적은 특정한 종류의 어플리케이션의 착수하기 위해서 최적의 방법을 표시해 준다. 이것으로 작성하려하는 인터페이스의 가장 가까운 템플릿을 이용하여 시작하는 것이 가장쉽다. 

**********************************

커스텀 뷰 콘트롤러

커스텀 뷰 콘트롤러는 어플리케이션의 컨텐츠를 표시하기 위해 사용한다. 어떤 뷰 콘트롤러도 어떠한 컨텐츠의 표시를 관리하고 어플리케이션의 기반이 되는 데이터 오브젝트에 기초하여 컨텐츠를 변경하거나 동기화 한다. 커스텀 뷰 콘트롤러에서는 그것을 위해 컨텐츠를 표시하는 뷰를 작성하고 그 뷰의 컨텐츠와 어플리케이션의 데이터 구조를 동기화 하기위해서 필요한 인프라 스트럭처를 실장하지 않으면 안된다.

UIView 콘트롤러 클래스는  (커스텀이든지 아니든지 상관없이) 모든 뷰 콘트롤러에 필요한 기본적인 동작을 제공한다. 이 장에서는 이 클래스가 제공하는 기본적인 동작에 대해서 설명하고 어플리케이션의 니즈에 맞춘 이러한 동작들을 변경하는 방법도 제시한다. 이 동작들과 그것을 변경하는 방법을 이해하는 것은 어플리케이션의 커스텀 뷰 콘트롤러를 실장하기 위해서 불가결하다. 또 어떤 종류의 뷰 콘트롤러와 통신하는 경우에도 도움이 된다. 

커스텀 뷰 콘트롤러의 구조

UIView 콘트롤러 클래스는 모든 커스텀 뷰 콘트롤러를 실장하기 위해서 기본적인 인프라 스트럭처를 제공한다. UIView 콘트롤러 클래스의 인스턴스를 작성하여 뷰를 표시하는 일도 가능하지만 무언가 특별한 것을 실행하고 싶을 경우에는 커스텀 서브클래스를 정의할 필요가 있다. 그 서브클래스에서 커스텀 매서드를 사용하여 뷰에 데이터를 포함시키거나 버튼이나 그 밖의 콘트롤러에 대한 탭에 응답한다. 단 뷰 콘트롤러의 디폴트 동작에 변경을 가하고 싶을때에는 UIView 콘트롤러 매서드를 오브라이드 할 필요가 있다. 그리고 희망하는 동작을 실장하기 위해서 다른 UI킷 클래스와의 통신이 필요할 때도 있다.

그림 2-1 (23쪽) 

커스텀 뷰 콘트롤러에 직접 관련되는 주요한 오브젝트를 나타낸다. 이 오브젝트들은 실질적으로는 뷰 콘트롤러 자신이 소유하고 관리한다. 뷰(뷰 프로퍼티를 개재하여 엑세스 가능)는  뷰 콘트롤러에게 제공하지 않으면 안되는 유일한 오브젝트이다. 단, 대부분의 뷰 콘트롤러는 표시할 필요가 있는 데이터를 포함하는 커스텀 오브젝트를 가지고 있다. 그 밖의 오브젝트는 네비게이션 바 인터페이스나 탭바 인터페이스 등의 기능을 서포트할 필요가 있을 때 만 사용한다. 그래도 대부분의 오브젝트는 충분한 디폴트 동작을 제공한다. 

뷰 콘트롤러가 단독으로 동작하는 일은 거의 없지만 커스텀 뷰 콘트롤러는 항상 독립적인 오브젝트로서 설계해야만 한다. 즉, 뷰 콘트롤러에는 하나의 화면에 상당하는 컨텐츠의 관리에 관한 모든 동작을 캡슐화 할 필요가 있다. 뷰 콘트롤러에는 필요한 데이터 (또는 적어도 관리하에 두는 데이터에의 참조 ), 그 데이터의 표시에 필요한 뷰, 시스템 내의 변화에 대응하기 위한 로직, 유저와의 통신을 검증하거나 처리하기위한 코드포함되어 있지 않으면 안된다. 뷰 계층이나 데이터모델의 일부를 관리하기 위해 필요한 모든 커스텀 오브젝트는 뷰 콘트롤러로 작성하여 안전하게 관리하지 않으면 안된다. 

커스텀 뷰 콘트롤러의 실장 체크리스트

어플리케이션의 커스텀 뷰 콘트롤러를 실장하기 위해서는 xcode를 사용하여 소스를 준비한다. 대부분의 아이폰 프로젝트 템플릿에는 적어도 하나의 뷰 콘트롤러 클래스가 포함되어 있다. 그리고 필요하면 xcode로 신규의 뷰 콘트롤러를 작성할 수 있다. 독자적으로 작성한 커스텀 뷰 콘트롤러에서, 꼭 실행하지 않으면 안되는 작업이 있다. 

- 뷰 콘트롤러에서 로드할 뷰를 설정한다.

-뷰 콘트롤러에서 서포트하는 방향을 결정한다.

-뷰 콘트롤러에서 관리할 메모리를 클린 업 한다.

뷰 콘트롤러의 뷰를 설정할 때는, 액션 메서드나 그 뷰를 사용하는 아울렛을 정의할 필요가 있을지도 모른다. 예를 들면 뷰 계층에 테이블이 포함되어 있는 경우에는 그 테이블에의 포인트를 아웃렛에 포함시켜 뒤에 그것에 접근할 수 있게 한다. 그와 같이 뷰 계층의 버튼이나 그 밖의 콘트롤러가 포함되어 있는 경우는 유저와의 통신에 응답하여 그 콘트롤러부터 대응하는 액션 메스드를 호출하도록 한다. 다음과 같은 항목을 뷰 콘트롤러에 추가할 필요가 있다. 

-대응하는 뷰에 따라 표시되는 데이터를 포함하는 오브젝트를 가르키는 맴버변수

-그 뷰 콘트롤러가 통신하지 않으면 안되는 주요한 뷰 오브젝트를 가르키는 맴버변수(아웃렛)

-뷰 계층 내의 버튼 이나 그 밖의 콘트롤러에 관련된 테스크를 실행하는 액션 매서드

-이 뷰 콘트롤러의 커스텀 동작을 실장하기 위해 필요한 추가적인 매서드

중요: 아웃렛이나 그 밖의 맴버변수를 커스텀 뷰 콘트롤러에 추가할 때는 접근하려고 생각하고 있는 각각의 변수용 선언할 때 프로퍼티를 포함하는 것을 강추한다. 선언할 때 프로퍼티를 설정하는 것은 맴버변수에 접근하기 위한 간단 구문제공한다. 또 선언 프로퍼티에 의해 이 변수들을 관리 하기 위해 필요한 그룹 코드의 반 이상은 쓸 필요가 없어 진다. 특히,  다른 오브젝트를 참조하는 경우에는 필요에 의해 오브젝트의 유지와 해방을 자동적으로 행해주기 때문에 프로퍼티를 사용하면 아주 편리하다. 

-뷰 콘트롤러의 뷰가 화면에 표시되거나 화면에서 사라지거나 하는 것에 응답하여 뷰 계층이나 어플리케이션 상태를 조정할 수 있다.

-네비게이션 콘트롤러나 탭바 콘트롤러에서 사용되는 다음과 같은 오브젝트를 설정할 수 있다.

   네비게이션 아이템

   툴바 아이템( 관련되는 네비게이션 콘트롤러가 툴바를 표시할 경우)

   탭바 아이템

-인터페이스의 방향이 변화한 경우에는 뷰 계층을 조정할 수 있다. 

-뷰 또는 그 서브 뷰에서 처리 되지 않는 이벤트를 캐치 하는 이벤트핸들러를 실장할 수 있다.

-편집가능한 뷰를 실장할 수 있다.

뷰 관리 사이트의 이해 

뷰 콘트롤러 오브젝트에서는 대응하는 뷰의 관리는 로드사이클과 언로드사이클 이라고 하는 두개의 독립적인 사이클로 발생한다. 로드사이클은 어플리케이션이 뷰 콘트롤러에게 뷰 오브젝트에의 포인트를 요구했을 때 그 오브젝트가 현재 메모리내에 존재하지 않는 경우에 꼭 발생한다. 로드사이클이 발생하면 뷰 콘트롤러는 그 뷰를 메모리에 로드하고 그 다음 부터 참조할 수 있도록 뷰로의 포인트를 보존한다. 

그 후 어플리케이션이 메모리 부족의 경고를 받으면 뷰 콘트롤러는 그 뷰를 언로드 하려고 한다. 언로드 사이클 에서는 뷰 콘트롤러는 뷰 오브젝트를 릴리즈하고 뷰 가 없는 초기상태로 돌아가려는 것을 시도한다. 뷰를 릴리즈하면 뷰 콘트롤러는 재차 뷰가 요구되어 로드 사이클이 재차 시작될 때 까지 뷰 오브젝트가 없는 상태이다. 

로드사이클과 언로드사이클에서는 뷰 콘트롤러가 뷰의 로드나 언로드에 관계하는 대부분의 처리를 실행한다. 단, 뷰 콘트롤러 클래스에서 뷰 계층 내의 뷰에의 참조를 포함하거나 로드 시에 뷰에 다른 설정을 행할 필요가 있을 경우는 특정한 메서드를 오버라이드 해야 그 처리를 실행할 수 있다.

로드사이클에서는 다음과 같은 스탭이 발생한다. 

1. 어플리케이션의 어딘가 에서 뷰 콘트롤러의 뷰 프러퍼티 내에 있는 뷰가 요구된다.

2. 뷰가 현재 메모리내에 존재하지 않는 경우 뷰 콘트롤러는 로드 뷰 메서드를 호출한다.

3. 로드뷰 메서드는 다음의 것들 중 어떤 것을 실행한다.

  -그 메서드를 오버라이드하는 경우에는 그 실장이 필요한 뷰를 모두 작성하여 뷰 프러퍼티에 닐 이외의 값을 대입하는 처리를 담당한다.

  - 이 메서드를 오버라이드 하지 않는 경우 디폴트의 실장이 뷰 콘트롤러의 nib 네임 프러퍼티와 nibBundle 프러퍼티를 사용하여 지정한 nib 파일로 부터 로드하려고 한다. 특정한 nib 파일이 발견되지 않으면 뷰 콘트롤러 클래스의 이름과 같은 이름의 nib 파일을 검색하여 로드한다.

  - 해당하는 nib파일이 발견되지 않으면 메서드는 빈 UIView 오브젝트를 작성하여 뷰 프러터티에 대입한다. 

4. 뷰 콘트롤러는 뷰 디드로드 메서드를 호출하여 로드시에 실행해야만 하는 것 이외의 처리 가 있으면 그것을 실행한다. 

그림 2-2 로드사이클을 표시한 것이다. 이 그림에서는 로드사이클에서 호출된 몇개의 메서드도 포함되어 있다. 필요하면 어플리케이션에서 로드 뷰 메서드와 뷰 디드로드 메서드의 양방을 오버라이드 하여 뷰 콘트롤러에 희망하는 동작을 추가하는 일도 가능하다.(27쪽)

언로드사이클에서는 다음과 같은 스탭이 발생한다.

1. 어플리케이션이 시스템 에서 메모리 부족 경고를 받는다.

2. 각 뷰 콘트롤러는 자신의 디드리시브 메모리 원이 메서드를 호출한다. 이 메서드를 오버라이드 하는 경우에는 그 중에 뷰 콘트롤러 오브젝트에서 불필요하게된 모든 커스텀 데이터를 릴리즈한다.

  - 이 메서드에서는 뷰 콘트롤러의 뷰를 릴리즈 해야만 하는 것은 아니다. 이 메서드의 실장의 어딘가 에서 슈퍼를 호출하여 디폴트동작을 실행하지 않으면 안된다. 

  - 디폴트의 실장에서는 뷰를 릴리즈 해도 안전하다는 것이 판단되었을 때만 뷰가 릴리즈된다. 

3. 뷰 콘트롤러는 뷰를 릴리즈하면 뷰 디드언로드 메서드를 호출한다. 이 메서드를 오버라이드하여 뷰나 뷰 계층에 필요한 추가 클린업처리를 실행하는 것이 가능하다

중요: 아이폰 OS 3.0이상에서는 뷰의 클린업에 관련된 코드를 두는 장소로서 뷰디드언로드 메서드가 바람직한 장소다. 디드리시브 메모리 원 메소드를 오버라이드하여 뷰의 릴리즈시에 일시적인 캐시나 불 필요하게 된 그 밖의 프라이빗 데이터를 릴리즈하는 것이 가능하다. 디드리시브 메모리 워닝은 오버라이드 하는 경우에는 꼭 수퍼를 호출하여 부모 버전의 메서드에게 뷰를 릴리즈 시킨다.

  아이폰 OS 2.2에서는 뷰 관련의 클린업을 실행하거나 불필요하게 된 프라이빗 데이터구조를 릴리즈 하기 위해서 디드리시브 메모리 원이 메소드를 하지 않으면 안된다. 뷰디드언로드 메서드는 아이폰 OS 3.0 이후에서만 가능하다.

막코딩으로 하는 뷰의 작성

nib파일을 사용하지 않고 뷰를 작성하고 싶을 때는 뷰 콘트롤러의 로드뷰 메서드에서 그것을 실행한다. 프로그램에 의해 뷰를 작성하는 경우에는 이 메서드를 오버라이드하지 않으면 안된다. 이 메서드의 실장에서는 다음의 처리를 실행하지 않으면 안된다.

1. 화면에 딱 맞는 사이즈의 루트 뷰 오브젝트를 작성한다. 이 루트 뷰는 뷰 콘트롤러에 관련된 그 밖의 모든 뷰의 컨테이너로서 역할을 한다. 통상적으로는 그 뷰에 대해서 어플리케이션 윈도우 ( 화면가득히 표시된다)의 사이즈에 일치하는 프레임을 정의한다. 단, 시스템 스테이터스 바 , 네비게이션 바, 탭바 등 각종 뷰가 존재할 때 뷰 콘트롤러는 이것들에 대응하여 이 프레임의 사이즈를 조정한다. 범용 UIView  오브젝트 , 독자적으로 정의한 커스텀 뷰 , 그 밖의 화면 가득히 확장할 수 있는 임의의 뷰를 사용할 수 있다. 

2. 추가적인 서브뷰를 작성하여 그것들을 루트뷰가 추가 작성한다. 뷰 마다 다음처리를 실행하지 않으면 안된다. 

   -뷰를 작성하여 초기화 한다. 시스템뷰의 경우에는 통상 initWithFrame : 메서드 를 사용하여 그 뷰의 초기 사이즈와 위치를 지정한다.

   -addSubview: 메서드 를 사용하여 그 뷰를 부모 뷰에 추가한다. 

   -릴리즈 : 메서드  를 호출하여 그 뷰를 릴리즈한다.

3.루트 뷰를 뷰 콘트롤러의 뷰 프로퍼티에 대입한다.

4. 루트 뷰를 릴리즈한다.

각 뷰를 작성한 직후에 그것을 릴리즈하는 것은 이상하게 생각될지 모른다. 그러나 뷰를 뷰계층에 추가 하거나 뷰에의 참조를 보존하는 경우에 릴리즈하는 것은 정말 해야만 하는 것이다. 어떤 오브젝트도 작성시의 리테인 카운터의 초기값은1이다. 부모 뷰는 자동적으로 서브 뷰를 리테인 하기 때문에 자식 뷰를 부모 뷰에 추가하면 자식 뷰를 릴리즈해도 안전하다. 그와 같이 루트뷰를 포함하기 위해서 사용되는 뷰 프로퍼티도 리테인의 시멘틱스에 따라서 뷰가 릴리즈되는 것을 막는다. 따라서 각 뷰를 릴리즈하는 것은 소유권을 적절한 장소로 옮겨서 뒤에 그 오브젝트의 릴리즈 누락이 발생하는 것을 막는 의미이다. 

주) 로드뷰 메서드를 오버라이드하여 프로그래밍에의해 뷰를 작성할 때에는 수퍼를 호출하면 안된다. 그렇게 하면 뷰를 로드하는 디폴트동작이 개시된다. 통상 그것은 CPU 사이클을 낭비할 뿐이다. 로드 뷰 메서드의 독자적인 실장에서는 뷰 콘트롤러용의 루트 뷰 와 서브뷰의 작성에 필요한 모든 처리를 실행해야만 한다. 

프로퍼티나 커스텀 setter 메서드를 사용하여 임의의 뷰 오브젝트를 리테인 하는 경우에는 꼭 뷰 디드 언로드 메서드를 실장하여 이것들의 프로퍼티를 nil 로 설정 하는 것을 잊지 마세요. 특히 아웃렛을 사용하여 뷰에의 참조를 포함하거나 이런 아웃렛들에서 리테인 시멘틱스를 가지는 프로퍼티나 그 밖의 setter 메서드를 사용하는 경우에는 이점에 주의 하세요. 

뷰의 언로드 후의 클린업

뷰 콘트롤러의 뷰는 메모리에 로드되면 메모리 부족상황이 발생하거나 뷰 콘트롤러 자신이 할당해제될 때 까지는 메모리내에 있다. 메모리 부족상황 일때는  UIView 콘트롤러 디폴트 동작에서는 뷰가 현재 사용되고 있지 않으면 뷰 프러퍼티에 포함되어 있는 뷰 오브젝트가 릴리즈 된다. 그러나 커스텀 뷰 콘트롤러 클래스에서 뷰 계층 내의 뷰에의 아웃렛이나 포인터를 포함하고 있는 경우에는 최상위 레벨의 뷰 오브젝트가 릴리즈되었을 때 이 참조들도 릴리즈하지 않으면 안된다. 그것을 방심하면 그 오브젝트들은 금방 메모리에서 소거되지 않고 그 후 그 오브젝트들의 포인터를 덮어쓰기 하면 뒤에 메모리 부족의 원인이 될 가능성이 있다. 

뷰 콘트롤러가 꼭 뷰 오브젝트에의 참조를 클린업 하지 않으면 안되는 곳은 다음 두 곳이다.

 - dealloc 메서드 

 - viewDidUnload 메서드

선언할 때 프로퍼티를 사용하여 뷰에의 참조를 포함하고, 그 프로퍼티가 리테인 시멘틱스를 사용하고 있는 경우 그 프로퍼티에 nil 값을 대입하는 것만으로 그 뷰를 릴리즈 할 수 있다. 프로퍼티는 그 편리함으로 부터 뷰 오브젝트의 관리수단으로써 압도적으로 선호된다. 프로퍼티를 사용하지 않는 경우에는 명시적으로 리테인한 뷰에게 릴리즈 메시지를 송신하여 그것에 대응하는 포인터 값을 nil로 설정하지 않으면 안된다.

효율적인 메모리관리

뷰 콘트롤러와 메모리관리에서 검토하지 않으면 문제는 2가지 이다.

 - 어떻게 메모리를 효율적으로 할당할 것인가

 - 언제 어떻게 메모리를 릴리즈를 할 것인가

메모리 할당에 대해서는 완전하게 개발자가 판단해야 할 부분이지만 UIView 콘트롤러 클래스에는 메모리관리 테스크에 관련한 메서드가 몇개가 있다. 표 2-2는 뷰 콘트롤러 오브젝트 내에서 메모리에 할당이나 릴리즈를 행하는 가능성이 있는 곳과 각각의 곳에서 실행하지 않으면 안되는 리스트이다. 

테스크/ 메서드/ 설명

---

뷰콘트롤러에서 필요한 중요한 데이터 구조를 할당한다. / 초기화 메서드 / 커스텀초기화 메서드에는 (init 이든지 상관없이) 항상 뷰 콘트롤러 오브젝트를 적절한 상태에 설정할 책임이 있다. 그것에는 적절한 조작을 보정하기 위해서 필요한 여러 데이터 구조의 할당이 포함되어 있다.

---

뷰오브젝트를 작성한다./ loadView / 프로그래밍에의한 뷰를 작성하는 경우에만 로드 뷰 메서드의 오버라이드가 필요하다. nib 파일로 부터 뷰를 로드하는 경우에는 initWithNibname : bundle 메서드를 사용하여 적절한 nib 파일의 정보를 사용하여 뷰 콘트롤러를 초기화 할 뿐이다.

---

뷰에 표시할 데이터의 할당과 로드를 실행/ viewDidLoad / 뷰오브젝트에 관련된 데이터는 모두 viewDidLoad메서드에서 작성 또는 로드하지 않으면 안된다. 이 메서드가 호출하는 시점 에서 뷰 오브젝트 존재와 그것이 적절한 상태에 있는 것이 보증된다. 

---

뷰오브젝트에의 참조를 릴리즈한다./ viewDidUnload dealloc / 클래스의 아웃렛과 그 밖의 맴버변수를 사용하여 뷰 계층내의 뷰 오브젝트를 리테인하는 곳은 그 뷰가 불필요하게 되면 그 아웃렛들을 꼭 릴리즈하지 않으면 안된다. 뷰 오브젝트를 릴리즈하면 안전을 위해서 꼭 아웃렛과 변수를 nil로 설정한다. 

---

뷰가 표시되지 않을 때 필요없는 데이터를 릴리즈한다./ viewDidUnload / 뷰 고유의 데이터 중, 뷰가 재차 메모리에 로드되었을 때 간단하게 재작성할 수 있는 데이터를 릴리즈 하기위해서는  viewDidUnload 메서드를 사용한다. 단, 데이터의 재 작성에 너무 시간이 걸릴 경우에는 그것에 대응하는 데이터 오브젝트를 여기에서 릴리즈할 필요가 없다. 대신에 didReceiveMemoryWarning 메서드로 이 오브젝트들을 릴리즈하는 것을 검토해야만 한다.

---

메모리 부족 통지에 응답한다./ didReceiveMemoryWarning / 뷰콘트롤러에 관련된 커스텀 데이터 구조 중, 중요하지않은 것을 릴리즈 하기 위해서는 이 메서드를 사용한다. 이 메서드는 뷰 오브젝트에의 참조를 릴리즈 하기 위해서는 사용하지 않지만 뷰 디드언로드 메서드에서 릴리즈 하지 않은 뷰 관련 데이터 구조를 릴리즈 하기 위해서 사용한다. ( 뷰 오브젝트 그 자체는 꼭 뷰 디드언로드 메서드로 릴리즈 하지 않으면 안된다.)

---

View 콘트롤러에서 필요한 중요한 데이터 구조를 릴리즈한다./ dealloc/ 뷰 콘트롤러에 관련된 모든 데이터 구조를 릴리즈하기 위해서 이 메서드를 사용한다. 뷰 콘트롤러에 nil 이외의 값을 가지는 아웃렛 이나 변수가 남아있는 경우에는 여기에서 그것들을 릴리즈하지 않으면 안된다.