Review of Work with View Controllers (1) - Food Tracker

Understand the View Controller Lifecycle

 

하나의 씬보다 더 많은 씬을 가지고 있는 복잡한 앱에서, 우리는 화면이 이동함에 따라 view를 싣고 내리는 ( loading and unloading ) 작업을 다루어야 합니다.

 

UIViewController 클래스는 뷰 계층을 관리하기 위한 메소드를 제공합니다.

 

iOS는 하나의 View Controller의 상태가 바뀔 때 자동으로 적절한 메서드를 호출합니다.

 

UIVIewController를 서브 클래싱 한 Custom class에서 해당 메서드를 오버 라이딩하여 상태 변화에 따라 원하는 동작을 직접 구현할 수 있습니다.

 

VC의  state transition 에 따라 호출되는 메서드들

 

iOS는 아래 UIViewController 메서드를 다음 시점에서 호출합니다

---

viewDidLoad()

VC의 Contentview( Root view)가 생성 되고 storyboard에서 load 되었을 때 호출됩니다.

 

` storyboard에서 load되었을 때 `
저는 아직 storyboard와 system 및 VC와의 관계에 대해 모호하게 알고 있는 것 같습니다.
해당 문구가 완벽하게 이해되지 않아 보완하는글을 후에 작성해야 할 것 같습니다.

 

VC의 outlet 들은 이 메서드가 호출될때 모두 유효한 값들을 가지고 있게 보장됩니다.

 

즉, 메서드 바디에서 아웃렛들을 사용할 수 있습니다.

 

보통 iOS는 viewDidLoad()를 단 한 번만 호출합니다. 그 시점은 최초로 content view가 생성되었을 때입니다.

 

content view는 lazy 하게 생성됩니다. 즉, VC가 인스턴스화 되는 시점과 일치하지 않습니다

 

content view의 생성시점은 시스템이나 어떠한 코드가 VC의 view 속성에 접근하였을 때입니다.

 

VC의 view 속성에는 content view의 참조가 저장되어 있습니다.

 

viewWillAppear()

viewDidLoad()가 content view가 생성될 때 호출된다면, 이 메서드는 생성된 content view가 앱의 뷰 계층에 추가되기 직전에 호출됩니다.

 

contentview 가 기기 화면에 나오지 직전에 수행해야 할 일들을 이 메서드에 구현합니다.

 

다만 이름과 달리, 이 메서드가 호출되었다는 것이 content view가 화면에서 보인다는 것을 보장하지 않습니다.

 

view는 다른 view에 의해 가려지거나 숨겨질 수 있습니다.

 

즉 이 메서드의 호출은 단지 앱의 뷰 계층에 곧 추가된다는 것을 나타냅니다.

 

viewDidAppear()

이 메서드는 생성된 content view가 앱의 뷰 계층에 추가된 직후에 호출됩니다.

 

view가 화면에 나타난 직후에 수행할 일들을 이 메서드에 구현합니다.  ( data 불러오기, animation 보여주기 등)

 

이 메서드 또한 viewWillAppear()과 같이 호출이 content view의 가시성을 보장하지 않습니다.

 

즉 이 메서드의 호출은 단지 앱의 뷰 계층에 추가되었다는 것을 나타냅니다.

 

viewWillDisappear()

이 메서드는 생성된 content view가 앱의 뷰 계층에 제거되기 직전에 호출됩니다.

 

view 관련된 것들을 정리하는 작업을 이 메서드에서 구현합니다. ( 변경사항 적용하기, first responder 해제하기 등)

 

이름과 다르게 이 메서드의 호출이 contenview가 가려지거나 사라지는 것을 보장하지 않습니다.

 

즉 이 메서드의 호출은 단지 앱의 뷰 계층에서 곧 삭제될 것이라는 것을 나타냅니다.

 

viewDidDisappear()

이 메서드는 생성된 content view가 앱의 뷰 계층에 제거된 직후에 호출됩니다.

 

이 메서드의 호출은 단지 앱의 뷰 계층에서 삭제되었다는 것이라는 것을 나타냅니다.

---

VC가 view와 data model의 communication pipeline이 되어주는 앱 설계는 MVC 패턴으로 알려져 있습니다.

 

MVC 패턴에서, model 은 앱의 데이터를 계속 추적하고, view는 앱의 UI와 콘텐츠를 보여주고, controller는 view를 관리합니다.

 

controller는 view 와 model 사이에서 communication gateway (위에서는 communication pipeline이라고 표현)의 역할을 합니다.

 

---

 

Add a Meal Photo

Object Library에서 선택한 View를 기존에 있던 Stack View에 바로 넣는 법:

 

추가하려는 View를 Document Outline 으로 드래그하여 계층에 맞는 순서에 드랍 하면 됩니다.

 

여기서는 `Set Default Label Text` 버튼 밑에 넣어서 추가하였습니다. 

 

Size Inspector의 Instrinsic Size

Placeholder 로 설정해 놓고 Width & Height를 부여하면 뷰에 이미지가 추가되기 전에 임의로 뷰 영역을 설정할 수 있습니다.

 

이미지가 추가되면 intrinsic content size는 image의 size로 맞춰집니다. 따라서 추가되기 전까지만 사용하는 임시 값입니다.

 

실제로 앱 실행 중 layout engine은 뷰의 실제 intrinsic content size를 사용합니다!

 

 

Constraints: Aspect ratio

 Width & Height 를 각각 320으로 설정해 놓은 상태에서 Aspect ratio Constraints를 주었습니다.

 

따라서 해당 이미지뷰는 이제 항상 1 : 1 비율을 가진 정사각형 형태를 가집니다.

 

`Add New Constraints` 윈도우

---

 

Display a Default Photo

 

# Asset Catalog  #Assets.xcassets

 

Asset Catalog : 앱에서 사용할 이미지들을 저장하고 관리하는 파일 ( 이 곳에 사용할 사진들을 추가합니다. )

---

 

Connect the Image View to Code

 

Assistant Editor Shortcut : (storyboard 파일에서) ctrl + option + cmd + return

 

Views 와 Controls, 두 용어를 구분하는 미묘한 차이 (a nuanced distinction)

우선 Controls (UIControl)은 Views(UIView) 의 Subclass 입니다.

 

즉 controls 는 항상 views 인 동시에 controls 이지만, views 는 항상 controls 는 아닙니다.

 

views는 콘텐츠를 보여주는 역할만 하면 되고, control 은 콘텐츠를 어떠한 방식으로 교체하는 역할을 추가적으로 가지고 있습니다.

 

view 의 예로는 lables, image views 가 있습니다.

 

control 의 예로는 text fields, buttons가 있습니다.

 

Xcode 에서 views인 UIImageView 를 `control drag & drop` 하여 VC와의 Connection을 만들어 보겠습니다.

 

  Connection 타입이 Outlet 만 가능한 것을 확인할 수 있습니다.

 

UIImageView는 controls 가 아닌 views 이기 때문에, 어떤 이벤트가 발생하여 처리되지 않기 때문입니다.

 

views에 이벤트 처리를 넣는 방법으로는 views에 gesture recognizer를 추가하는 방법이 있습니다.

 

해당 내용은 다음 글에서 이어서 작성하겠습니다!

---

 

 

 

 

끝!

---

 

다음 글: Review of Work with View Controllers (2) - Food Tracker

Review of Work with View Controllers (2) - Food Tracker