상태 변화에따라 다른 동작을 처리하기 위한 앱델리게이트 메서들을 설명하시오.

• 애플리케이션이 실행된 직후 사용자의 화면에 보여지기 직전에 호출
  func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool

• 애플리케이션이 최초 실행될 때 호출되는 메소드
  func application(_ application: UIApplication, willFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool

• 애플리케이션이 InActive 상태로 전환되기 직전에 호출 task 일시정지, 타이머 비활성화, 일시정지(게임)
  func applicationWillResignActive(_ application: UIApplication)

• 애플리케이션이 백그라운드 상태로 전환된 직후 호출
  func applicationDidEnterBackground(_ application: UIApplication)

• 애플리케이션이 Active 상태가 되기 직전, 화면에 보여지기 직전에 호출
  func applicationWillEnterForeground(_ application: UIApplication)

• 애플리케이션이 Active 상태로 전환된 직후 호출
  func applicationDidBecomeActive(_ application: UIApplication)

• 애플리케이션이 종료되기 직전에 호출
  func applicationWillTerminate(_ application: UIApplication)

Appdelegate의 역할은?
iOS 12 이전에는 app의 launch, foregrounding, backgrounding 등 App Life-Cycle을 관리하는 책임을 갖고 있었다.

iOS 13 이후로 갖는 역할
1. 앱의 가장 중요한 데이터 구조를 초기화하는 것
2. 앱의 scene을 환경설정(Configuration)하는 것
3. 앱 밖에서 발생한 알림(배터리 부족, 다운로드 완료 등)에 대응하는 것
4. 특정한 scenes, views, view controllers에 한정되지 않고 앱 자체를 타겟하는 이벤트에 대응하는 것.
5. 애플 푸쉬 알림 서브스와 같이 실행시 요구되는 모든 서비스를 등록하는것.

위 사진과 같이 Life-Cycle을 관리하는 책임을 Scene Delegate에게 넘겨주고
Proess Lifecycle역할이 추가된다.

Scene Session이 생성되거나 삭제될 때 AppDelegate에 알리는 두 개의 메소드가 추가됐다.
Scene Session은 앱에서 생성한 모든 scene의 정보를 관리한다.

• Scene?
  -> Scene에는 UI의 하나의 인스턴스를 나타내는 windows와 view controllers가 들어있다. 결과적으로 하나의 앱은 여러 scene과 scene delegate 객체를 동시에 활성화할 수 있다.
• Scene Session?
  -> scene의 고유의 런타임 인스턴스를 관리한다. 사용자가 앱에 새로운 scene을 추가하거나 프로그래밍적으로 scene을 요청하면, 시스탬은 그 scene을 추적하는 session 객체를 생성한다. 그 session에는 고유한 식별자와 scene의 구성 세부사항(configuration details)가 들어있다.

AppDelegate and SceneDelegate 역할

UIApplicationDelegate

---

Delegate 패턴을 활용하는 경우를 예를 들어 설명하시오.

Delegate 패턴: 객체의 할일을 다른 객체에게 위임하는 것

테이블뷰 - 셀 , 컬렉션뷰 - 셀 의 관계에서 많이 사용하게된다.
테이블뷰 셀에 있는 버튼을 눌렀을때 셀이 추가되거나 삭제되게 하는 경우 -> 셀에 프로토콜과 delegate를 선언하여, TableView가 있는 ViewController에 Delegate Protocol을 상속받아서 해당 셀에 맞는 indexPath를 구하여서 셀을 추가 하거나 삭제한다.
(선택된 셀의 이벤트 및 indexPath 셀정보를 TableView를 가진 ViewController에게 위임해준다.)

장점

• 매우 엄격한 Syntax로 인해 프로토콜에 필요한 메서드들이 명확하게 명시된다.
• 컴파일 시 경고나 에러가 떠서 프로토콜의 구현되지 않은 메소드들을 알려준다
• 로직의 흐름을 따라가기 쉽다
• 프로토콜 메소드로 알려주는 것 뿐만 아니라 정보를 받을 수 있다.
• 커뮤니케이션 과정을 유지하고 모니터링하는 제 3의 객체가 필요없다. (NotificationCenter같은 외부 객체)
• 프로토콜이 컨트롤러의 범위 안에서 정의된다.
• 재사용하고 유지보수하기 쉬워진다.

단점

• 많은 줄의 코드가 필요하다
• delegate 설정에 nil이 들어가지 않게 주의해야한다. 크래시를 일으킬 수 있다.
• 많은 객체들에게 이벤트를 알려주는 것이 어렵고 비효율적이다. (가능은 하다.)

Delegate 패턴에 대하여

---

Singleton 패턴을 활용하는 경우를 예를 들어 설명하시오.

Singleton 패턴

• 싱글톤 패턴은 특정 용도로 객체를 하나 생성해서 공용으로 사용하고 싶을 때 사용하는 방법이다.
• 많이 사용하다보면 코드의 결합도가 높아지고 테스트하기 어려운 코드가 된다.

ex)

URLSession

-> 네트워크 처리를 할 때 URLSession 객체를 이용하는데, 이미 만들어져있는 shared 객체에 접근해 메서드를 수행한다.

UserDefaults

-> UserDefaults에서 기본적으로 공유하고 있는 standard 저장소에 접근해 쓰고 읽기 위해 만들어져있는 standard 에 접근해 메서드를 수행한다.

이외에도 NotificationCenter.default, UIScreen.main 등 여러 곳에 사용된다.

장점

• 인스턴스가 1번만 생성되기 때문에 메모리 낭비를 방지할 수 있다
• 전역 인스턴스로 사용할 수 있기 때문에 메모리 및 자원 관리가 쉽다
• 메모리를 할당하고 초기화하는 시간이 줄어들어 객체 접근 시간이 줄어든다

단점

• 생성자가 private 이기 때문에 Mock 객체를 만들어내기 어려워 테스트가 힘들다
• 어느곳에서나 쉽게 접근이 가능해 의존성이 생긴다
• 멀티 스레드 환경에서 객체가 2개 생성되는 위험이 발생할수 있다
• 싱글턴은 런타임에 메모리에 할당되고 앱이 종료될 때까지 사라지지 않는다. 따라서 필요한 곳에 알맞게 쓰는 것이 중요하다.

개인적인 기준은 하나의 객체를 여러 곳에서 사용해야 될 때 사용하는 것이 좋다고 생각했다.