Heecheol's blog

debug() Rx를 사용하게되면 스트림이 흐르면서 데이터 타입이 많이 바뀜 근데 이때 데이터 연산이 많으면 원했던 형태로 안나올 수도 있고, 이걸 중간에서 체크하기 어려움 Rx를 사용하기 전에는 중간에 print구문을 이용해 현재 데이터를 출력할 수 있었는데, debug도 똑같음 단순하게 print라고 생각하면됨 RxDatasource 아직 직접 적용해보진 않았고 간단하게만 확인해봄 테이블뷰나 컬렉션뷰의 섹션이 한 개가 아닌 경우엔 RxDatasource를 반드시 써야함. 디퍼블 데이터소스랑 구현 방식이 비슷함. lazy var dataSource = RxTableViewSectionedReloadDataSource(configureCell: { dataSource, tableView, indexPat..

Observable과 Subject Subject는 Observable이자 Observer Subject는 스트림 공유 -> 즉, Subscribe할때마다 새로운 시퀀스가 생성되는게 아니라서 리소스 낭비를 줄일 수 있음. Subject에는 Publish, Behavior, Replay, Async가 있는데 다 share()를 내부적으로 갖고있기때문에 따로 추가해주지 않아도됨 subscribe와 bind subscribe는 next, error, complete가 있는데, 무한한 시퀀스에서는 error나 complete를 안씀. -> UI를 핸들링하는 부분은 실패할 일이 거의 없기때문에 error나 complete가 필요없기때문에 bind사용 bind는 UI핸들링에 특화되어있고, 메인스레드에서 동작 bin..

Observable vs Observer 옵저버블 - 이벤트를 emit 옵저버 - 이벤트 처리 옵저버블과 옵저버를 통해 데이터 스트림을 통제할 수 있고, Operator를 통해 조작할 수 있음 근데 옵저버블은 이벤트에 대한 처리를 할 수 없고, 옵저버는 이벤트에 대한 처리만 가능함. -> 그래서 Subject나옴 Subject 위에서 말했듯이 emit과 Subscribe 둘 다 가능. 네 가지 종류가 있음 Publish, Behavior, Replay, Async 근데 UI의 경우는 에러가 날 일이 거의 없음. 그래서 핸들링도 딱히 필요없고, 이벤트에 대한 요소도 대부분 infinite RxSwift로도 충분했지만, UI를 더 잘 관리할 수 있는게 RxCocoa onNext를 전달할 수 있다는 것은, e..

Disposable 리소스를 정리 subscribe중인 Stream을 원하는 시기에 처리할 수 있도록 도와줌 항상 마지막에 dispose가 붙는 것을 알 수 있음 -> Observable은 모두 Disposable을 리턴하기 때문임 -> 이를 통해 Stream을 종료하고 실행되던걸 종료함. Observable의 next 이벤트 emit이 끝나면 disposed로 인해 자동으로 종료(리소스 해제)됨 -> 근데 인터벌의 경우를 생각하면 화면이 dismiss되더라도 disposed되지않음 -> 이때 deinit이 정상적으로 되면 disposed도 정상적으로 동작함 -> 순환참조 신경 잘 쓰기 만약 루트뷰컨트롤러인 경우에는 메모리에서 해제되지 않음 위의 두 경우는 직접 관리를 해줘야함. -> disposed 메..

Collection타입들은 sequence 프로토콜을 채택하고 있음 -> 한 번에 하나씩 단계별로 진행할 수 있는 값 목록 -> 반복문 생각하면될듯 Observable과 Observer 옵저버블은 이벤트를 보내고, 옵저버는 이벤트를 처리한다고 생각 youtube를 예시로 들어보면, 영상을 아무리 많이 올려도 구독하는 사람이 없으면 볼 사람이 없음 처리하는 이벤트가 영상 시청이라고 생각하면 될듯 Infinite Observable Sequences, Finite Observable Sequences 말그대로 무한과 유한 무한은 UI같은거 생각하면될듯. -> 데이터에 따라 UI변경이 일어나는건 계속해서 일어날 수 있음 유한은 파일 다운로드 생각하면됨. -> 1기가 파일을 다운받을때, 한 번에 다운되는게 아니..