Model - View - Controller의 앞글자를 따서 이름이 지어짐
Model : 앱의 데이터 및 비즈니스 로직을 관리
View : 데이터의 시각적 표현을 제공
Controller : 모델과 뷰 객체 사이의 다리 역할을 수행 (적절한 타이밍에 데이터를 이동시킴)
AppDelegate : 앱 전반의 동작에 관여
SceneDelegate : Scene의 동작에 관여
ViewController : 앱과 Scene 위에서 실제로 표현될 여러 뷰에 대한 상태와 변화를 담당
storyboard (Main, LaunchScreen) : 앱의 인터페이스 담당
Info.plist : 앱의 동작 직전에 앱의 정보를 받아옴
뷰와 모델의 상호의존성을 없애고, 컨트롤러가 뷰와 모델의 중간다리 역할 수행하는 아래의 그림이
MVC 모델의 이상적인 형태일 것이다.
하지만, 실상은 조금 다르다
실제로는 View와 ViewController의 결합성이 너무 강하다.
View, Controller가 거의 모든 일을 담당해버리고 Controller가 View의 LifeCycle에 관여하기 때문에 이들의 결합성을 약화시키기도 힘들다.
이 상태에서 프로젝트의 규모가 커질수록 Controller가 비대해지고 내부구조가 복잡해져서 유지보수가 힘들어진다.
이러한 MVC 패턴의 문제점을 해결하기 위해 MVVM, VIPER 패턴 등이 등장했다.
(공식문서)
UIApplicationMain
어플리케이션 객체와 이에 대한 Delegate를 생성하고, Event Cycle을 만드는 함수
func UIApplicationMain(
argc: Int32,
argv: UnsafeMutablePointer<UnsafeMutablePointer<CChar>?>,
principalClassName: String?,
delegateClassName: String?
) -> Int32
argc : argv의 count에 해당함, main에 상응하는 parameter
argv : 인자 리스트 변수, main에 상응하는 parameter
principalClassName : UIApplication 클래스의 이름
=> UIApplicationMain이 실행되면 UIApplication 객체가 싱글톤 패턴으로 하나가 생성됨
delegateClassName : application delegate가 인스턴스화되는 클래스의 이름
반환 타입이 Int32이긴 하지만, 사용자가 iOS App을 exit하지 않는 이상 정수 반환 값이 지정되어도 앱은 절대 종료되지 않는다는 특징이 있다.
NSMainNibFile
key와 적절한 nib file 명을 포함시켜주어서 해당 nib file을 UIApplicationMain이 load 할 수 있도록 해준다.사실상 UIApplicationMain은
앱 객체 생성 프로세스 핸들링, UI와 기능을 읽어 구현, 이벤트 루프 실행
이 모든 것을 다 하기 때문에 앱 그 자체로 볼 수 있다.
App Start -> UIApplicationMain 실행 -> UIApplication 생성 -> AppDelegate 생성 -> 해당 클래스에 있는 application 메소드를 실행시켜 개발자가 써 놓은 코드 실행
UIApplication의 권한을 위임받아 커스텀 코드와 상호작용하여 코드를 실제 뷰와 컨트롤러로 보여지게, 그리고 동작하게 한다.
앱이 꺼지기 직전까지 쭉 이벤트 루프를 돌면서 뷰를 생성하고, 동작하게 함.
앱의 여러 뷰와 각각의 뷰를 제어하는 컨트롤러가 사용자와 상호작용하는 것으로 볼 수 있음.
이벤트 루프 실행 -> AppDelegate의 applicationWillTermintate 실행 -> 앱 종료
앱이 꺼지기 직전까지는 이벤트 루프가 실행
종료직전에 AppDelegate의 applicationWillTerminate 메소드가 실행
해당 메소드 안에 적혀 있는 커스텀 코드에 따라 종료 직전 처리해야 할 일들을 모두 완료
앱이 최종적으로 종료됨
참고링크 : https://2unbini.github.io/%F0%9F%93%82%20all/swift/UIKit-2/