블로그 이미지

ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [iOS] View Controller Hierarchy - 뷰 컨트롤러 계층 구조
    iOS 2022. 8. 9. 00:34

    이 글은 애플의 "View Controller Programming Guide for iOS" 공식문서에서 View Controller Hierarchy 글을 번역, 의역한 것이다. Root view controller, container view controller에서의 view controller의 계층을 이해하는데 도움이 된다.

     

     

    View Controller Programming Guide for iOS: The View Controller Hierarchy

    View Controller Programming Guide for iOS

    developer.apple.com

    The View Controller Hierarchy

    앱에서는 view controller 간의 관계를 설정해서 각 view controller에서 요구되는 행동을 정의한다.


    UIKit은 정해진대로 view controller를 사용할 것을 기대한다. View controller 간의 적절한 관계를 잘 유지하면 각 view controller가 필요할 때 적재적소에 맞게 사용될 수 있다. 만약 미리 정해진 규칙이나 presentation 관계를 깨면 예상대로 동작하지 않을 수 있다.

     

    즉 설계된 대로(UIKit 개발자들이 의도한 대로) view controller 간의 관계를 잘 설정하라는 말로, 적절하게 관계를 설정하지 않으면 의도한대로 동작 안 할 수 있으니 주의하세요 라는 뜻이다.

    The Root View Controller

    Root view controller는 view controller 계층의 앵커(닻)이 된다. 모든 window는 오직 하나의 root view controller를 가지고 있고, 이 root view controller는 window의 content를 채운다. Root view controller는 사용자에게 초기 상태의 content가 어떻게 보여질지를 정의한다.

    위 그림은 root view controller와 window간의 관계를 보여준다. Window가 자신만의 visible한 content가 없기 때문에, view controller의 view가 content를 제공한다.

     

    Root view controller는 UIWindow 객체의 rootViewController 프로퍼티로 접근할 수 있다. 스토리보드를 사용해서 view controller를 구성할 때, UIKit은 launch time에 자동으로 rootViewController의 값을 설정한다. 이를 코드로 구현할 때는 root view controller를 꼭 직접 설정해줘야 한다.

    Container View Controllers

    Container view controller는 더 관리하기 쉽고 재사용하기 쉬운 조각들을 조합해서 복잡한 인터페이스를 만들 수 있게 해준다. 이게 뭔 말이냐면 Container view controller는 하나 이상의 child view controller의 content와 optional custom view들을 섞어서 복잡한 Interface를 만든다는 말이다. 가령 UINavigationController 객체는 child view controller의 content를 navigation controller에 의해 관리되는 navigation bar와 optional toolbar와 함께 보여준다.

     

    UIKit은 여러 container view controller를 가지고 있다. (UINavigationController, UISplitViewController, UIPageViewController) 얘네들 모두가 child view controller의 view를 섞어서 복잡한 interface를 만든다.

     

    container view controller는 하나 이상의 child view controller들의 content를 보여주는 view controller인데, Container view controller의 view는 항상 주어진 공간을 채운다(기기의 화면을 꽉 채운다는 말인 것 같다.) Container view controller들은 아래 그림에서도 볼 수 있듯이 window의 root view controller로 설정되기도 하지만, modal하게 띄우거나 다른 컨테이너의 자식으로도 설정할 수 있다.

    Container는 자식 뷰들의 위치를 적절히 조정하는데 책임이 있다. 위 그림에서, container는 두 child view를 나란히 배치한다. Container interface에 따라 다르긴 하지만, child view controller들은 container와 형제 view controller에 대해 최소한으로 알아야 할 것만 알고 있다.

     

    Container view controller가 자신의 children을 관리하기 때문에, UIKit은 custom container에서 어떻게 children을 설정하는지 규칙을 정의하고 있다. Custom container view controller를 어떻게 생성하는지 보려면 Implementing a Container View Controller를 참고하면 된다.

    Presented View Controllers

    View Controller를 present하면 현재의 view controller의 content를 새로운 것으로 바꾸는데, 주로 이전 view controller의 content를 감춘다. Presentation은 새로운 content를 modal하게 띄우는데 주로 사용된다.

    예를 들어, 인스타에는 위와 같이 사용자에게서 입력값을 받는 폼을 modal하게 띄울 수 있는데, 이를 view controller로 만들어서 띄울 수 있다. 이런 사용자 입력을 받는 폼은 질문 받는 용도가 아니라 다른 화면에서 여러 용도로도 사용될 수 있기 때문에 이 view controller를 앱 내의 여러 곳에서 사용 가능한 building block으로도 사용할 수 있다.

    View contoller를 present할 때, UIKit은 presenting view controller와 presented view controller 간의 관계를 생성한다.

     

    • Presenting view controller : 다른 view controller를 띄우는 view controller
    • Presented view controller : 다른 view controller에 의해 띄워진 view controller

     

    (Presented view controller에서 presenting view controller로 돌아가는 역방향의 관계가 있기도 하다.) 이런 관계는 view controller 계층의 부분들을 구성하고 런타임에서 다른 view controller로 이동하는 방법이 된다.

     

    Container view controller를 사용하면 UIKit은 개발자가 작성해야 할 코드를 단순화시키기 위해 presentation chain을 수정할 수도 있다. Presentaion style에는 여러 종류가 있는데, 저마다 이들이 화면에 어떻게 띄워져야 할지에 대해 다른 규칙을 갖고 있다. 예를 들어 full-screen presentation은 항상 띄울 때 전체 화면을 덮어야 한다.

     

    View controller를 present할 때, UIKit은 presentation에 맞는 적합한 context를 제공하는 view controller를 찾는다. 대부분의 경우에 UIKit은 가장 가까운 container view controller를 고르지만 window의 root view controller를 고를 수도 있다. 특정 경우에는 UIKit에게 어떤 view controller가 presentation context를 정의하고 presentation을 수행할지 정해줄 수도 있다.

     

    위 그림은 왜 주로 Container가 presentation을 위한 context를 제공하는 지를 보여준다. Full-screen presentation을 수행할 때, 새로운 view controller는 화면 전체를 덮어야 한다. Child가 container의 bound를 알게하는 것 대신에, container는 presentaion을 handle할 것인지 말지를 결정한다. 예시에 있는 navigation controller가 화면 전체를 덮기 때문에, presenting view controller와 같이 동작하며 presentation을 시작한다.


    위 긴 글에서 핵심을 추리면 다음과 같다.

     

    • window는 하나의 root view controller를 가지고 있다.
    • container view controller는 하나 이상의 child view controller들의 content를 조합해 interface를 만든다.
    • View controller를 present할 때 presented되는 view controller가 bound를 아는 대신 UIKit는 presentation에 맞는 context를 제공하는 view controller를 찾아 presentation을 handle하게 한다.
    반응형

    'iOS' 카테고리의 다른 글

    [iOS] Outlet이란?  (0) 2022.08.09
    [iOS] View controller의 역할  (0) 2022.08.09
    [WWDC19] Advances in UI Data Sources  (0) 2022.06.27
    [WWDC22] Design App Shortcuts  (0) 2022.06.20
    [WWDC22] Complications and widgets: Reloaded  (0) 2022.06.17

    댓글

Designed by Tistory.