먹고 기도하고 코딩하라

작업할 때 옵저버블을 관찰하는 스케줄러를 다른 스케줄러로 돌릴 때가 있다. .subscribe의 onNext에서 UI 변경 작업을 해줘야 할 때 메인으로 바꿔준다든가 할 때는 거의 .observe(on:)을 사용하곤 했다. .subscribe(on:)과 확실한 차이점은 어떤 것이 있어서 .observe(on:)을 썼을까 하면, 명쾌하게 이야기하기 힘들었다. 자주 쓰는 것이 아니면 잊어버리다 보니 이번 기회에 정리하고자 한다. 빠른 정리 1. .subscribe(on:) : Observable이 생성되는 스케줄러 변경 2. .observe(on:) : Observable을 구독하는, ObserverType의 스케줄러 변경 .subscribe(on:) - 생성 스케줄러 변경 .subscribe(on:)은 O..

지난달에 ReactorKit 사내 세미나를 열었다. ReactorKit에 대해 간단히 설명하고, 프로젝트 일부 코드를 ReactorKit으로 부분적으로 전환했을 때 얻을 수 있는 장점 등을 설명한 다음, 회사 코드 일부를 ReactorKit으로 바꿔서 시연했다. 세미나가 끝나고 2가지 질문이 나왔다: mutate에서 통신 값으로 Observable을 return하게 하려면 기존에 쓰던 클로저 방식으로는 안 되는 건가? 즉, Observable을 반환하는 새로운 통신 함수를 작성하는 게 필수인가? 클로저로 값을 넘겨주는 건 안 되는 건가? 통신 중에 Reactor와 연동된 View가 사라지면 통신 옵저버블은 어떻게 되는가? 메모리 릭의 원인이 될 수 있지 않은가? 첫 번째는 일단 클로저 방식으로는 하기 어..

결론부터 얘기하면 있다. ReactorKit의 Reactor 파일을 살펴보면 extension에서 disposeBag을 찾을 수 있다. extension Reactor { fileprivate var disposeBag: DisposeBag { return MapTables.disposeBag.value(forKey: self, default: DisposeBag()) } } 하지만 fileprivate 레벨로 선언된 변수이기 때문에 커스텀해서 만드는 Reactor 내에서 직접 접근할 수는 없다. disposeBag의 존재 의의가 궁금해진다. 기원을 찾아 올라가기 위해 MapTables.disposeBag으로 이동한다. MapTables는 enum 타입이고, disposeBag 변수가 포함되어 있다. p..

Observable 구독하는 클로저에서 이벤트가 발생하면 UI를 업데이트해주는 코드가 있었다. 그런데 observe를 메인 스레드가 아니라 다른 스레드에서 하고 있어서 이벤트를 받아 onNext 하면 메인 스레드가 아닌 데서 UI 조작한다고 앱이 강제종료되는 이슈가 생겼다. .observe(on: MainScheduler.Instance)를 체이닝에 추가해서 메인 스레드에서 관찰하도록 변경해줌으로써 이슈는 해결했다. 그런데 문득 궁금해졌다. 그러니까, onNext에서 할 행동을 DispatchQueue.main.async { } 블록으로 감싸줘도 되는 게 아닌가? 이 둘은 퍼포먼스상으로 유의미한 차이가 있을까? 먼저 .observe(on: MainScheduler.Instance) 메소드부터 살펴보자. ..

MVC가 Massive View Controller라는 농담이 있다. 코코아 MVC에서는 뷰컨이 뷰의 역할도 하고 컨트롤러의 역할도 하기 때문에 뷰컨이 하는 일이 너무 많아지기 때문이다. 전통적인 MVC에서 모델, 뷰, 컨트롤러 3가지는 다음과 같은 일을 한다. Model : 비즈니스 로직 수행에 필요한 데이터 구조를 정의하고 담는 역할 View : 유저에게 보일 뷰를 구성하고, 사용자 인풋을 받고 컨트롤러가 주는대로 아웃풋을 그리는 역할 Controller : 뷰와 모델의 중간 다리 역할로, 뷰에서 일어나는 사용자 인풋은 컨트롤러에 전달. 컨트롤러는 인풋으로부터 모델에 반영하고, 모델 변화에 따른 아웃풋을 뷰를 업데이트하는 역할. MVVM은 뷰컨이 뷰의 역할만 할 수 있도록 하고, 뷰모델이 MVC에서 ..

Observable을 생성할 수 있는 오퍼레이터들은 다음과 같은 것들이 있다. subscribe는 문서 하단에서 설명하겠다. Observable 생성 오퍼레이터 just(_ element: T) -> Observable 1개의 요소만 갖고 방출하는 Observable 시퀀스를 만들어 반환한다. 엄밀히 말하면 1개의 아이템을 그 아이템을 방출하는 Observable로 변환하는 오퍼레이터다. From과 비슷하지만, From은 배열이나 순회 가능한 요소들을 받아서 순회해서 방출하지만, just의 경우 배열을 받아도 배열 자체를 방출한다. just에 1개 이상의 요소를 매개변수로 줄 수 없다. 이 경우 컴파일 에러가 난다. Observable .just(1) .subscribe(onNext: { print($0..

Rx는 무엇인가? ReactiveX 공식 사이트에 가보면, Rx는 관찰 가능한 스트림과 비동기 프로그래밍을 위한 API(An API for asynchronous programming with observable streams)라고 적혀 있다. Rx는 Observer 패턴을 더욱 확장해서, 데이터나 이벤트 시퀀스를 지원하며 개발자들이 프로그램에 갖는 로우레벨 스레딩, 동기화, 스레드 세이프(Thread-safety), 동시 데이터 구조나 논블로킹 I/O 등에 대한 걱정을 없애고 Observable을 조정할 수 있는 연산자를 지원한다. Rx는 Observer, Iterator 패턴, 그리고 함수형 프로그래밍의 좋은 부분만을 합한 것과 같다고 한다. 이벤트 스트림이나 데이터 스트림을 생성하고(Create),..