[iOS] 윈도우란? (feat. UIWindow)

안녕하세요🐶

 

이번 시간에는 윈도우에 대해서 공부해보겠습니다.

 

윈도우는 UIWindow 오브젝트를 가리키는 말인데요.

 

 

 

윈도우라는 개념이 필요하기 시작할 때는 아마 스토리보드 없이 UI를 처음 코드로 구현해볼 때 일 것 같아요.

 

 

이 글에서는 언제 직접 윈도우를 생성해야되는지에 대해서도 다루었습니다.

 

두 개의 공식문서를 종합해서 정리하다보니 내용이 좀 많아진 것 같네요.

 

 

요약 해보자면

윈도우는 뷰들을 담는 컨테이너이다.

 

윈도우는 이벤트를 전달해주는 매개체이다.

 

iOS 앱은 콘텐츠를 화면에 보여주기 위해서 최소 1개 이상의 윈도우를 가지고 있다. (보통 1개)

 

시스템 윈도우에서 생성된 이벤트들은 Key Window 로 전달이 된다.

 

 

 

이 글에는 없는 것

External Display 에 관련된 내용

 

 

그럼 시작해볼게요!!!🔥

---

 

정의

앱 UI 의 배경막 역할을 하고 뷰에 이벤트를 전달하는 오브젝트

 

우선 알아야할 점은 UIWinodw 도 UIView 의 서브클래스라는 것입니다.

 

그런데 UIView 는 UIResponder 의 서브클래스이죠?

 

이벤트를 처리하는 리스폰더 체인(Responder Chain) 에는 UIWindow 가 항상 포함됩니다.

 

이부분에서 '뷰에 이벤트를 전달하는' 이라는 역할이 수행되는 것입니다.

 

@MainActor 라는 어트리뷰트는 Swift 5.5 부터 도입되는 개념으로, 메인 쓰레드에서 실행되는 클래스임을 가리킵니다.

 

아직 베타 테스트 중이고 주제와 벗어나므로, 다음에 다루어보는게 좋을 것 같습니다.

---

 

개요

 

UIWindow 는 제일 밑에 있네...

 

 

우선 그림에 대해서 간단히 보자면, 위의 정의대로 UIWindow 는 뷰들 가장 뒤에서 배경막 역할을 하고 있습니다.

 

" 그 옆의 Core Animation layers 를 보면, 레이어는 뷰와 1 : 1 관계로 표현되어 있는 오브젝트들입니다.

iOS에서 모든 뷰들은 layer-backed 뷰라는 점과 관련이 있는데요.

관련된 글은 CALayer 에 대해서 정리한 이 글을 참고해주세요! "

 

 

모든 iOS 앱은 적어도 한 개 이상의 윈도우를 가지고 있습니다.

 

여기서 윈도우란 UIWindow 오브젝트를 의미합니다.

 

iOS 에서 윈도우 자체는 시작적인 요소를 전혀 포함하고 있지 않습니다.

 

윈도우는 그저 한 개 이상의 뷰를 포함할 수 있는 비어있는 컨테이너 입니다.

( 그리고 새로운 콘텐츠를 보여주기 위해서 윈도우를 교체하는 대신, 뷰를 교체합니다 )

 

윈도우 자체는 시각적인 표현을 포함하지 않는다

 

---

🟢 윈도우는 다음과 같은 책임을 가지고 있습니다:

 

앱이 보여주는 콘텐츠들을 포함하는 역할을 합니다.

 

뷰를 포함한 다른 앱 내 오브젝트들에게 이벤트를 전달해주는 핵심적인 역할을 합니다.

 

앱의 뷰 컨트롤러와 화면 방향전환 ( landscape & portrait ) 을 용이하게 하기 위해 협업합니다.

---

 

윈도우는 뷰 컨트롤러와 함께 동작하면서 이벤트를 핸들링하고 앱의 동작에 필수적인 작업들을 수행합니다.

 

UIKit 은 앱의 동작 구현이 필요할 때

다른 오브젝트들과 같이 협동하면서 대부분의 윈도우 관련 상호작용 (window-related interactions) 들을 처리합니다.

 

 

---

🟢 우리는 다음 두 가지 경우에 윈도우를 사용합니다:

 

앱의 콘텐츠를 화면에 보여주기 위하여 Main window 를 제공해야할 때

 

추가적인 콘텐츠를 보여주기 위해 추가적인 window 를 생성해야 할 때 (external display 를 사용할 경우)

---

 

External Display 를 사용하여 Window 의 개수가 2개가 된 상황

 

윈도우를 생성하고 설정하는 방식은 코드로 생성하기 혹은 인터페이스 빌더를 사용하기 두 가지가 있습니다.

 

스토리보드 방식(인터페이스 빌더를 이용) 으로 iOS 프로젝트를 구성한다고 가정해보겠습니다.

 

 

이 경우, Xcode 는 앱의 메인 윈도우 를 자동으로 제공합니다.

 

스토리보드는 AppDelegate 오브젝트의 window 속성이 UIWindow 오브젝트로 초기화 되어있어야 제대로 작동합니다.

 

단, SceneDelegate 개념이 등장한 이후에는 SceneDelegate 오브젝트가 window 속성을 가지고 있습니다.

 

 

위와 같이 SceneDelegate 에서 window 는 Optional<UIWindow> 로 선언되어 있지만,

window 속성을 사용할 시점에는 제대로 초기화 되어있음을 보장합니다.

 

Xcode 가 자동으로 초기화시키기 때문입니다.

 

만약 스토리 보드를 사용하지 않고 코드로 UI 를 구성한다면, 윈도우를 직접 생성해야합니다.

 

 

정리를 하자면 윈도우 생성을 고려해야할 4가지 경우가 생깁니다.👇🏻👇🏻👇🏻

---

 

iOS 12 버전 이하 혹은 AppDelegate 만 사용할 경우

a. Storyboard 를 사용할 때

위에서 언급한대로 window 속성이 제대로 초기화 됩니다. 따로 생성해줄 필요가 없습니다.

 

b. UI 를 Programmatically 하게 구성할 때 ( Storyboard 를 사용하지 않을때 )

window 가 따로 초기화되지 않습니다.

AppDelegate 의 didFinishWithLaunchingOptions: 에서 UIWindow() 등으로

생성해서 속성을 초기화 해주어야 합니다.

 

 

iOS 13 버전 이상 SceneDelegate 를 사용할 때

(iOS 13 버전 이상에서는 AppDelegate 와 SceneDelegate 를 모두 사용하지만 window 에 초점을 맞추고 생각해보았습니다.)

 

a. Storyboard 를 사용할 때 = 생성할 필요 ❌

 

b. UI 를 Programmatically 하게 구성할 때 ( Storyboard 를 사용하지 않을때 )

SceneDelegate 의 willConnectTo: 메서드에서 직접 생성 ( 이 링크 참조 )

 

// scene(willConnectTo:options:) 메서드 내부에서 // 두 생성 방식의 차이는????? UIWindow(frame: UIScreen.main.bounds) UIWindow(frame: windowScene.coordinateSpace.bounds)

---

 

앱이 실행될 때는 어떤 상태로 실행되는 것과는 상관 없이 메인 윈도우는 항상 생성되어야 합니다.

 

윈도우를 생성하고 설정하는 작업 자체는 고비용의 작업이 아닙니다.

 

하지만 background 로 실행 될 경우, 윈도우를 'visible' 하게 하는 것은 피해야합니다.

 

---

🟢 윈도우(UIWindow) 오브젝트를 통해 다음과 같은 작업도 할 수 있습니다:

 

윈도우의 z 축 좌표를 설정하여, 다른 윈도우의 관계에 따라 보이는 정도를 조절할 수 있습니다 (뷰 계층과 유사)

 

윈도우를 보여주고, 키보드 이벤트의 타겟으로 설정할 수 있습니다.

 

윈도우 좌표 시스템의 좌표를 변환할 수 있습니다.

 

윈도우의 Root ViewController 를 변경할 수 있습니다.

 

윈도우가 표시되고 있는 (기기)스크린을 변경할 수 있습니다.

---

 

윈도우는 그것 자체로 어떠한 시각적인 표현물을 가지고 있지 않습니다.

(위의 글 내용에서도 나왔습니다. 윈도우는 뷰를 포함할 수 있는 비어있는 컨테이너다!!!!!!!!!)

 

대신에 윈도우는 한 개 이상의 뷰를 상주시키고 있는데,

이 뷰들은 윈도우의 Root ViewController 에 의해 관리되는 것들입니다.

 

UIWindow 를 서브클래싱할 일은 거의 없습니다.

 

윈도우에서 구현하고 싶어할법한 동작들은 더 윗-레벨인 뷰 컨트롤러에서 보통 더 쉽게 구현할수 있습니다.

 

거의 일어나지 않을 일이지만 서브클래싱을 한다면, becomeKey() 나 resignKey() 를 오버라이딩하여 윈도우의 키 상태가 변경될 때 커스텀한 동작을 구현하고 싶을 경우일 것입니다.

 

윈도우가 표시될 스크린을 구체적으로 정하는 방법에 대해서는 UIScreen 문서를 한번 살펴보는것이 좋을 것 같습니다.

---

 

Understanding Keyboard Interactions

 

터치 이벤트의 경우 이벤트가 발생한 윈도우에 직접 전달이 됩니다.

그런데 관련 좌표값이 없는 이벤트 같은 경우에는 키 윈도우 (Key Window) 로 전달 됩니다.

 

그런데 관련 좌표값이 없는 이벤트는 어떤 이벤트일까요?????

시스템이 생성한 윈도우에서 생성된 이벤트를 가리키는 것 같습니다.

가상 키보드 창을 화면에 띄울 때 새로 추가되는 윈도우 중 하나

 

예를 들어 가상 키보드 창은 시스템이 생성한 윈도우입니다.

키보드 창에서 글자를 입력할 때 발생하는 이벤트들은 앱의 키 윈도우로 전달이 됩니다.

여기서 UIInputView 라는 개념이 등장하는데, 공부해봐야할 것 같습니다.

 

하나의 시점에는 오직 한 개의 윈도우만이 키 윈도우가 될 수 있습니다.

 

키 윈도우는 isKeyWindow 라는 속성을 통해 결정할 수 있습니다.

 

앱에서 External Display 가 없는 경우 윈도우는 1개이기 때문에

대부분의 경우, 앱의 메인 윈도우가 키 윈도우입니다.

 

하지만 UIKit 은 필요할 경우 다른 윈도우를 키 윈도우로 지정하기도 합니다.

 

만약 어떤 윈도우가 키 윈도우인지 알고 싶다면,

didBecomeKeyNotification 이나 didResignKeyNotification 노티를 옵저빙해 보세요.

( 확인 전에는 키보드창이 뜨면 앱 메인 윈도우가 KeyWindow 가 아니게 되겠구나 라고 생각했는데,

그대로 KeyWindow 였습니다.

그래서 키보드 윈도우에서 발생한 이벤트는 KeyWindow 인 메인 윈도우로 전달됩니다!!)

 

시스템이 앱의 키 윈도우가 변경될 때 위의 노티를 뿌려줍니다

 

어떤 윈도우를 키 윈도우로 강제하거나, 키 윈도우를 해제시키고 싶다면 이 클래스의 적절한 메서드를 찾아서 호출하세요.

 

makeKey(), resignKey() 를 가리키고 있습니다.

 

---

 

Changing the Window Level

 

각각의 UIWindow 오브젝트는 설정 가능한 windowLevel 속성이 있습니다. (수정이 가능함)

 

이 속성값은 z 축 좌표 값을 나타내는 것입니다.

 

이 속성을 통해 다른 윈도우와 비교하여 자신의 위치를 결정합니다.

 

이 속성은 UIWindow.Level 타입이며, 같은 레벨의 윈도우는 다른 레벨의 윈도우보다 앞 혹은 뒤쪽에 나타납니다.

 

그런데 같은 레벨 안에서의 윈도우 순서는 보장되지 않습니다.

 

윈도우 레벨의 기본 값은 normal 입니다.

 

대부분의 경우는 앱의 윈도우들의 레벨을 변경할 필요가 없습니다.

 

새로 생성된 윈도우들은 생성과 동시에 normal 레벨로 설정됩니다.

 

normal 윈도우는 앱과 관련된 콘텐츠를 표시하는 윈도우임을 가리킵니다.

 

더 높은 레벨의 윈도우는 앱 콘텐츠 위에 떠야만하는 정보를 표시하기위해 남겨둔 것 입니다.

 

예를 들어 시스템 상태 바 (system status bar) 혹은 경고 창 (alert messages) 가 있습니다.

 

그래서 저는 경고창이 나타났을 때의 윈도우 레벨이 .alert 인지 정말 확인해보고 싶었는데요🔎

 

UIApplication.shared.windows 속성에서는 시스템이 만든 윈도우를 확인할 수 없다는 것을 알게 되었습니다.

" 이 리스트는 시스템이 만든 윈도우를 포함하고 있지 않습니다 "

 

이후

저 경고 창이라는 것이 앱 내에서 UIAlertController 로 생성한 경고창과는

무관한 것이라는 것을 뷰 디버깅을 통해 확인했습니다.

 

 

 

 

끝!

---

🤖🟢[우짱의 iOS 블로그]🔵💻

iOS를 공부하면서 배운 내용을 기록하고 있습니다.

 

 

 

참고 자료 1: https://developer.apple.com/library/archive/documentation/WindowsViews/Conceptual/ViewPG_iPhoneOS/Introduction/Introduction.html#//apple_ref/doc/uid/TP40009503-CH1-SW2

 

참고 자료 2: https://developer.apple.com/documentation/uikit/uiwindow