<ios framework> present 2편

뷰컨트롤러에 대한 present를 계속 찾던 중 컨테이너 뷰컨에서의 present와 모달리 present가 뷰 하이어아키에서 어떻게 추가되는지 차이점이 있다는 것을 알게 되었습니다.

 

전자는 모든 뷰컨에서 가능하고, 푸쉬는 네뷰컨에서 가능한 메소드입니다. 결국에 이런 메소드들을 이해하는데 사전적으로 먼저 이해해야 할 점은 제가 1달동안 고민한 결과, 컨테이너 뷰 컨트롤러가 무엇인지 먼저 이해하는게 가장 중요한거 같습니다.....!!! 

 

컨테이너 뷰컨은 아래에서 말하겠지만, 뷰컨의 뷰 일부에 다른 뷰컨들의 뷰를 보여 줄 수 있습니다.

 

[https://developer.apple.com/library/archive/featuredarticles/ViewControllerPGforiPhoneOS/TheViewControllerHierarchy.html#//apple_ref/doc/uid/TP40007457-CH33-SW1]

[https://developer.apple.com/library/archive/featuredarticles/ViewControllerPGforiPhoneOS/PresentingaViewController.html#//apple_ref/doc/uid/TP40007457-CH14-SW7]

 

In programming, instantiation is the creation of a real instance or particular realization of an abstraction or template such as a class of objects or a computer process

 

---

Designing a Custom Container View Controller

In almost every way, a container view controller is like any other content view controller in that it manages a root view and some content. The difference is that a container view controller gets part of its content from other view controllers. The content it gets is limited to the other view controllers’ views, which it embeds inside its own view hierarchy. The container view controller sets the size and position of any embedded views, but the original view controllers still manage the content inside those views.

 

대부분의 경우에서, 컨테이너 뷰컨은 루트 뷰와 다른 컨텐트를 관리한다는 점이 여타 다른 컨텐트 뷰컨이랑 비슷합니다. 둘의 차이점은 컨테이너 뷰컨은 컨텐트의 일부분을 다른 뷰컨들로 부터 얻습니다. 컨테이너 뷰컨이 얻는 컨텐트는 다른 뷰컨들의 뷰로 한정되 있습니다, 이런 뷰들을 뷰 계층에 내포시킵니다. 컨테이너 뷰 컨트롤러들은 내포된 뷰들의 사이즈와 위치를 지정할 수 있습니다, 하지만 original 뷰컨들은 여전히 이러한 뷰들의 내부 콘텐트들을 관리합니다.

 

When designing your own container view controllers, always understand the relationships between the container and contained view controllers. The relationships of the view controllers can help inform how their content should appear onscreen and how your container manages them internally. During the design process, ask yourself the following questions:

• What is the role of the container and what role do its children play?

• How many children are displayed simultaneously?

• What is the relationship (if any) between sibling view controllers?

• How are child view controllers added to or removed from the container?

• Can the size or position of the children change? Under what conditions do those changes occur?

• Does the container provide any decorative or navigation-related views of its own?

• What kind of communication is required between the container and its children? Does the container need to report specific events to its children other than the standard ones defined by the UIViewController class?

• Can the appearance of the container be configured in different ways? If so, how?

The implementation of a container view controller is relatively straightforward after you have defined the roles of the various objects. The only requirement from UIKit is that you establish a formal parent-child relationship between the container view controller and any child view controllers. The parent-child relationship ensures that the children receive any relevant system messages. Apart from that, most of the real work happens during the layout and management of the contained views, which is different for each container. You can place views anywhere in your container’s content area and size those views however you want. You can also add custom views to the view hierarchy to provide decoration or to aid in navigation.

---

The Root View Controller

The root view controller is the anchor of the view controller hierarchy. Every window has exactly one root view controller whose content fills that window. The root view controller defines the initial content seen by the user. Figure 2-1 shows the relationship between the root view controller and the window. Because the window has no visible content of its own, the view controller’s view provides all of the content.

 

Figure 2-1 The root view controller

The root view controller is accessible from the rootViewController property of the UIWindow object. When you use storyboards to configure your view controllers, UIKit sets the value of that property automatically at launch time. For windows you create programmatically, you must set the root view controller yourself.

 

---

Container View Controllers

Container view controllers let you assemble sophisticated interfaces from more manageable and reusable pieces. A container view controller mixes the content of one or more child view controllers together with optional custom views to create its final interface. For example, a UINavigationController object displays the content from a child view controller together with a navigation bar and optional toolbar, which are managed by the navigation controller. UIKit includes several container view controllers, including UINavigationController, UISplitViewController, and UIPageViewController.

A container view controller’s view always fills the space given to it. Container view controllers are often installed as root view controllers in a window (as shown in Figure 2-2), but they can also be presented modally or installed as children of other containers. The container is responsible for positioning its child views appropriately. In the figure, the container places the two child views side by side. Although it depends on the container interface, child view controllers may have minimal knowledge of the container and any sibling view controllers.

 

Figure 2-2 A container acting as the root view controller

 

---

 

일단 뷰컨은 콘텐츠 뷰컨과 컨테이너 뷰컨이 있습니다.

 

Presenting a View Controller

There are two ways to display a view controller onscreen: embed it in a container view controller or present it. Container view controllers provide an app’s primary navigation, but presenting view controllers is also an important navigation tool. You use direct presentation to display a new view controller on top of the current one. Typically, you present view controllers when you want to implement modal interfaces, but you can also use them for other purposes.

 

뷰컨을 presenting하는 방법.

뷰컨을 스크린에 보여주는 방법은 두가지가 있습니다. 컨테이너 뷰컨에 embed하거나 present하는 방법입니다. 컨테이너 뷰컨들은 앱의 주요 네비게이션을 제공합니다, 하지만 뷰컨 presenting은 또한 중요한 네비게이션 도구입니다. present VC를 통해 새로운 뷰컨을 현재 것들중에서 가장 위에서 보여주는 것이 가능합니다. 전형적으로, 우리는 뷰컨을 우리가 모달 인터페이스를 구현하기를 원하거나 다른 목적으로 present 뷰컨을 사용합니다. 

 

Support for presenting view controllers is built in to the UIViewController class and is available to all view controller objects. You can present any view controller from any other view controller, although UIKit might reroute the request to a different view controller. Presenting a view controller creates a relationship between the original view controller, known as the presenting view controller, and the new view controller to be displayed, known as the presented view controller. This relationship forms part of the view controller hierarchy and remains in place until the presented view controller is dismissed

 

presenting VC는 UIViewController 클래스에 내장되어 있습니다. 우리는 어떤 뷰컨에서든 다른 뷰컨을 present할 수 있습니다, (?). presenting 뷰컨은 오리지널 뷰컨인 presenting 뷰컨과 displayed되 있는 뷰컨과 관계를 형성합니다. 형성된 관계는 뷰컨 계층의 일부가 됩니다 그리고 presented 뷰컨이 소멸되기전 까지 남아 있습니다.

 

 

Presenting Versus Showing a View Controller

The UIViewController class offers two ways to display a view controller:

• The showViewController:sender: and showDetailViewController:sender: methods offer the most adaptive(적응형) and flexible way to display view controllers. These methods let the presenting view controller decide how best to handle the presentation. For example, a container view controller might incorporate(통합하다) the view controller as a child instead of presenting it modally. The default behavior presents the view controller modally

showViewController와 showDetailViewController 메소드들은 뷰컨을 디스플레이 하는데 가장 adaptive하고 유연한 방법입니다. 이러한 메소드들은 presenting VC가 어떻게 가장 잘 presentation할지 다루어 줍니다. 예시로는 컨테이너 뷰컨은 show를 하면 뷰컨을 모달리하게 present하기 보다 자식으로 통합할 것입니다. 그니까 초기 디폴트 설정은 모달리하게 present 하는 것입니다.

 

• The presentViewController:animated:completion: method always displays the view controller modally. The view controller that calls this method might not ultimately handle the presentation but the presentation is always modal. This method adapts the presentation style for horizontally compact environments.

present 모달리는 항상 뷰컨을 모달리하게 보여줍니다. 이 메소드를 호출하는 뷰컨은 궁극적으로 presentation을 handle합니다 하지만 presentation은 항상 모달합니다. 이 메소드는 presentation 스타일을 받아들여 horizontally compact한 환경으로 변화 시킵니다.

 

The showViewController:sender: and showDetailViewController:sender: methods are the preferred way to initiate presentations. A view controller can call them without knowing anything about the rest of the view controller hierarchy or the current view controller’s position in that hierarchy. These methods also make it easier to reuse view controllers in different parts of your app without writing conditional code paths.

 

shoViewController와 showDetailViewController 메소드들은 presentaion들을 시작하기에 선호되는 방법입니다. 한 뷰컨을 다른 뷰컨의 계층이나 현재 뷰컨들의 계층상에서의 위치를 알 필요 없이 호출할 수 있습니다. 이러한 메소드들은 뷰컨트롤러의 앱의 서로 다른 파트들에서 재사용을 쉽게 합니다. 

 

---

Presented View Controllers

Presenting a view controller replaces the current view controller’s contents with those of a new one, usually hiding the previous view controller’s contents. Presentations are most often used for displaying new content modally. For example, you might present a view controller to gather input from the user. You can also use them as a general building block for your app’s interface.

When you present a view controller, UIKit creates a relationship between the presenting view controller and the presented view controller, as shown in Figure 2-3. (There is also a reverse relationship from the presented view controller back to its presenting view controller.) These relationships form part of the view controller hierarchy and are a way to locate other view controllers at runtime.

'Figure 2-3 Presented view controllers

 

When container view controllers are involved, UIKit may modify the presentation chain to simplify the code you have to write. Different presentation styles have different rules for how they appear onscreen—for example, a full-screen presentation always covers the entire screen. When you present a view controller, UIKit looks for a view controller that provides a suitable context for the presentation. In many cases, UIKit chooses the nearest container view controller but it might also choose the window’s root view controller. In some cases, you can also tell UIKit which view controller defines the presentation context and should handle the presentation.

 

컨테이너 뷰컨들이 포함되면, UIKit은 당신이 작성한 코드를 간단하게 하기 위해 presentation chain을 수정할 것입니다. 서로 다른 presentation 스타일들은 스크린을 보여주는 방법에 대한 서로 다른 규칙들이 있습니다. 내가 view controller를 present하면, UIKit은 presentation에 적절한 맥락을 찾습니다. 많은 경우들에, UIKit은 가장 가까운 container view controller를 선택합니다 하지만 윈도우의 루트 뷰컨을 선택할 수도 있습니다. 몇몇의 경우들에서는, 우리는 UIKit에 어떤 뷰컨이 presentation context를 정의하고 presentation을 조정할지 정할 수 있습니다.

 

Figure 2-4 shows why containers usually provide the context for a presentation. When performing a full-screen presentation, the new view controller needs to cover the entire screen. Rather than requiring the child to know the bounds of its container, the container decides whether to handle the presentation. Because the navigation controller in the example covers the entire screen, it acts as the presenting view controller and initiates the presentation.

 

아래 그림 2-4는 왜 컨테이너들이 주로 presentation을 위한 컨텍스트를 제공하는지 보여줍니다. 풀 스크린 presentation을 실행하면, 새로운 뷰컨은 전체 화면을 덮어야 합니다. child에게 container의 bounds를 알리지 않습니다, 컨테이너는 presentation을 맡아 다룰지 결정합니다. 왜냐하면 예시에서 네비게이션 컨트롤러는 전체 화면을 책임집니다, 네뷰컨은 presenting 뷰컨처럼 활동합니다 그리고 presentation을 시작합니다.

 

Figure 2-4 A container and a presented view controller

솔직히 아직 이해가 안되는 부분이 presentedViewController가 childViewController가 되는 거랑 뭐가 다르지?