안드로이드에서 Flow로 읽어오는 데이터는 UI에 사용될 시, 주로 viewmodel에 저장하는 livedata형태로 변환해서 사용하게 된다. UI 업데이트는 observable한 데이터를 필요로 하기 때문이다. Flow는 cold stream이기 때문에 observable한 형태는 불가능하다. 옵저버 패턴은 다른말로 발행-구독(Publisher-Subscriber) 모델로 말하기도 하는데, 발행하는 쪽이 데이터가 바뀔 때마다 구독자들에게 브로드 캐스팅을 해야하기 때문에, hot stream 형태로 구현되어야 한다. 만약, livedata를 사용하지 않는다면? Flow만으로는…
[카테고리:] 코틀린
Kotlin 관련 메모
Kotlin : Flow Part. 1
Reactive Stream규격의 Kotlin 구현. Asynchronouse cold stream. Asynchronouse 하게 동작하는게 코루틴과 찰떡으로 돌아간다. 데이터 스트림이라고 한다면, 한쪽(Producer)에서는 소스 데이터를 계속 넣어주고 이 데이터들이 일련의 파이프라인을 따라 처리된 후, 맞은편(Consumer)에서 데이터를 빼가는 모습을 생각할 수 있다. 주로 파일처리등의 대용량 데이터의 처리에 사용되지만, 이미 안드로이드에서 범용적으로 사용하고 있듯, 비동기적으로 데이터를 처리하는 reactive programming 형태에서는 데이터의 크기와 상관없이…
Kotlin: Coroutines
coroutine을 알기위해선 asynchronous process의 역사를 간략이 알아야할 필요가 있다. async process, 즉 비동기 처리는 예전부터 필요한 경우들이 있다. 예를 들어 네트워킹, DB 작업등은 응답에 시간이 걸리기 때문에, 메인쓰레드에서 처리하게되면 그동안 프로그램이 멈추게된다. 그래서 쓰레드를 이용한 처리방식이 일반적이다. 문제는 쓰레드라는 놈이 다루기 너무 까다롭다는데 있다. 일단, 별도의 context를 갖기 때문에, 쓰레드를 생성하는 일은 부하가 크게 걸리는…
Android : Preferences DataStore
안드로이드에서 설정같은 간단한 값들의 저장은 DB가 아니라 가볍게 파일로 읽고 쓰는 SharedPreferences를 제공했었다. SharedPreferences는 key-value 쌍으로 값을 읽고 쓴다. 큰 문제없이 써오던 것이지만, 오래되다보니 몇가지 문제가 존재한다. 우선 제대로된 비동기 읽기/쓰기를 제공하지 않는다. 또한, 런타임 exception에 대한 처리도 제공하지 않고, UI Thread를 블럭하여 ANR을 발생 시킬 수도 있다. Kotlin이 도입되고, coroutine, Flow라는 신기술이 일상적으로 쓰이면서…
Application Context를 수시로 참조하고 싶다!
Shared Preference를 사용해 데이터를 읽고 저장하는 Data Model을 만들려고 했더니, Shared Preference를 얻기 위해 Application Context가 필요했다. 보통 context는 필요할 때 매번 값을 인자로 넘겨주는 사용법이 권장된다. 그런데 말이지. 언제든 사용할 수 있게 singleton으로 만들었는데, 만들다보니 lifecycle이 Application과 동일하고 데이터 저장, 읽기를 하는데 굳이 외부에서 context를 매번넘겨줘야 하는건가 생각이 들었다. Data Model에서 알아서 읽고 쓰고…