Thanks to @fimuxd 🖤

참고자료
https://github.com/ReactiveX/RxSwift
https://github.com/fimuxd/RxSwift
iOSアプリ設計パターン入門 – https://peaks.cc/books/iOS_architecture

MVVM

구조

View (binding) ViewController (input/output) ViewModel (update/notify) Model

1. Model
– UI와 상관없는 순수한 로직과 데이터.
– View, ViewModel 에 의존하지 않음 (= Model만으로도 빌드 가능)

2. View (ViewController)
– 유저의 조작을 받고, 화면 표시를 담당.
– View는 ViewModel가 갖고있는 상태와 데이터 바인딩을 한다.
– ViewModel이 갖고있는 데이터를 가공, 업데이트해서 바인딩한 View까지 업데이트

– ViewController
– View의 생명주기를 처리하고 UI 구성요소를 바인딩 할 때만, ViewModel, View와 통신한다.

3. ViewModel
– View와 Model 사이의 화면 표시를 위한 매개체.
– View에 표시하는 데이터를 갖는다.
– View에서 이벤트를 받고 Model의 처리를 실행.
– View에서 이벤트를 받아 처리하고 값을 업데이트.
– 화면표시를 위한 로직를 함께 담당하는 것이 ViewModel
– MVP의 Presenter와 비슷하지만, Presenter는 View의 참조를 유지하지만 MVVM의 ViewModel은 데이터 바인딩에 의해 상태를 업데이트하기 때문에 View의 참조가 필요하지 않다.

실제 예제 연습

1. iOS 설계 패턴 예제
🔗

2. https://github.com/fimuxd/RxSwift, Lecture 23 예제를 조금 변경
Twitter 대신 Starwars 인물 API로 변경.
UITableView, MVVM, CustomCell 구현은 동일.
🔗

1) 해결했지만 고민되었던 부분 🤔
– refreshControl의 Handling : .endRefreshing 을 실행시키는 타이밍
– UITableView : delegate, dataSource, customCell / 를 어떻게해야하나 !
–  peoples과 reload 의 binding : 어느걸 기준으로 바인딩을 할 것인가
– URLSession 관련 : request 결과물을 Observable로 return시키는게 나은가? 아니면 그냥 배열으로? Rx의존도의 문제.

2) 과제
– VC의 binding이 끝나자마자 별도의 유저 동작 없이 바로 request하기 위해서는 어떻게해야 RxSwift스러운 코드가 될까.

3) 머릿속 정리가 완벽하지 않은 부분
– Observable과 Observer
– Observable<타입>.create ~~~~ 이 부분을 쓰는게 어렵다 ㅠㅡㅠ
– Disposable
– Subject VS Observable
– bind VS subscribe : error, next, complete 를 섬세하게 핸들링할 것인가?
– Drive : UI 중심으로 사용하는 듯?
– MainThread 대신에 MainScheduler 사용하기. 갈아타는 것도!

다시 한 번 짚고 넘어가기

1. Observable과 Observer
– Observer = 관찰자. Observable = 관찰자를 가져 event를 구독.
– Observer가 발행시킨 이벤트들을 Observable이 구독(subscribe)
– Observable이 이벤트를 배출하면 Observer가 반응.



2. Subject VS Observable
– Subject = Observable + Observer
– 하나의 Observer를 여러 곳에서 구독했을 때 차이가 포인트 !
– Subject : 여러 곳에서 구독해도 Observer의 이벤트 값이 동일. (多구독자 : 단일Observer)
– ObserverType 이기 때문에 (Observer의 특성) on 메소드를 사용할 수 있다.
– Observable : 각각의 구독에 대한 Observer가 존재. (단일구독자 : 단일Observer)



3. Observable<타입>.create ~~~~ 이 부분을 쓰는게 어렵다 ㅠㅡㅠ

public static func create(_ subscribe: @escaping (AnyObserver<Element>) -> Disposable) -> Observable<Element> {
    return AnonymousObservable(subscribe)
}

– subscribe
– @escaping (AnyObserver) -> Disposable
– event를 발생시키는 Obsever가 주어지고 Disposable을 리턴시켜야하는 클로저.

/// Represents a disposable resource.
public protocol Disposable {
    /// Dispose resource.
    func dispose()
}

– Disposable
– Disposables : Disposable 을 생성.
– Disposable 은 .dispose 를 가지고 있다. 즉, Observable 을 메모리에서 해제시키고 해제할 수 있도록 해준다.
– .dispose : 메모리를 해제시키는 메소드
– DisposeBag에 담기게 된다. DisposeBag이 dealloc되면 같이 delloc 된다.



4. bind VS subscribe : error, next, complete 를 섬세하게 핸들링할 것인가?

    public func bind(to relays: PublishRelay<Element>...) -> Disposable {
        return bind(to: relays)
    }

    public func subscribe(onNext: ((Element) -> Void)? = nil, onError: ((Swift.Error) -> Void)? = nil, onCompleted: (() -> Void)? = nil, onDisposed: (() -> Void)? = nil)
        -> Disposable {
            let disposable: Disposable
            
            if let disposed = onDisposed {
                disposable = Disposables.create(with: disposed)
            }
            else {
                disposable = Disposables.create()
            }
            
            #if DEBUG
                let synchronizationTracker = SynchronizationTracker()
            #endif
            
            let callStack = Hooks.recordCallStackOnError ? Hooks.customCaptureSubscriptionCallstack() : []
            
            let observer = AnonymousObserver<Element> { event in
                
                #if DEBUG
                    synchronizationTracker.register(synchronizationErrorMessage: .default)
                    defer { synchronizationTracker.unregister() }
                #endif
                
                switch event {
                case .next(let value):
                    onNext?(value)
                case .error(let error):
                    if let onError = onError {
                        onError(error)
                    }
                    else {
                        Hooks.defaultErrorHandler(callStack, error)
                    }
                    disposable.dispose()
                case .completed:
                    onCompleted?()
                    disposable.dispose()
                }
            }
            return Disposables.create(
                self.asObservable().subscribe(observer),
                disposable
            )
    }

– .bind : error를 별도로 핸들링 하지 못함.
– .subscribe : onError 에서 핸들링 가능.



5. Drive : UI 중심으로 사용하는 듯?
– RxCocoa 에서 제공됨.
– Driver : UI에서 직관적으로 사용. MainScheduler에서 실행된다.
– Observable 은 MainScheduler 에서의 실행이 보장되지 않는다.
– Observable의 .subscribe는 Driver의 .drive
– .drive에서는 onError가 제공되지 않는다.
– .asDriver : Observable 에서 Driver로 변환



6. MainThread 대신에 MainScheduler 사용하기. 갈아타는 것도!
– UI 중심의 구독의 경우에는 5의 Driver를 활용하는게 중요 !

public func observeOn(_ scheduler: RxSwift.ImmediateSchedulerType) -> RxSwift.Observable<Self.Element>

// 사용 예.

let observable = Observable<Int>.just(1)
observable.observeOn(MainScheduler.instance)

– 위의 코드처럼 MainScheduler 를 지정하는 것도 물론 가능.
– Custom Scheduler도 지정할 수 있고 왔다갔다하는것도 가능하다.
– Scheduler 가 Thread라 생각하면 죠타