[iOS - WWDC2019] UISceneDelegate: Multiple Window를 사용하는 앱의 설계

🍎 WWDC19 세션을 번역하며 공부한 글입니다! 의역이나 오역이 있을 수 있으니 자세한 내용은 세션 영상을 참고해주세요!

App Delegate와 Scene Delegate

iOS 12까지의 App Delegate 의 역할을 먼저 살펴보겠습니다. App Delegate는 두 가지 주요한 역할을 담당하고 있었습니다. 첫번째는 프로세스 레벨의 이벤트를 애플리케이션에 알리는 것이었습니다. 프로세스가 시작되거나, 종료될 때, AppDelegate를 통해 이벤트들이 애플리케이션에 전달되었습니다. 그리고 두번째 역할은 애플리케이션이 자신의 UI의 상태를 알 수 있게끔 하는 것이었습니다.

DidEnterForeGround, WillResignActive와 같은 메서드를 통해 시스템은UI의 상태를 알 수 있었죠. App Delegate의 이런 역할은 iOS 12까지는 큰 문제가 없었습니다. 모든 애플리케이션은 하나의 프로세스를 가지고, 이 프로세스를 사용해서 하나의 UI를 가졌기 때문입니다.

여러분들이 사용하던 AppDelegate는 아마도 이렇게 구성되어있겠죠 예를 들어, didFinishingLaunchingWithOptions 에는 데이터베이스를 연결하고 UI를 설정하는, 최초 1회만 실행하는 작업들이 정의되어 있을 것입니다.

이런 패턴은 iOS 12까지는 아주아주 괜찮았습니다. 하지만 iOS 13부터는 불가능하죠.

왜냐하면 이제부터는 애플리케이션이 여전히 하나의 프로세스만을 사용하지만, 여러개의 Scene 세션이나 UI 인스턴스를 가질 수 있게되었기 때문입니다.

따라서 App Delegate는 더 이상 UI 생명주기와 관련된 작업들을 책임질 수 없게됩니다. 대신, UISceneDelegate를 통해서 UI와 관련된 작업을 하도록 변경되었습니다. 즉, 여러분들이 App Delegate에서 정의했던 UI작업들을 그와 대응되UISceneDelegate 이동해야한다는 뜻입니다.

더 이상 iOS는 App Delegate에 존재하는 UI관련된 메서드를 실행하지 않습니다. 그렇다면 iOS 13을 위해 구현하면 iOS 12는 호환하지 못하는걸까요? 그렇지 않습니다. UIApplicationDelegate와 UISceneDelegate를 모두 구현해두면, 배포하는 버전에 맞추어 UIKit이 실행중에 자신에게 맞는 메서드를 찾아갑니다.

AppDelegate는 추가적인 역할을 하나 더 부여받습니다. 이제 새로운 Scene Session이 시작되거나 종료되면 AppDelegate는 이에 대한 알림을 받게됩니다.

여기에 보이는 파란색 애플리케이션을 처음부터 실행해본다고 합시다.

가장 먼저 App Delegate가 didFinishLaunching을 받습니다. 여전히 UI과 관련되어 있지 않은 초기 설정들은 이곳에서 해줄 수 있습니다. 그리고 곧바로 시스템이 Scene Session을 생성합니다.

하지만 실제로 UI Scene 을 생성하기 전에, 애플리케이션에게 UIScene Configuration을 시스템이 요구합니다. 여기서 Configuration은 어떤 스토리보드나, Scene delegate, scene의 서브클래스들을 Scene과 함께 생성할지 결정하는 것을 의미합니다.

 

여기까지 실행되면 애플리케이션이 실행되고 Scene Session이 시작됩니다. 하지만 아직 UI는 볼 수 없죠. 이 시점에서 SceneDelegate가 Scene Session과 연결되는 작업이 시작됩니다.

UISceneDelegate에서는 전달된 UIScene 을 통해 UIWindow를 생성합니다. 그리고 더 중요한 것은 생성된 window와 관련된 사용자의 활동이나 상태 복원을 확인해야한다는 것입니다. 상태를 복원하는 내용은 잠시 뒤에 더 자세히 설명하겠습니다.

이제 우리는 애플리케이션 화면을 볼 수 있습니다!

이제 여기서 사용자가 스와이프해서 홈으로 다시 이동하면 어떻게 될까요?
이전처럼 willResignActive와 didEnterBackground 가 호출됩니다.

그리고 얼마 정도의 시간이 지나면 실행되었던 Scene의 연결이 끊어집니다.

연결이 끊어진다는 것은 어떤 것을 의미할까요? Scene 이 메모리에서 해제됨을 의미합니다. 그리고 이는 곧 sceneDelegate가 메모리에서 해제되고 이 sceneDelegate로 생성했던 window 계층과 뷰 계층들이 모두 함께 해제됨을 의미합니다.

이런 방식은 해당 Scene과 관련되 메모리를 차지하고 있던 애플리케이션의 리소스를 해제할 수 있도록 도와줍니다. 하지만 나중에 해당 Scene 이 다시 시작도리 수도 있기 때문에 사용자 정보나 상태를 영구적으로 삭제해버리면 안되겠죠.

이번에는 사용자가 앱을 위로 스와이프해서 완전히 종료하고자 한다면 어떨까요? 시스템은 App Delegate 의 didDiscardSceneSession을 호출합니다. 여기서 우리는 사용자데이터나 상태를 완전히 지울 수 있습니다. 메모 앱에서 임시저장된 정보를 삭제하는 것 처럼요.

또 다른 경우에는 사용자가 앱 스위쳐를 열어서 실제로는 실행중이지 않는 앱을 종료하고자 할 수도 있습니다. 만약 그 프로세스가 실행중이지 않다면, 시스템은 Discarded Session을 그대로 추적하고 있다가, 애플리케이션이 다음에 다시 실행됐을 때 다시 호출하게됩니다. (개인적 견해 -> 불필요하게 프로세스를 다시 실행하는 작업을 하지 않고 다음번에 실행되었을 때 초기화하는 과정을 진행하기 위해서가 아닐까요..? 명확한 이유를 아시는 분이 계시면 댓글 부탁드리겠습니다ㅠ)

상태 복원하기

iOS13 에서는 Scene을 기반으로한 상태 복원이 아주 중요합니다. 왜 중요한지 한번 알아볼게요.

앱 스위쳐가 있습니다. 여행은 준비하고 있기 때문에 4개의 문서 애플리케이션 세션을 실행하고 있습니다. 만약 제가 여행준비물 리스트와 일정에 집중하고 싶다고 해보겠습니다.

백그라운드에 있던 여행 세션과 출석세션은 어떤 시점에 disconnect 되고 메모리에서 해제될 것입니다. 만약 상태 복원을 구현해두지 않았다면, 다시 여행 세션으로 이동했을 때 이전에 작업하던 내용을 볼 수 없게됩니다. 대신 완전히 새로운 화면이 시작되면 이건 좋은 사용자 경험이 아닐 것입니다.

이 문제를 어떻게 해결할까요? iOS13 은 새로운 Scene 기반 상태복원 API를 제공합니다. 그리고 사용하기에 아주 단순하죠. 이제 더 이상 뷰계층을 인코딩할 필요가 없이 window를 다시 생성하기 위한 상태를 인코딩합니다. 그리고 이는 NSUserActivity를 기반으로 합니다. 그래서 만약 애플리케이션이 handoff나 spotlight 검색을 사용한다면 이 활동들을 애플리케이션의 상태로 인코딩할 수 있습니다. 따라서 상태복원을 위한 아카이브는 다른 애플리케이션들과 동일한 레벨의 보호등급을 시스템에 제공해야합니다.

코드로는 어떻게 구현할 수 있을까요? Scene Delegate에서 우리는 Scene에 대한 상태복원을 구현하고 현재 window에서 가장 활발한 사용자 활동을 찾는 메서드를 호출합니다. 그리고 이 활동을 반환합니다.

시간이 지나고 애플리케이션이 다시 foreground로 들어오면 해당 sessiondl 상태 복원 활동을 가지고 있는지 확인합니다. 만약 있다면, 해당 활동을 그대로 사용하고, 없다면 새로운 window를 생성합니다.

이를 통해 사용자들은 백그라운드에서 애플리케이션의 scene이 해제되었는지 알 수 없게됩니다.

Scene간 데이터 동기화

마지막으로 scene 간의 동기화를 어떻게 맞추는지 알아보겠습니다.

이렇게 두 개의 scene이 있고 각 scene은 서로 다른 뷰 컨트롤러와 scene 인스턴스를 가지고 있다고 하겠습니다. 메시지를 보내면, 한쪽에만 업데이트가 됩니다.

왜 이럴까요?

많은 애플리케이션들이 가지고 있는 구조처럼, 버튼이나 어떤 이벤트가 발생했을 때, 이 이벤트들은 뷰컨트롤러에 전달되고, 뷰 컨트롤러는 자신이 가지고 있는 UI만 업데이트하기 때문입니다.

이를 해결하기 위해서는 뷰컨트롤러가 이벤트를 받으면 모델 컨트롤러에게 알려주는 방식의 구조를 만들 수 있습니다. 모델 컨트롤러는 자신과 관련된 뷰 컨트롤러나 구독자들에게 새로운 데이터로 업데이트 하라는 알림을 보내는 방식을 사용할 수 잇습니다.

이런 구조를 구현하기 위해서는 몇가지 방법들을 사용할 수 있습니다. delegate나 notification을 사용할 수도 있고, combine을 사용할 수도 있습니다.

하지만 여기서는 가볍게 사용할 수 있는 예제를 사용해보겠습니다.

이 메서드는 메시지를 전송하는 버튼이 눌렸을 때의 작업을 정의하고 있습니다. 메시지 객체를 생성하고, 뷰를 업데이트 한 뒤에 모델 컨트롤러가 데이터를 보관하도록 하고 있습니다.

우리가 먼저 해야할 일은 뷰 컨트롤러가 자기 자신의 뷰 상태를 바꾸지 못하도록 하는 것입니다. 지금은 일단 해당 코드를 지우고 잠시 뒤에 다시 돌아오겠습니다.

이제는 모델 컨트롤러의 add 메서드가 어떤 역할을 하는지 보겠습니다. 단순하게 새로운 메시지를 저장하도록 하고 있습니다.

하지만 이제 모델 컨트롤러는 다른 뷰 컨트롤러나 연결된 scene이 업데이트 되도록 알림을 보내도록 해야합니다.

그럼 어떻게 알림을 보낼 수 있을 까요? 우리는 디버깅과 테스팅이 가능한 구조화된 방식을 사용하고 싶습니다. 그럼 새로운 타입을 만들어서 업데이트 이벤트가 생겼을 때 사용해봅시다.

스위프트의 enum과 associated value를 사용합니다. 이제 새로운 메시지 타입이 생겼습니다. 이 타입은 모델 컨트롤러가 생성하고 관련된 뷰 컨트롤러나 scene에 전송됩니다.

이 객체의 전송을 위해서 NSNotificationCenter를 사용합니다. post 메서드를 정의하고 구독자들에게 알림을 보냅니다. 그리고 이때, 자기자신을 발신자로 정의해서 알림을 보냅니다.

이제 모델 컨트롤러가 새로운 메시지를 받으면, 이 메시지를 저장한 뒤에 새로운 이벤트를 생성해 발행하면 됩니다.

아까 미뤄두었던 뷰 컨트롤러를 수정해봅시다. 우리는 새로운 옵저버를 추가하고 핸들러 메서드를 정의합니다. 핸들러 메서드는 Notification 객체를 받습니다.

이벤트를 발행할 때 새로운 이벤트 자체가 발신자가 되기 때문에 단순히 발신자를 확인하는 것으로 이벤트를 받아올 수 있습니다.

그리고 associated value를 꺼내오면 새로운 메시지를 받을 수 있게됩니다. 이제 UI를 업데이트 할 수 있습니다.

그럼 다시 메시지를 보내볼까요? 양쪽에 모두 업데이트가 되네요!

오늘은 App Delegate와 Scene Delegate의 책임과 차이에 대해 이야기해봤습니다. 그리고 iOS13 에서의 상태복원이 왜 중요한지 의논했죠. 그리고 scene들을 동기화하는 방법까지 알아봤습니다.

Scene Delegate와 백그라운드에 들어갈 때 상태가 어떤식으로 유지되는지 잘 몰랐었는데 여러모로 공부가 많이 되었던 세션이었습니다! 개인적으로 번역하면서 내용을 정리한 것이기 때문에 의역이나 오역이 있을 수 있어요! 잘못된 내용이 있다면 알려주세요~! 읽어주셔서 감사합니다!