iOS ) UIApplication

안녕하세요 :) Zedd입니다.

오늘은... UIResponder에 이어..UIApplication! 

저번글에서 싱글톤이야기가 나와서 공부해보려고 합니다. 

ㄱㄱ

UIApplication

---

UIApplication은 UIResponder와 마찬가지로, 클래스입니다!

정의는 "The centralized point of control and coordination for apps running in iOS."

iOS에서 실행되는 앱의 중앙 집중 제어 및 조정 지점...

뭔가 중앙에서 뭔가 제어하는 그런 아주 중요한 그런 느낌......이죠?

모든 iOS앱에는 UIApplication인스턴스가 "하나만" (exactly one instance)있습니다. (또는 매우 드물게 UIApplication의 하위클래스)

앱이 시작되면, 시스템은  UIApplicationMain(_:_:_:_:) 함수를 호출합니다. 이 함수는 다른 task들 중에서 싱글톤 UIApplication객체를 만듭니다.

그런 다음, shared클래스 메소드를 호출하여 객체에 접근합니다.

==> 한마디로 정리 : 앱 시작하면 UIApplicationMain(_:_:_:_:) 가 shared app instance를 만든다. 

흠 더 보기 전에, UIApplicationMain(_:_:_:_:)을 조금 더 알아봅시다.

UIApplicationMain(_:_:_:_:)은 application객체와 application delegate를 만들고, 이벤트 사이클을 설정하는 역할을 가지고 있습니다.

굉장히 어려워보임 ㅎ

파라미터로는 argc, argv, prinsipalClassName, delegateClassName이 있네요.

argc, argv보니까 c가 생각나는..

UIApplicationMain 정의까지 보는 이유는..밑에 principal, delegate Class Name이 언급되기 때문ㅇ..

-  argc : argv의 개수. 대게 main에 해당하는 파라미터입니다.

- argv : argument의 변수 목록. 대게 main에 해당하는 파라미터입니다.

- prinsipalClassName : UIApplication클래스 또는 하위 클래스의 이름입니다. nil을 지정하면, UIApplication으로 가정됩니다.

- delegateClassName : application delegate가 인스턴스화 되는 클래스 이름입니다. prinsipalClassName이 UIApplication의 하위클래스를 지정하는 경우, 하위 클래스를 delegate로 지정 할 수 있습니다. 하위클래스 인스턴스는 앱의 delegate 메세지를 받습니다. 앱의 기본 nib파일에서 delegate 객체를 로드하는 경우, nil을 지정합니다.

application 객체의 주요 역할은, 들어오는 사용자 이벤트의 초기 라우팅을 처리하는 것입니다. 컨트롤 객체(UIControl의 인스턴스)가 적절한 target 객체에 전달한 action 메세지를 전달합니다. application 객체는 열린 window(UIWindow의 객체)의 목록을 유지관리하며, 이를 통해 앱의 UIView객체를 검색할 수 있습니다.

UIApplication클래스는 UIApplicationDelegate프로토콜을 준수하고, 일부 프로토콜 메소드를 구현해야하는 delegate를 정의합니다. application 객체는 delegate에게 중요한 런타임 이벤트(예: 앱 시작, 메모리 부족 경고 및 앱 종료)를 알리고, 적절히 응답 할 기회를 제공합니다.

대부분의 앱은 UIApplication을 서브클래싱 할 필요가 없습니다. 대신 app delegate를 사용하여 시스템과 앱 간의 상호작용을 관리하세요.

앱에 들어오는 이벤트를 시스템이 처리하기 전에 처리해야하는 경우 -매우 드문경우- 사용자 정의 이벤트 또는 디스패칭 메커니즘을 구현 할 수 있습니다. 

이렇게 하려면 UIApplication을 서브클래스화하고, sendEvent(_:) 그리고/또는 sendAction(_:to:from:for:)메소드를 override하세요.

인터셉트하는 모든 이벤트에대해 이벤트를 처리 한 후, [super sendEvent:event]를 호출하여 시스템에 이벤트를 다시 전달하세요. 이벤트를 가로채는 것은 거의 필요하지 않으며, 가능하면 피해야합니다.

오..이런것을 할 수 있다는 사실이 놀랍네요.

앱이 시작되는 그 순간의 과정을 자세히 알고싶은데..

그러니까 앱이 시작되는 순간, main에서 UIApplicationMain(_:_:_:_:)가 application 객체를 만들고, delegate도 만든다.

(Objc에서는 main.m에서 UIApplicationMain(_:_:_:_:)를 호출했지만, Swift에서는 appDelegate.swift에서 AppDelegate클래스 앞에 어노테이션으로 붙은

@UIApplicationMain을 통해  UIApplicationMain(_:_:_:_:)를 호출한다고 AppDelegate.Swift의 역할에서 그랬죠?) 

그리고 UIApplicationMain(_:_:_:_:)에 파라미터가 여러개 있었는데, 가장 마지막에 delegateClassName이 있었죠? 

AppDelegate에서 UIApplicationMain(_:_:_:_:)를 호출했으니, 이 delegateClassName에 "AppDelegate"라는 이름을 전달한것과 동일합니다.

그리고, AppDelegate클래스의 인스턴스를 만들고, 이 인스턴스를 위에서 만든 application 객체에 할당한다.

(이 내용은 AppDelegate.Swift의 역할에 나와있습니다.)

즉, 지금 appDelegate와 application객체가 연결된 것. 

그리고 application객체가 delegate메소드인 application:didFinishLaunchingWithOptions:를 호출하게 됩니다.

그러면, 지금 AppDelegate가 UIApplicationDelegate를 채택하고 준수하고 있으니, 여기에 있는 application:didFinishLaunchingWithOptions:가 호출되게 되고 이제 앱이 실행됩니다.

위에서 AppDelegate의 인스턴스는 앱의 콘텐츠가 그려질 window을 만드는 역할을 한다고 했는데요, 그래서 앱을 시작하면, 하얀화면이 뜨게 되는 것이죠. 

으아아ㅏ 뭔가 헷갈리는 기분...

이건, 그럼 application 객체의 shared를 의미하는 거겠죠?