[iOS] - View Controller

🕹 View Controller

🎯 View Controller란?

• View Controller는 iOS 앱의 가장 기초가 되는 빌딩 블록이라고 할 수 있습니다. 모든 앱은 최소 한 개의 View Controller를 가지며 일반적으로 여러개의 View Controller를 갖게 됩니다.

  하나의 view controller는 일반적으로 하나의 UI 또는 스크린(a single User Interface or screen)을 관리합니다. 또한 UI와 모델(underlying data)들 사이의 상호작용을 관리합니다.

  예시를 통해 살펴보겠습니다!

  
  

  class MainViewController: UIViewController
  {
      @IBOutlet weak var textLabel:UILabel?
  
      override func viewDidLoad()
      {
          super.viewDidLoad()
  
          textLabel?.text = "Click the button..."
      }
  
      @IBAction func onButtonTap(sender: UIButton)
      {
          textLabel?.text = "Hello world!"
      }
  }

  
  

  위의 예시를 자세히 살펴보겠습니다 ☺️

  우선 MainViewController라는 ViewController를 생성했습니다. view controller는 UIViewController를 상속받습니다. 이 클래스는 Optional UILabel 타입인 프로퍼티 textLabel을 가지고 있습니다.

  프로퍼티인 textLabel은 outlet입니다. 여기서 outlet의 사전적 의미는 출구, 배출구, 표현의 수단 등으로 볼 수 있는데요, @IBOutlet은

  
  

  'InterfaceBuilder'를 사용해서 UI에서 'label과 outlet connnection을 만들수 있다'

  
  

  라는 의미를 갖습니다. 이 변수를 통해 textLabel?.text에서 .text와 같은 레이블의 값을 변경할 수 있습니다.

  그 다음 메소드인 viewDidLoad를 보면 override가 되어있는 것을 볼 수 있는데요, 상속 받은 메소드라는 의미이기 때문에 UIViewController에서 이미 정의되어 있을 것이라는 것을 알 수 있습니다. 이 메소드는 view controller life cycle의 일부이며 view controller의 일반적인 시작점이라고 볼 수 있습니다.

  마지막으로 메소드인 onButtonTap(sender:)는 @IBAction으로 정의되어 있습니다. 위의 IBOutlet과 마찬가지로 Interface Builder를 통해 작동하는 것을 볼 수 있는데 단순히 연결을 의미하는 Outlet과 다르게 어떤 동작을 일으킨다는 측면에서 Action이라는 네이밍이 붙은 것 같습니다.

  
  

• 모든 view controller에는 view property가 있습니다. 결국 view controller라는 것은 view들의 controller라고 정의할 수 있습니다. 코드에서는 UIViewController 클래스의 view property를 통해 view에 접근 가능합니다. 예시를 통해 살펴보겠습니다!

  
  

  

  
  

  위의 그림을 보면 View Controller 안에는 프로퍼티로 Table View를 갖게 됩니다. 그리고 그 Table View 안에는 Item Cell이라는 요소가 존재하고 그 안에 다시 Content View가 존재합니다. 이 Content View부터 살펴보면 ContentView는 아래 레이블들의 Super View가 되며, 레이블이나 버튼, 썸네일 등은 Sub View가 됩니다. 여기서 주의할 점은 View라는 이름이 붙은 요소 뿐만 아니라 버튼 등도 view로 이해해야한다는 점입니다.

  이제부터 조금더 자세히 View Controller에 대해 이해해보도록 하겠습니다 🎯

  
  

📐 Views, Storyboards, MVC and Controllers

• 바로 위에서 view라는 것은 view controller에서 프로퍼티로 존재한다는 것을 이야기했었습니다. 반대로 말하면 모든 view controller는 view 프로퍼티를 갖는 것이고 controller는 자연스럽게 트리 구조의 계층 구조를 갖게 됩니다.

  그래서 iOS의 View Controller를 학습하다보면 자연스럽게 이런 질문이 떠오르게 됩니다.

  
  

  "그래서 view controller는 MVC 중 View인가 Controller인가?"

  
  

  결론부터 이야기 하면, view controller는 view인 동시에 controller입니다(원문에서는 mix라고 표현하는데 허무한듸..). iOS에서는 MVC를 칼같이 나누는 것이 아니라 view controller 안에 View와 Controller라는 개념을 함께 묶었습니다.

  예시로 UITableViewController를 보면 이 클래스는 스크린에 UI 테이블을 보여주는 동시에 뒷단에서 데이터를 관리하기도 합니다. 아래의 코멘트를 살펴보도록 하겠습니다.

  
  

  The dual role of the view controller is often criticized, and for good reason. It’s easy to dump a whole lot of code into a view controller. You’d let the view controller do everything in your app’s UI, from organizing the view, to networking, user interaction, and controlling data models. This often results in what’s called Massive View Controller ...

  
  

  view controller는 View의 역할과 Controller의 역할을 모두 갖기 때문에 너무 많은 기능들이 한 곳에 모일 가능성이 있고, 객체지향의 특성상 특정 하나의 객체가 너무 많은 권한과 책임을 갖는 것은 건강하지 못한(?) 구조가 되기 쉬울 수 있기 때문에 이것을 피하는 방향으로 프로그래밍할 필요가 있다는 점을 지적하고 있습니다.

  또한 아래의 코멘트 역시 함께 읽어보도록 하겠습니다.

  
  

  In practical iOS development, you don’t create your UIs manually with Swift code. It’s more productive to use XIBs or Storyboards with Interface Builder, to visually build UIs. Interface Builder also has helpful tools to create responsive layouts for different iPhone device models and screen sizes.

  
  

  iOS 개발에서 UI를 Swift code로 수동 구현 하지 않고 XIB나 스토리보드를 통해서 구현한다는 것인데 이것은 논쟁 가능한 표현이라고 생각합니다. 인터페이스를 활용할 때의 장단점과 코드를 활용한 UI 개발의 장단점이 명확히 존재하므로 경우에 따라 선호되는 방식이 다르고, 많은 현업에서 스토리보드보다 코드를 활용해 UI를 그린다고 알고 있습니다.

  혹시 XIB나 Storyboard가 무엇인지 헷갈리시는 분들을 위해 가볍게 설명하고 넘어가도록 하겠습니다.

  
  

  XIB: XML 기반의 UI 파일입니다. 하나의 UI에 대한 정보들을 담고 있으며 일반적으로 view나 view controller에 연결됩니다.

  Storyboard: 스토리보드는 XIB와 비슷한 개념으로 하나 이상의 UI에 대한 정보를 가집니다. segue라는 화면전환 기법을 통해 view controller간 전환이 일어납니다.

  
  

  두 개념의 가장 큰 차이는 스토리보드가 일반적으로 2개 이상의 view controller를 담는다는데 있습니다. 또한 XIB는 하나의 뷰를 표현하는 반면 Storyboard는 여러개의 뷰를 가질 수 있기 때문에 전환에 대한 개념이 포함됩니다.

  하나 추가로 첨언하자면, XIB에서 중요한 개념이 File's Owner라는 것입니다. File's Owner는 런타입에 XIB를 불러오는 클래스를 의미합니다. 말 그대로 Interface Builder file을 "own(소유)"하는 것인데 이 연결이 뷰컨트롤러와 XIB를 연결합니다.

  🧐 그럼 NIB는 무엇인가요?

  XIB는 위에서 언급한대로 편집 가능한 XML 형식의 Interface Builder 파일입니다. NIB는 배포 가능한 바이너리 포맷의 파일로 app binary package에 저장됩니다.

  
  

🖇 UI를 코드에 연결하기

• 일반적으로 UI와 view controller를 연결할 때 control 버튼을 누른 상태로 끌어당겨 연결을 했었습니다. 혹은 hierarchy에서 inspector tab에 직접 연결할 수도 있겠죠? 하지만 이 방법은 Storyboard에서 사용할 때의 방식입니다. 만약 XIB에 연결한다고 하면 view controller에 연결하는 것이 아니라 File's Owner에 연결해야합니다.

  
  

  🧐 왜 textLabel 등을 선언할 때 디폴트가 weak var(약한 참조)로 선언될까?

  약한 참조의 개념을 메모리적인 관점이 아니라 조금 단순화 시켜서 생각해보겠습니다. 간단히 말하면 이것은 UI 요소(여기서는 Label)과 view controller가 약한 결합을 했다는 것을 의미합니다. Strong한 retain cycle이 생겨 memory leak이 생기는 것을 방지하는 것이죠.

  weak type일 경우 메모리에서 해제되는 시점에 언제 nil로 값이 변경될 지 모르기 때문에 항상 옵셔널 타입으로 선언되어야 합니다. 또한 viewDidLoad()가 실행되기 전에 outlet 프로퍼티들은 nil 값을 갖습니다. 아울렛 값을 옵셔널로 설정하므로써 이 값이 nil일 때 실수로 참조하는 상황을 대비해줍니다.

  그럼 우선 Strong하게 선언해도 문제가 되지 않는 상황을 가정해볼까요?

  
  

  ViewController가 있음

  ViewController가 Strong하게 someView를 소유

  IB에서 SomeView가 Label을 SubView로 Strong하게 소유

  ViewController가 위의 Label을 소유

  
  

  위 상황의 retain count를 계산해보면

  
  

  someView: 1

  Label: 2

  
  

  가 됩니다. 이 상황에서 ViewController가 dealloc 된다고 가정하겠습니다. 그럼 someView의 retain count는 이것을 참조하던 View Controller가 사라져 -1이 되어 0이 됩니다. 또 Label 역시 ViewController의 참조가 사라져 -1이 되고, 여기에 SomeView의 참조 역시 사라지므로 -2가 되어 0이 됩니다. Strong해도 전혀 문제가 없는 구조입니다.

  만약 복잡한 View Hierarchy에서 특정 subView가 다른 subView2를 가질 때 subView가 의도치 않게 해제될 경우 subView2가 메모리에서 사라지게 될 수 있습니다. 이런 경우는 Strong한 선언이 필요하죠.

  그럼 항상 Strong을 사용해도 괜찮을까요? 당연히 아닙니다. 메모리 부족의 가능성이 있기 때문입니다. 메모리가 부족하면 ViewController의 메소드인 didReceiveMemoryWarning이 호출됩니다. 일반적으로 didReceiveMemoryWarning에서 mainView를 nil로 처리해서 mainView에 포함된 모든 Sub View들을 dealloc합니다. 이를 통해 메모리를 확보하는 것이죠.

  이 경우에 만약 IBOutlet이 Strong한 Subview들을 갖고 있다면 그 SubView들의 Reference Count가 1 이하로 절대 내려가지 않습니다. 즉 SuperView가 nil이 되도 SubView는 dealloc되지 않습니다. 작동하지 않는 뷰가 메모리에 상주하게 되는 상황이 발생합니다.

  
  

  🧐 outlet 없이 UI element를 연결할 수 있을까?

  가능합니다! 귀찮긴 하지만 viewWithTag(_:)라는 메소드를 통해 구현 가능합니다.

🧗 View Controller Hierarchy(계층 구조)

• view controller는 tree와 같은 구조의 계층을 가집니다. 모든 iOS 앱들은 main window가 있고, 모든 window는 root view controller를 가집니다. 이 view controller가 app window의 최초 화면이 됩니다. 하나의 앱은 하나 이상의 window를 가질 수 있습니다. Window 그 자체는 시각적인 요소를 가질 수 없고, view controller의 view가 app의 UI 요소들을 제공합니다.

  AppDelegate의 메소드를 살펴보도록 하겠습니다.

  class AppDelegate: UIResponder, UIApplicationDelegate 
  {
      var window:UIWindow?
  
      func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool
      {
          let mainViewController = MainViewController()
          mainViewController.title = "Main"
  
          let frame = UIScreen.main.bounds
          window = UIWindow(frame: frame)
  
          window!.rootViewController = mainViewController
          window!.makeKeyAndVisible()
  
          return true
      }
  }

  위의 코드는 app의 시작점이 됩니다. 이 시작점에서 최초의 ViewController 객체를 생성하는 것을 볼 수 있습니다. 그리고 UIWindow 객체를 생성하고 메소드를 통해 그 윈도우에 view controller 객체를 부여하고 makeKeyAndVisible 메소드를 통해 해당 View를 보여주게 됩니다.

  🧐 Storyboard로 UI를 그릴 때 한번도 이런 작업을 해준 적이 없는데?!

  우리는 사실 이 작업을 Storyboard에서 화면을 만들 때마다 하고 있었습니다. "Is Initial View Controller" 선택을 하면 자동으로 위의 로직을 실행시켜 줍니다.

  대부분의 앱들은 UITabBarController, UINavigationController, UISplitViewController, UIPageViewController와 같은 "container view controller" 를 사용합니다. 이러한 view controller들은 많은 view controller들을 관리가능한 인터페이스와 요소로서 관리합니다.

👨🏼‍⚕️ View Controller Life Cycle

• 이번엔 View Controller의 Life Cycle에 대해 이야기해보도록 하겠습니다. App의 Life Cycle이 아닌 View의 Life Cycle입니다!

  
  

  

  
  

  view controller의 생명은 당연히 초기화 시점에 시작됩니다. view controller 객체가 생성되며 view의 프로퍼티인 content view가 생성됩니다(앞서 언급한 storyboard나 XIB의 형태). 이렇게 view까지 생성되고 나면 viewDidLoad 메소드가 호출됩니다.

  일반적으로 이 viewDidLoad메소드는 최초 한번만 실행됩니다. 그리고 이 viewDidLoad는 애초에 UIViewController에 존재하기 때문에 우리가 구현하는 메소드는 override function이 되어야 합니다. 직접 구현하는 view controller는 이 UIViewController를 상속하게 되기 때문입니다.

  이 시점에서 outlet들은 값을 가져야 하기 때문에 일반적으로 viewDidLoad는 view를 구현할 때 최초의 포인트가 되고 이 곳에 기본적인 값들을 구현합니다.

  
  

  🧐 view controller 객체가 생성되면 바로 viewDidLoad가 실행되는 것인가?

  결론부터 말하자면 아닙니다. view controller의 초기화 즉시 메소드가 실행되는 것이 아니라 lazy하게 선언되어 view property에 처음 접근이 일어났을 경우 메소드가 실행됩니다.

  
  

  이렇게 viewDidLoad가 실행되고 나면 view controller는 Appear/Disappear의 상태를 가지게 됩니다. 그리고 그 시점에 따라 will/Did의 상태를 가지게 됩니다. 이를 표로 나타내면 아래와 같습니다.

  
  

  	Will	Did
  Appear	viewWillAppear(_:)	viewDidAppear(_:)
  Disappear	viewWillDisappear(_:)	viewDidDisappear(_:)

  
  

  위의 그림과 표를 비교해보면 순서를 이해하기 더 편합니다. 당연히 view가 나타나기 전에 viewWillAppear가 동작하고, 나타나면 viewDidAppear가 동작합니다. 그리고 이제 view가 사라지게 되면 viewWillDisappear가 호출되고 사라지면 viewDidDisappear가 호출됩니다. 네이밍의 중요성을 새삼 느끼게 됩니다 :)

  
  

  각 메소드들은 파라미터로 animated of type Bool을 갖게 됩니다. 즉 view의 생명(?)변화가 일어날 때 애니메이션 효과를 줄 것인지에 대한 옵션입니다. 이러한 메소드를 호출할 때, 단순히 override된 메소드만 호출하는 것이 아니라 상위 클래스(UIViewController)에 이미 선언되어있는 메소드, 즉 super.method()를 먼저 호출하게 됩니다.

  
  

  🚓 이러한 lifecycle function들은 view가 눈에서 사라질 때 작동한다?

  일반적으로 하기 쉬운 오해로 엄밀히 정의하면 사실이 아닙니다. 이러한 메소드들은 기본적으로 view controller의 content view가 view hierarchy에서 추가되거나 사라짐을 기준으로 합니다.

  
  

  위의 자료들을 기반으로 각 메소드에 작성해야할 내용들을 정리해보겠습니다.

  
  

  viewDidLoad: view controller의 진입 포인트

  viewWillAppear: viewController의 content view가 view hierarchy에 추가되기 전 동작. viewController가 화면에 보이기 직전 일어나야하는 단순 연산

  viewDidAppear: viewController의 content view가 view hierarchy에 추가된 후 동작. 화면이 나타남과 동시에 시작되야할 연산(e.g. 데이터 불러오기)

  viewWillDisappear: viewController의 content view가 view hierarchy에 삭제되기 전 동작. 키보드를 숨기거나 특정 작업을 저장하는 등 화면이 사라지기 전 동작해야할 작업

  viewDidDisappear: viewController의 content view가 view hierarchy에 삭제된 후 동작. 메모리에 적재된 추후 재생성 가능한 데이터 제거 등 마무리 작업

  
  

  위의 내용을 기반으로 예시를 작성해보겠습니다.

  
  

  viewDidLoad: on-screen messageLabel에 표현될 문자 프로퍼티 세팅

  viewWillAppear: 백엔드에서 변경된 새로운 UI 정보 업데이트

  viewDidAppear: 로그인 여부를 확인하고 LoginViewController 띄우기

  viewWillDisappear: 변경사항 db 저장

  viewDidDisappear: 메모리 관리(tear down view controller)

Reference: https://learnappmaking.com/view-controller-uiviewcontroller-ios-swift/