앱이 In-Active 상태가 되는 시나리오를 설명하시오.
In-active(비활성화): 앱이 실행되면서 포어그라운드에 진입하지만 어떠한 이벤트도 받지 않는 상태이다.
- 앱 사용 중 전화나 메시지 같은 interrupt 발생 시
- 미리알림 같은 특정 알림창이 화면을 덮어서 앱이 실질적으로 event를 받지 못하는 상태 등이 여기에 해당한다.
- 메시지를 카카오톡 앱으로 공유하고자 할 때, 메시지 앱은 In-Active 상태가 된다.
- 다른 상태로 넘어가기 전에 앱은 반드시 이 상태를 거친다.
ex)
사용자가 앱을 실행한다: Not running » In-Active » Active
앱 실행 도중 홈버튼을 누른다: Active » In-Active » Background
앱을 다시 켠다: Background » In-Active » Active
앱이 백그라운에 있다가 Suspended 상태로 전이: Active » In-Active » Background » Suspended
scene delegate에 대해 설명하시오.
Scene delegate 는 iOS 13에 새롭게 생긴 개념으로 iOS 13이전에는 App delegate 가 모든 역할을 담당하고 있었다. iOS 13 이전, App delegate 의 역할은 크게 두 가지로 애플리케이션에게 프로세스 level의 이벤트와 UI의 상태변화를 알려주는 것이다.
iOS 13이후에는 Scene delegate 가 메소드를 통해 애플리케이션에게 UI의 상태변화를 알리는 역할을 대신하게 되었고 App delegate 는 애플리케이션에게 프로세스 level의 이벤트를 알려주는 역할을 그대로 수행하고 session life-cycle 을 알려주는 역할을 추가로 맡게 됐다.
이러한 변화로 인해 하나의 앱에서 여러개의 scene 을 가질 수 있게 됐다.
KVO 동작 방식에 대해 설명하시오.
KVO는 Key-Value Observing의 약자로 특정한 변수가 변경될 때마다 코드가 실행되도록 하는 기능이다.
property observers(willset , didSet)과 아주 유사한데 KVO는 타입 정의 밖에서 observe를 추가한다는 점이 다르다. 모델과 뷰 등 논리적으로 분리된 앱 부분간에 변경사항을 전달하는데 유용하다고 한다. KVO는 순수 스위프트 코드로는 그리 좋지 않은데, 그 이유는 Objective-c 런타임에 의존 하고 있기 때문이다. 그래서 NSObject를 상속받기 위해 @objc 를 반드시 붙여줘야 한다. 특히 KVO는 속성 각각에 @objc dynamic 을 붙여줘야 한다.
Property Observers
: KVO와 비슷하지만, NSObject를 상속받을 수 없는 값 타입에도 적용 할 수 있다는 점이 장점이다. 하지만 Property Observer는 타입 선언의 일부이기 때문에 정적이고, KVO는 런타임에 동적으로 추가하는 것이라는 차이가 있다.
Apple의 프레임워크는 KVO를 적극적으로 활용하고 있다. 특히 요즘 많이 등장하는 개념인 데이터 바인딩(Data Binding)을 외부 프레임워크에 의존하지 않고 구현할 수 있다는 점에서, 반드시 알아두어야 할 기술이라 할 수 있다.
Delegates와 Notification 방식의 차이점에 대해 설명하시오.
어플리케이션의 특성상 객체 간의 소통은 필수적다. 하지만, 다른 객체에 종속되어 동작하는 것은 재사용성과 독립적 기능요소 측면에서 볼 때는 바람직하지 않다. 그래서 하나의 객체가 다른 객체와 소통은 하지만 묶이기는 싫을 경우에 사용하기 위해서 등장했다.
공통점 : 세 패턴 모두 특정 이벤트가 일어나면 원하는 객체에 알려주어 해당되는 처리를 하는 방식입니다.
Delegate는 한 화면에서 많은 이벤트와, 해당되는 객체의 데이터를 가져와야할 때 쓰면 적합하다고 생각한다. TableView의 Delegate함수를 보면 셀 갯수, 셀 설정, 셀 크기, 등 많은 이벤트를 위한 함수와, 이벤트가 발생했을 때 가져올 수 있는 데이터에 접근하기위한 변수들이 설정 되어있듯 한 속성에대한 다양한 이벤트를 처리하기 위해서는 Delegate가 적합하다고 생각한다.
Notification은 한 이벤트에 대해 다수의 수신자가 있을 경우에 쓰면 좋을 것 같다. UI의 업데이트를 위한 이벤트를 받을 때, 화면 간 연결 관계가 없을 때, 바로 다음 화면이 아닌 건너건너 depth가 깊은 화면에 이벤트를 줄 때 좋을 것 같아요. 깊이가 깊다면 Delegate를 채택하고 객체를 담을 변수를 전달하는 과정이 복잡하다고 생각한다.
