[1교시] 개념잡기 - RxSwift를 사용한 비동기 프로그래밍

• 기존의 비동기적 처리에 있어서 func을 함수를 value 처럼 변수에 담아 파라미터로 받아 핸들러로 사용
• @esacaping은 전달된 함수가 본체의 스코프가 종료된 후에 사용되는 경우로 파라미터를 optional로 전달 시 default가 @esacaping
• 함수는 행동을 저장하고 이러한 행동은 나중에 사용이 가능 - 함수형 프로그래밍 기반
• 해당 개념을 제네릭과 엮어서 만든 것이 RxSwift
• 개인적으로 Generator의 개념도 섞인게 아닐까 싶음(iterator.next())
• Observable이 이벤트를 발생시키면 옵저버의 관찰자가 그 순간을 감지하고 하고 '순차적으로 분리 된' 방식으로 처리함으로써 '비동기식' 기능 구현이 가능
• 기존의 비동기 처리 방식: Notification Center, Delegate pattern, Grand Central Dispatch(GCD), Closures + promiseKit, Bolts

1. Observable & Sugar API

• 생성
  • create: AnyObserver 타입의 emitter 방출, next, error, completed의 세 가지 타입의 유형으로 switch 문을 통해 제어
  • 간단한 생성: just, from
• 필터: filter, take
• 변환: map, flatMap, scan
• 결합: combineLatest, merge, zip
• 유틸: do, delay, observeOn, subscribeOn

[2교시] RxSwift 활용하기 - 쓰레드의 활용과 메모리 관리

1. Observable Life-Cycle

Observable은 subscription을 받기 전까진 아무 짓도 하지 않은채 값을 가지고만 있다.
즉, subscription이 Observable이 이벤트들을 방출하도록 해줄 방아쇠 역할을 한다

• Subscribed: Observable 객체를 감시하여 객체의 value의 변화에 따른 Subscribed 메서드 동작
• Next: 구독을 통하여 이벤트를 계속해서 방출받을 수 있는 상태, Element 인스턴스를 가짐
• Completed / Error: 구독이 완료/에러발생으로 종료된 상태, .error 이벤트는 Swift.Error 인스턴스를 가짐
• Disposabled: 구독을 취소하여 Observable을 수동적으로 종료

2. 순환 참조와 메모리 관리

self 값에 대한 참조에 있어서 weak를 이용한 순환 참조 해결
클로저의 캡처 리스트에 있어서 참조 타입(Class)의 레퍼런스 카운트 주의
특히 UI 관련 사이드 이펙트에 있어서 주의
edit scheme - Diagnostics - malloc 설정으로 해당 앱 실행에 있어서 메모리 leak 체크 가능
[weak self] 와 같은 귀찮은 코드를 하지 않더라도, 종료조건이나 시점을 통제함으로써 메모리를 관리할 수 있다.

3. Thread/Scheduler 분기

observeOn(원하는 시점 부터), subscribeOn(구독 시작 부터) 메서드를 사용하여 UX에 있어서 비동기적인 활용을 위한 thread 컨트롤

4. Stream의 병합 및 공유

• 병합
  • combine, merge, zip을 활용하여 Observable 병합
• 공유
  • 1개의 이벤트를 여러 Observer가 구독하여 공유, observing하기 전 과거 elements를 어떻게 다룰지(replay)와 언제 공유할지(refCount)가 필요, replay(1).refCount(), 합쳐서 share(replay: 1)로 사용

[3교시] RxSwift 활용범위 넓히기 - UI 컴포넌트와의 연동

1. Subject

bridge 또는 proxy로 Observable, Observer 두 가지 역할을 모두 할 수 있다
실제로 Observable을 subscribe하며, item을 observer에게 reemitting한다

Data Control

• BehaviorSubject
  • 초기값 사용 가능하며, Observer가 subscribe할 때 가장 최근에 emit했던 item을 emit한다
  • 그 뒤로 계속 item emitting이 일어남
  • source Observable이 error로 없어지면 BehaviorSubject도 item이 아닌 error를 뱉음
• PublishSubject
  • Observer가 subscribe한 이 후의 내보내진 item만 뱉는다
  • 따라서 PubliishSubject의 생성시간과 Observer의 subscribe 생성시간 사이의 item은 다루지 못하는 경우가 발생할 수 있다
• ReplaySubject
  • Observer가 언제 subscribe한지와 관계없이 전에 내보냈던 모든 item을 내보낸다
  • 버퍼의 크기 또는 내보낸 시간에 따라서 오래된 item을 버리는 버전도 있다
• AsyncSubject
  • source Obsevable이 complete된 이후 가장 마지막으로 내보내진 item을 Observer에게 뱉는다

Hot Observable / Cold Observable

Observable이 언제부터 item을 내보내는지에 대한 문제
공유 방식의 차이 존재 - 스트림 분기가 필요한 경우 subject같은 Hot Observable을 사용해 subscription을 공유

• Hot
  • 생성하자마자 item을 내보낼 수 있는 Observable
  • 따라서 나중에 subscribe한 Observer는 Sequence의 중간부터 시작한다
  • Hot의 경우 자원을 공유한다 - Observer들은 하나의 스트림으로 연결되어 있다
• Cold
  • 한 Observer가 subscribe하기 전까지 기다린다
  • Observer는 처음부터 모든 Sequence를 볼 수 있다
  • Cold의 경우 Observer당 자원이 할당된다 - Observer당 각 하나의 스트림이 생겨난다

2. RxCocoa

UI 작업의 특징

데이터로 인한 에러가 발생하는 것을 방지하고 스레드 관리에 있어서 편리함을 주기 위해서 RxCocoa에서 제공하는 특성화된 메서드를 활용

Observable / Driver

Driver는 UI layer에서 좀 더 직관적으로 사용하도록 제공하는 unit
Driver는 항상 MainScheduler에서 사용
asDriver를 통해 구독하는 이벤트에 대해서 UI 특화적으로 구성이 가능
onError가 발생하지 않는다
subscription 공유도 상황에 따라선 가능(share(replay:1, scope: .whileConnected))

Subject / Relay

Relay는 complete, error를 내보내지 않는다
그 이외의 점은 subject와 동일하며 이름을 통해 어떤 subject 처럼 동작하는지 알 수 있다
next 이벤트만 발생시키고, dispose전까지 없어지지 않는다
따라서 Observable보다 Driver가 UI에 적합하듯이 UI에는 Subject보다 Relay가 더 적합하다
next 이벤트를 발생시킬때는 accept를 사용하며, UI에 사용할때는 bind를 사용한다

• PublishRelay
  • PublishSubject의 특성처럼 구독 이후의 발생하는 이벤트들만 알 수 있다
• BehaviorRelay
  • 초기값을 가지고 생성
  • value()를 사용해 현재의 값을 꺼낼 수 있다(읽기 전용)
  • 현재의 값을 변경하기 위해서 .accept()를 사용
• ReplayRelay
  • ReplaySubject 처럼 bufferSize만큼 최신이벤트를 전달한다