[iOS-WWDC2019] Combine 사용하기 (1) - Publisher

Combine in Practice 

오늘은 WWDC에서 발표된 컴바인에 대해 번역하며 공부해보겠습니다! 오역이나 의역이 있을 수 있으니 더 자세하고 명확한 내용은 아래 세션에서 확인해보세요...! 그럼 시작합니다~!

Combine in Practice - WWDC19 - Videos - Apple Developer

 

컴바인이 뭔데?

우리의 코드에서 우리는 자주 어떤 이벤트나 값을 발행하는 Publisher와 이 발행된 값이나 이벤트를 받는 Subscriber의 구조를 만나게됩니다.

그리고 어떤 다른 영역의 코드가 이 둘을 연결하기도 합니다. 서로 연결이 된 이후에는 Subscriber가 값을 받고싶다는 요청을 Publisher에게 전달하고, Publisher는 데이터를 흘려보내게 됩니다. 이 과정은 계속해서 반복되고 Publisher가 어떤 종류의 실패가 발생하거나 작업이 모두 끝나 더 이상 값을 발행하지 않을 때까지 지속됩니다. 

 

이런 종류의 통신은 이미 많은 곳에 적용되고 있는데요, 콜백, 클로저와 같이 비동기 통신이 필요한 경우에 사용됩니다. 그리고 이 통신 패턴이 컴바인이 하고자 하는 것과 같습니다.

 

컴바인을 사용하면 우리는 시간에 흐름과 함께 값을 처리할 수 있는 통합된 API를 사용할 수 있습니다. 그럼 값의 Publisher가 된다는 것이 무엇을 의미하는지 살펴보도록 하겠습니다. 

 

컴바인을 사용해보자

컴바인에서 값을 발행하는 Publisher는 Publisher 프로토콜을 채택합니다. 이 프로토콜에는 두 가지 associatedtype이 있는데요, Output은 Publisher가 발행하고자 하는 값의 종류를 의미하고, Failure는 이 Publisher의 실패여부를 나타냅니다. Publisher 프로토콜은 어떻게 Subscriber를 등록하는지에 대해서도 설명하고 있는데요, Subscriber는 반드시 Publisher의 Ouput과 동일한 타입의 Input을 가져야하고, 동일한 타입의 Failure를 가지고 있어야합니다. 

 

여기 엄청나게 멋진 마법사가 있습니다! 이 마법사는 애플리케이션을 원하는데요, 자신이 설립할 새로운 마법사 학교에서 사용할 앱이죠. 이 앱에 들어갈 기능 중 하나는 다른 마법사들에 의해 공유된 멋진 마법기술들을 앱을 통해 다운받을 수 있도록 하는 것입니다. 이 마법사는 앱 개발자가 아니기 때문에 개발자인 저에게 이렇게 생긴 UI스케치를 주었죠.

 

이 앱을 만들기 위해서 우리는 컴바인을 사용해서 Trick Name 레이블의 이름을 새로 다운받은 마법기술의 이름으로 바꾸기로 했습니다.

 

컴바인을 사용하면, NotificationCenter는 특정한 Notification을 위한 Publisher로 등록할 수 있도록 지원합니다. 그래서 위처럼 NotificationCenter를 통해 Publisher를 생성하였습니다. 이 publisher 함수는 Publisher를 반환합니다. 하지만 컴바인에서 정말로 중요한건 Publisher의 ouput과 failure 타입이죠.

 

이렇게 반환된 Publisher는 output으로 Notification을 가지고,failure로 Never를 가집니다. 자, 이제 우리는 Notification을 발행하는 Publisher를 만들었습니다. 하지만 우리가 지금 원하는 것은 다운로드한 마법 기술에 대한 데이터입니다.

 

고맙게도 이 데이터는 딕셔너리 형태로 들어있습니다. 컴바인은 notification을 우리가 원하는 형태로 변환할 수 있는 유용한 map 함수를 지원합니다! Sequence에 들어있는 map과 아주 유사하죠. 이제 우리의 Publisher는 변환된 Data 타입을 output으로 가지고 여전히 failure는 Never로 가지게됩니다.

 

마법사 친구가 한 가지 정보를 더 알려주었는데요, data의 값을 JSON 형태라고 합니다. 그래서 우리는 데이터 디코딩을 시도할 수 있게 컴바인의 새로운 Operator를 사용할 수 있습니다. 이 Operator는 tryMap 입니다. 일반적인 map과 비슷하지만 Error가 발생했을 때 스트림에 failure를 보낼 수 있는 기능이 있습니다.

 

Publisher의 타입이 다시 또 바뀌었네요! 이제 디코딩된 마법기술의 대한 데이터와 Error가 담긴 Publisher가 되었습니다. 그런데 어떤 데이터를 디코딩하는건 자주 일어나는 일이죠? 그래서 저희는 이 작업을 쉽게 할 수 있는 decode Operator를 제공합니다!

 

간단하죠? (이 구간에서 사람들이 막 박수를 치는데 얼마나 디코딩을 다들 귀찮아했는지 이해가 되네요ㅜㅜ)

 

Error Handling

이제 우리의 Publisher는 Error를 failure로 가지게 되었습니다. 그래서 Error에 대한 이야기를 더 해보겠습니다. 

 

컴바인에서는 잠재적인 Failure에 대해 적절히 대응하는 것이 매우 중요합니다. Publisher와 Subscriber는 모두 자신이 발생시킬 수 있는, 자신이 받아들일 수 있는 Failure에 대해 정의할 수 있습니다. 이렇게 구성한 이유는 스위프트와 마찬가지로 컨벤션을 통해 에러들을 처리하도록 하고싶지 않았기 때문입니다. 많은 타입들이 Failure를 Never로 가집니다. 스트림에 들어가기 전에 에러를 모두 처리하기 위해서이죠. 하지만, 그 외의 경우에는 저희가 에러에 대응하고 다시 회복할 수 있는 다양한 Operator들을 지원합니다.

 

가장 단순한 Operator는 Failure가 절대 발생하지 않도록 Assert하는 것입니다. 이렇게 하면 이제 Publisher의 Failure 타입은 Never가 되죠. 왜 그럴까요?

 

이렇게 Publisher와 Subscriber가 있고 중간에 assertNoFailure가 있다고 가정해봅시다. assertNoFailure는 정상적인 데이터가 스트림에 들어오면 subscriber에게 그대로 전달합니다. 하지만 만약 Failure가 전달되면 어떨까요?

 

우리의 프로그램은 트랩을 발생시킵니다. 그리고 트랩이 발생하는 것은 고객이 원하는 앱의 동작이 아니죠. 

 

다행히도 컴바인과 Failure에 사용할 수 있는 다양한 Operator들이 존재합니다. 이중에서도 특히 유용한 Operator는 catch 입니다! catch는 여러분들에게 Recovery Publisher를 정의하는 클로저를 받아 기존 Publisher에서 Failure가 발생했을 때 사용하도록 할 수 있습니다. 어떻게 catch가 동작하는지 살펴보겠습니다.

 

assertNoFailure와 비슷한 상황에서 assertNoFailure만 catch로 변경해보았습니다. Publisher에서 정상적인 데이터가 내려오면 이를 그대로 subscriber에게 전달합니다.

 

하지만 만약 Failure가 내려오면, 기존에 연결되어 있던 Publisher와의 연결이 종료됩니다.

 

그리고 준비된 Recovery Publisher를 연결한 뒤에, 새로운 Publisher에서 발행하는 값을 Subscriber에게 전달합니다. catch를 코드에서 사용해보면 이렇게 사용할 수 있습니다.

 

다른 Operator들과 비슷하지만, 클로저를 정의해야한다는 것이 조금 다르죠. 컴바인은 발행할 값이 이미 정해져있는 특별한 Publisher를 제공하는데요, 우리는 이것을 Just 라고 부릅니다. 이렇게 하면 Publisher는 절대로 실패하지 않게됩니다.

 

그럼 지금까지 작성한 컴바인의 흐름을 정리해볼까요? 먼저 우리는 Notifcation을 발행하는 Publisher를 생성했습니다. 그리고 map을 통해 Notification에 들어있는 Data를 꺼내서 output으로 만들었죠. 그 이후에는 decode를 사용해서 데이터를 디코딩했고, 마지막으로 catch를 이용해서 발생할 수 있는 Failure에 대한 대책도 만들었습니다. 

 

 

그런데 뭔가 이상하지 않나요? catch가 Failure를 받으면 Upstream에 연결되어 있던 기존 Publisher와의 연결을 종료시켜버립니다. 새로운 대체 Publisher를 연결하기 위해서요. 하지만 우리가 원하는 것은 failure가 발생했을 때만 placeholder로 값을 채우고, 나머지 경우에는 계속해서 기존 Publisher로 부터 마법기술의 정보를 받아오는 것입니다. 

 

똑똑이 애플은 역시 이런 상황을 위한 Operator도 준비해두었습니다. FlatMap입니다. FlatMap은 이름처럼 Map과 비슷하게 동작합니다. FlatMap은 내부에 Publisher를 생성해서 데이터를 subscriber에게 전달합니다. 자세한 동작을 알아보죠.

 

Publisher에서 발행한 데이터가 flatMap에 도착했습니다. flatMap은 새 Publisher인 Just를 만들고 디코딩, catch과정을 진행합니다. 그리고 문제가 없다면 결과를 Subscriber에게 전달합니다.

 

그럼 이번엔 같은 상황에서 decode 과정에서 에러가 발생했다고 해보겠습니다. 이때 catch는 자신이 가지고 있던 Recovery Publisher를 통해 값을 발행하고, 이 값이 Subscriber에게 전달됩니다. 이렇게하면 flatMap과 기존 Publisher와의 연결은 여전히 남아있기 때문에 catch만을 사용할 때의 문제가 해결됩니다. 

 

코드로 살펴보겠습니다. map operator를 통해 만들었던 Publisher에 flatMap을 적용합니다. 클로저의 인자로 map으로 만든 Publisher의 output이 들어가겠죠. 이 값을 Just에 전달하고 Just는 기존에 정의했던 decode와 catch를 순차적으로 진행합니다. 이렇게 하면 절대로 Fail 하지 않는, Never를 Failure로 안전하게 가질 수 있겠죠!

 

컴바인을 사용한 앱을 계속 만들어봅시다!

이제 오류 상황에 대한 처리는 끝났으니, 계속해서 마법기술을 다운로드받는 앱을 만들어봅시다. 이제 Publisher(for) Operator를 사용해서 마법기술의 이름을 발행할 수 있습니다. 

 

Scheduled Operators

이 시점에서 특별한 종류의 Operator인 Scheduler Operator에 대한 이야기를 해보겠습니다. 현실세계에서 스케줄링을 하는 것처럼 언제, 어디서 특정한 이벤트가 발생하는지 결정할 수 있습니다. 이 Operator들은 RunLoop와 DispatchQueue에 의해 지원됩니다. 

 

Scheduler Operator들을 사요하면 delay처럼 어떤 이벤트를 미래의 어떤 시점까지 전달하는 것을 지연시킬 수 있기도 하고, throttle 처럼 이벤트의 전달을 일정한 속도 이상으로 하지 않도록 만들 수도 있습니다. 또한 receive 같은 Operator를 통해서 downstream 이벤트가 특정한 스레드나 큐로 전달되도록 지정할 수도 있습니다.

 

우리는 receive operator를 사용해서 우리가 얻은 마법기술의 이름이 항상 메인 큐로 전달되도록 지정하겠습니다.

 

이제 우리의 Publisher chain이 완성되었습니다! 아까에 이어 publisher for를 통해 데이터의 특정한 키에 대한 값을 가져오고, 그 값을 메인 큐에 전달해서 UI의 업데이트가 가능하도록 할 수 있습니다.

 

이렇게 Publisher를 만들 수 있는 유용한 Operator들에 대해 알아보고 chaining을 통해 원하는 데이터를 원하는 스레드로 보내는 작업까지 정리해보았습니다. 이제 절반 정도 왔는데, 여기서 일단 마무리하고 다음 포스트에서 Subscriber 편으로 나머지 내용들을 정리하겠습니다~!