[iOS-WWDC2019] Combine 사용하기 (2) - Subscriber

Combine in Practice 

지난 포스트에 이어서 세션의 나머지 부분인 Subscriber 주제에 대해 정리해보겠습니다! 오역이나 의역이 있을 수 있으니 더 자세하고 명확한 내용은 아래 세션에서 확인해보세요!

Combine in Practice - WWDC19 - Videos - Apple Developer

Subscriber 

Publisher와 마찬가지로 Subscriber 역시 두 개의 Associated Type를 가집니다. Input과 Failure 이죠. 그리고 세 개의 이벤트 함수를 가지고 있습니다. 이 함수들이 불리는 순서는 다음 규칙을 따릅니다.

첫번째 규칙은 Publisher과 구독자를 등록하는 행동에 반응해서 딱 한 번 receive(subscription:) 함수를 호출합니다.

두번째 규칙입니다. Publisher는 0개 이상의 값을Subscriber가 요청했을 때 downstream을 통해 제공할 수 있습니다.

마지막으로 Publisher는 최소한 하나의 완료신호를 보낼 수 있습니다. 이때 Publisher는 자신이 완료되었거나, 실패했음을 알릴 수 있습니다.

다시 정리해봅시다. Subscriber는 하나의 subscription을 받고, 0개 이상의 값을 전달받을 수 있으며, 최소한 하나의 완료, 혹은 실패 신호를 받을 수 있습니다. 그리고 완료신호는 옵셔널이기 때문에, 많은 stream은 NotificationCenter처럼 종료되지 않고 계속 동작할 수도 있습니다.

컴바인에서는 다양한 종류의 Subscriber들을 지원합니다. 이들이 어떻게 동작하는지 살펴봅시다.

이전 포스트에서 만들었던 이 Publisher 예제를 그대로 사용하겠습니다.

Key Path Assignment

먼저 컴바인에서 가장 간단한 Subscriber인 Key Path Assignment를 봅시다. Key Path Assignment는 assign(to: on:) operator를 사용합니다. 이 함수는 Publisher가 방출한 값이 특정한 Key Path에 할당된 객체에 전달됩니다. 

assign operator도 역시 cancellation 토큰을 생성해서 subscription을 종료하도록 할 수 있습니다. 

Cancellation

Cancellation에 대한 이야기를 조금 더 해봅시다. 우리는 컴바인 안에 Cancellation을 포함시켰습니다. Cancellation은 Publisher가 이벤트를 전달하기 전에 Subscription을 종료할 수 있는 이점을 주기 때문이죠. 이 특징은 특히 subscription과 관련된 리소스를 해제할 때 유용하게 사용될 수 있습니다.

저희는 Cancel에 대한 새로운 프로토콜을 도입했고 굉장히 용용한 AnyCancellable을 소개해드리려고 합니다. AnyCancellable은 deinit 단계에서 자동으로 cancel을 호출하는 강력한 타입입니다. 이제 Swift에게 메모리 관리를 맡기고 여러분들이 직접 cancel을 호출하지 않아도 되도록 합니다.

Sink

이제 두번째 Subscription 타입인 sink 를 알아봅시다.

Sink는 진짜 환상적이에요! 여러분들은 단지 전달받는 값에 대한 클로저를 제공하면 새로운 값이 전달될 때마다 해당 클로저가 실행됩니다. 또한, sink는 cancellable을 반환해서 이를 이용해 subscription을 종료시킬 수도 있습니다.

 

Subjects

세 번째 유형의 subscription은 혼합된 유형입니다. Publisher 같으면서도, Subscriber 같죠. Subjects는 멀티캐스팅을 지원하고 값을 필수적으로 전송하게 할 수 있습니다. 이 특징은 특히 코드 베이스의 작업을 할 때 유리하게 사용할 수 있습니다. 

 

먼저 Subjects가 어떻게 동작하는지 보겠습니다.

앞서 설명했던 것 처럼 subject를 사용하면 여러개의 downstream에 브로드캐스팅하는 것이 가능합니다. 이것은 값이 send를 통해 전송되지 않고, upstream Publisher가 값을 방출하는 경우에도 마찬가지입니다.

컴바인은 두 가지 종류의 Subject를 지원합니다. 먼저, Passthrough는 값을 저장하지 않습니다. 그래서 subscribe를 하지 않으면 값을 확인할 수 없습니다. 반면에 CurrentValue는 마지막으로 받았던 값을 기록해서 새로운 Subscriber가 연결되어도 값을 계속 추적하게 할 수 있습니다.

이제 어떻게 사용할 수 있는지 봅시다. Publisher는 이전 예제에서 만들었던 그대로 사용하겠습니다. Subject는 Output과 Failure Type을 지정하고 생성자를 호출하는 것으로 만들 수 있습니다. Subject는 Subscriber처럼 동작합니다. upstream Publisher를 구독할 수 있습니다.

그리고 sink와 같은 Operator를 통해 Publisher처럼 Subscriber를 등록할 수도 있습니다.

그럼 이렇게 값을 전송하는 것도 가능합니다.

그리고 실제로, Subject는 자주 도착하기 때문에 스트림에 subject를 주입할 수 있는 operator도 제공합니다. share operator는 Passthrough subject를 스트림에 주입합니다. Subject는 굉장히 강력하고 유용합니다. 그리고 이제 마지막으로 SwiftUI와 통합된 네 번째 유형의 Subject를 소개하겠습니다.

SwiftUI

SwiftUI의 놀라운 점은 여러분은 애플리케이션에 의존성을 설명해주면 나머지는 프레임워크에서 모두 관리해준다는 것입니다. 컴바인의 관점에서 이 특징은 여러분이 데이터가 언제, 어떻게 변경되는지 정의된 Publisher만 제공해주면 된다는 것을 의미합니다. 

이를 위해서 여러분은 단순하게 커스텀 타입이 BindableObject 프로토콜을 채택하도록 해주기만 하면 됩니다. 

SwfitUI의 BindableObject는 하나의 associated type을 가집니다. 바로 Never를 failure type으로 가지는 publisher이죠. 이는 UI 프레임워크 작업과 잘 어울립니다. Publisher에 도착하기 전에 upstream error를 처리하도록 강제하기 때문이죠. 

마지막으로 didChange 프로퍼티를 정의합니다. didChange는 실제 Publisher에게 해당 프로토콜을 채택한 타입의 값이 바뀌었다는 것을 알립니다.

 

더 자세한 이야기들은 SwiftUI Talk에서 다루고, 여기서는 실제로 SwiftUI에서 어떻게 사용할 수 있는지 알아보겠습니다.

SwiftUI + BindableObject

WizardModel 타입에 BindableOnbject를 추가해주었습니다. 그리고 Subject를 사용해 값의 변경을 처리하려고 합니다. 우리는 Subject를 통해 특정한 종류의 값을 전송할 필요가 없습니다. SwiftUI 프레임워크가 메서드 호출 단계에서 어떤 종류의 값을 전송해야하는지 결정합니다. 따라서 우리는 Void를 Subject의 Output Type으로 지정합니다.

이제 값이 변경되었을 때를 알기 위해서 프로퍼티 옵저버를 프로퍼티에 달고 값이 변결될 때마다 Subject에 전송을 보내도록 합니다.

우리는 이제 이렇게 만들어진 모델을 위와 같이 사용할 수 있습니다. 모델을 선언하면서 ObjectBinding으로 지정하면,SwiftUI는 자동으로 Publisher를 구독할 수 있도록합니다. 그리고 선언된 모델을 body 프로퍼티에 두면, SwiftUI는 모델의 값에 변경이 있을 때 새롭게 body를 생성합니다.

 

Design for Composition

이제부터는 예제를 통해서 컴바인을 사용하는 방법에 대해서 설명해드리겠습니다.

마법학교 애플리케이션의 회원가입 화면을 만들어야 한다고 해봅시다. 그리고 이때 몇 가지 요구사항이 발생합니다. 먼저, 우리는 사용자이름이 유효한지 서버를 통해 확인해야합니다. 그리고 비밀번호 필드와 비밀번호 확인 필드의 값이 일치하는지, 비밀번호가 8자 이상인지 확인해야합니다.

 

마지막으로 위 조건들을 확인해서 앱의 UI를 활성화하거나 비활성화할 수 있도록 해야합니다. 따라서, 이 예제에서 우리는 비동기적, 동기적 작업을 모두 통합하여 처리해야합니다. 이제 컴바인이 어떻게 이 작업을 도울 수 있는 지 알아보죠.

먼저 비밀번호에 대한 처리를 하기위해 비밀번호 필드의 값이 바뀌면 이벤트가 발생하도록 target action을 추가해줄 수 있습니다.  필드의 값이 업데이트 될 때마다 text 프로퍼티에 접근해서 값을 가져오고, 해당 값을 두 변수에 각각 저장해줍니다.

 

하지만 우리는 이 작업을 다른 동기처리 동작과 함께 동작하도록 해야합니다. 어떻게 하면 좋을까요?

아주 간단합니다. Published를 각 프로퍼티에 추가해주면 됩니다.

Publisher는 스위프트 5.1에 추가되어 주어진 프로퍼티에 Publisher를 추가해주는 Property Wrapper입니다.

코드에서 사용하더라도 크게 달라지는 것은 없습니다. 다른 프로퍼티와 마찬가지로 접근할 수 있습니다. Published 로 지정된 프로퍼티는 특별히 이름 앞에 $기호를 붙이면 wrap 된 값에 접근할 수 있습니다.

이렇게 하면 Publisher나 Subscriber에 사용할 수 있는 모든 Operator를 사용할 수 있죠. 이 예제에서는 sink를 사용했는데요, 만약 프로퍼티 password의 값이 변경되면 subscriber는 변경된 값을 전달받게 됩니다.

우리는 두 개의 Publisher를 만들었고 두 publisher 모두 String을 output 타입을 가지고, Never를 failure 타입으로 가집니다.

우리가 하고싶은 것은 하나의 유효한 비밀번호를 방출하는 무언가입니다. 그리고 저희는 이런 동작을 지원하는 Operator를 지원합니다.

CombineLatest라고 하죠.

코드로 봅시다. 이전과 마찬가지로 두 개의 Published 프로퍼티를 가지고, ConbineLatest를 사용해서 두 값 중에 하나에만 변경이 생겨도 신호를 받을 수 있게합니다. 만약 사용자가 비밀번호 필드를 모두 채우고, 비밀번호 확인필드를 입력하면, 비밀번호 필드는 기존값을 계속 사용하고, 비밀번호 확인 필드는 새롭게 변경된 값을 사용하게됩니다.

 

그리고 클로저를 추가해 비즈니스 로직을 채우고, 유효성이 검증되면 비밀번호를 반환하고, 아닐 경우에는 nil을 반환합니다. nil을 통해 유효성 검사가 실패했음을 알리기 위해서입니다.

위로 올라가 타입을 확인해봅시다. 코드에 적혀져 있는 그대로 해석이 됩니다. 우리는 두 개의 Published 된 문자열을 가지고 이들의 가장 마지막 값을 사용해서 Optional 타입의 문자열을 만들어냅니다.  

 

만약 새로운 요구사항이 추가되어서 우리가 지정한 특정한 비밀번호는 사용하지 못하도록 해야한다면 어떻게 할까요?

map을 추가하면 타입이 변경된 것을 알 수 있습니다. CombineLatest로 두 값을 combine 하고 그 결과를 다시 map할 수 있죠. 조금 복잡해졌네요.

 

우리는 여기서는 타입을 중요한 것에 집중하게하고 나머지는 API 영역에 두고싶습니다. 이를 위해 한 가지 Operator를 더 추가합시다.

eraseToAnyPublisher를 사용하면 Ouput 과 Failure 타입은 변하지 않지만 구체젝으로 어떤 일들이 일어나는지는 숨길 수 있습니다.

다음은 요구사항은 사용자가 빠르게 사용자이름을 입력할 때 비동기처리로 서버에서 유효성검사를 하도록 해야합니다.

비밀번호를 만들었을 때와 마찬가지로 이번에도 Published 프로퍼티를 만들 수 있습니다. 하지만 이번에는 조금 다른 동작이 요구됩니다. 필드에 변경이 생길 때마다 서버에 계속해서 요청을 보내는 것을 원하지 않기 때문입니다.

이를 위해서 debounce를 제공합니다. debounce는 특정한 윈도우를 만들고, 윈도우보다 더 빠르게는 값을 값을 받지 않도록 할 수 있습니다. 더 자세히 알아봅시다.

우리는 Publisher로 텍스트필드를 가지고 있고, 중간에 debounce를 두었습니다. 사용자가 빠르게 타이핑을 할 때마다 새로운 값이 debounce로 전달되지만, debounce는 자신의 윈도우에 맞게 속도를 줄여서 값을 subscriber에게 전달합니다.

debounce 만으로도 좋지만, 더 좋은 구조를 만들 수도 있습니다. 만약 사용자가 입력한 값이 같다면, 서버로 새로운 요청을 보낼 필요가 없습니다. 에를 들어 사용자가 Merlin을 입력해서 Merlin을 받았다가, n을 지우고 다시 입력해서 Merlin을 다시 받았다면, 서버에 유효성 검사를 다시 요청할 필요가 없는 것이죠. 

 

이를 위해서 removeDuplicates를 제공합니다. removeDuplicates operator를 사용하면 같은 debounce 윈도우 내에서 한번 발행된 값은 다시 발행되지 않도록 할 수 있습니다.

코드로는 이렇게 작성할 수 있습니다. 0.5초 동안의 윈도우를 만들고, 이 시간동안 도착하는 중복을 모두 제거한 뒤에 서버에 요청을 보내는 코드입니다. 이 코드는 서버처리를 더 부드럽게 만들 수 있지만 아직 비동기 처리에 대한 코드는 작성되지 않았습니다.

우리는 이미 작성되어있던 usernameAvailable 함수가 서버 작업이 완료되면 결과를 발행하도록 하고싶습니다.

앞서서 배웠던 flatMap을 사용하면 스트림의 값을 받아 새로운 Publisher를 만들 수 있었습니다. 그럼 여기서 함수를 어떻게 호출해야할까요?

우리는 Future를 사용할 수 있습니다. 그리고 promise를 받는 클로저를 정의합니다. promise는 작업의 성공, 혹은 실패를 결과로 받는 또 다른 클로저입니다.

 

그럼 이제 usernameAvailable을 호출해봅시다.

우리는 스트림에 값이 들어왔을 때 함수를 호출하고, 함수가 완료되면 promise에 해당 값을 채워서 실행합니다.

 

이 과정을 다시 정리해보면,

이렇게 정리할 수 있고, 그 결과로

비밀번호와 동일한 타입을 가지는 새로운 Publisher를 만들어낼 수 있었습니다.

 

이제 마지막 작업이 남았습니다.

우리에게는 두 개의 Publisher가 있고, 이를 다시 조합해서 UI를 활성화할지, 비활성화할지 결정해야합니다.

Publisher들을 조합하는 것은 지금까지와 동일합니다. CombineLatest로 값이 업데이트 될 때마다 사용자 이름과, 비밀번호를 검사하고 이름과 비밀번호를 튜플로 만들어 반환하는 또 다른 Publisher를 만듭니다.

 

UI를 업데이트하는 코드를 만드는 것은 더 간단합니다.

버튼을 하나 만들고, 버튼의 subscription 생명주기를 관리할 수 있도록 AnyCacellable 프로퍼티를 하나 생성합니다. 그리고 우리가 만들었던 Publisher를 구독하면서 새로운 값을 map으로 Bool 타입으로 변경한 뒤에 버튼의 isEnabled 속성을 변경한 값으로 업데이트합니다.

 

오늘 우리는 간단한 세 개의 작은 Publisher에서 시작했습니다. 그리고 이 Publisher들을 조합해서 우리가 원하는 작업을 수행하도록 만들었습니다.

짠!

 

이렇게해서 2019 WWDC 컴바인 세션에 대한 공부가 끝났습니다! 아직도 어렵고 실제로 사용할 때 고민이 많이 되는 컴바인이지만 능숙하게 사용할 수 있게 되었으면 좋겠네요ㅠ 

 

오늘도 읽어주셔서 감사합니다!