Definition
- 앱의 유저 인터페이스와 이벤트를 뷰에 디스패치하는 개체들의 화면이다.
OverView
윈도우는 많은 이벤트와 다른 많은 앱의 근간이 되는 많은 업무들을 수행하기 위해서 뷰 컨트롤러와 함께 동작한다.
UIKit는 대부분의 윈도우와 관련된 상호작용을 다루고, 다른 많은 앱 동작수행이 필요한 객체들과 동작한다.
우리가 윈도우를 사용하는 때는 다음의 상황들이다.
- 앱의 컨텐츠를 보여주기 위한 메인 윈도우 제공
- 추가적인 컨텐츠를 위한 추가적인 윈도우 생성
보통 Xcode는 우리 앱에 메인 윈도우를 제공한다. 새로운 iOS프로젝트는 스토리보드를 앱의 뷰를 정의하기 위해 사용한다. 스토리보드는 App Delegate 객체에 Xcode 템플릿을 자동으로 제공해주는 윈도우 프로퍼티의 존재를 요구한다. 만약 우리의 앱이 스토리보드를 사용하지 않는다면( 프로그램 적으로, 선언적으로 UI를 만들경우) 윈도우를 스스로 만들어줘야한다.
대부분의 하나의 메인 스크린에서 앱 컨텐츠를 보여주는 앱은 대부분 하나의 윈도우만을 필요로한다.
메인 스크린에 추가적인 윈도우를 만들 수 있음에도 불구하고, 추가적인 윈도우는 대게 외부적인 스크린을 보여줄(ex : 결된 스크린에 컨텐츠를 보여주거나.) 때 쓰인다.
또한, UIWindow 객체를 편리하게 다른 기능과 함께 사용할 수 있다 :
- 윈도우와 연결되어 시각적으로 영향을 미칠 수 있는 z축 계통의 윈도우를 세팅하거나
- 윈도우를 보여주고 키보드 이벤트를 넣을 때나
- 윈도우의 Coordinate 시스템으로 부터의 Coordinate 밸류를 바꾸고싶을 때
- 위도우의 RootViewController를 바꾸고 싶을 때
- 윈도우에 보여지고 있는 디스플레이를 바꾸고 싶을 때 이다.
윈도우는 그들 자신의 시각적 특징을 전부 가지고 있지는 않다 대신, 윈도우는 하나나 하나 이상의 루트뷰컨트롤러에 관리받고 있는 뷰를 호스팅한다. 스토리보드에 RootViewController를 설정해보자, 그리고 어떤 뷰든 우리 앱에 적절한 인터페이스를 추가해보자.
그리고 UIWindow 서브클래스를 거의 안 써야 할 것이다. 개발자들이 윈도우에서 수행하려고 하는 기능은 더 높은 레벨의 뷰 컨트롤러에서 수행하게되면 훨씬 쉽게 만들 수 있다.
Conclusion
- 당연하게 쓰는 것도, 알고 있고 없고는 큰 차이가 있다.
- 영어 공부하는 셈 치고 번역하면서 읽었다.
- 윈도우 서브클래스를 많이 건드리지말고 웬만하면 뷰컨트롤러 쪽에서 작업하라는 행간이 보이는 것 같기도 하다.
