[iOS] RxSwift

RxSwift, 여러 기술 스택에 많이 등장하는 키워드였는데 기본에 집중하기 위해(?) 아직 거들떠보지 않았던 녀석. 최근에 개발하던 중 RxSwift 키워드가 다시 등장했다. 도대체 뭐길래 이렇게 많이 나오는거야? 강의를 결제했고, 이 부분을 먼저 정리하려 한다.

---

비동기적으로 동작하는 Apple API들과 수시로 상태가 변하는 환경에서 보다 직관적이고 효율적인 코드를 작성할 수 있다.

• Binding
• retry
• Delegate (전체 로직을 다 따져볼 필요 없도록 직관적으로 ~ 변경 가능)

Apple의 비동기 API들

• KVO
• Notification Center
• The delegate pattern
• Grand Central Dispatch (GCD)
• Closures

 

개발자가 추적하기 거의 불가능함.

-> Rx는 이러한 이슈들을 추적 가능하게 함.

 

Benefits

 

• Composable
• Reusable
• Declarative
• Understandable and concise
• Stable (단방향 데이터 흐름을 가지기 때문에 안정적이다?)ㅇ
• Less stateful
• Without leaks

 

우리가 작성하는 대부분의 코드들은

외부 이벤트에 대한 응답과 관련된 코드들

 

ex)

사용자가 control을 조작할 때 응답할 IBAction Handler 작성

Keyboard 위치 변경을 감지하기 위해 Notification 을 관찰

URLSession이 데이터를 응답할 때 실행할 Closure를 제공

KVO를 사용해서 변수의 변경 사항을 감지

 

복잡함.

 

모든 호출-응답 코드를 처리하는 일관된 시스템이 있으면 어떨까?

-> Rx의 시작

 

Rx의 기본 개념으로 Observable에 대해 알아보자.

Swift에서 제공하는 Sequence와 동일하다. (Array처럼 개별적인 요소들을 하나씩 순회할 수 있는 타입)

 

RxSwift의 구성요소

• Observable (다양한 방법으로 생성해보고 다양한 타입을 알아보자)
• Operator (Observable의 이벤트를 입력받아서 결과로 출력할 수 있도록 하는 연산자)
• Scheduler (우리가 직접적으로 Scheduler를 생성하거나 커스텀할 일은 거의 없다. Rx의 Dispatch Queue라고 생각하면 됨.)

Observable

Observable <T>

- next

- error

- completed

 

+ Observer (관찰자, Observable을 수신할 수 있는)

 

1. Observable

Observer 만 있으면, Delegate 패턴이나 서로 다른 Class 간 통신을 위한 Closure 를 사용할 필요가 없음.

 

2. Operator

ex) filter, map

 

3. Scheduler

 

 

 

---

Observable 생명주기

여기에 녹아있는 개념인 Swift - Closure는 이 글을 참고하시라.