Reactive Stream규격의 Kotlin 구현. Asynchronouse cold stream. Asynchronouse 하게 동작하는게 코루틴과 찰떡으로 돌아간다. 데이터 스트림이라고 한다면, 한쪽(Producer)에서는 소스 데이터를 계속 넣어주고 이 데이터들이 일련의 파이프라인을 따라 처리된 후, 맞은편(Consumer)에서 데이터를 빼가는 모습을 생각할 수 있다. 주로 파일처리등의 대용량 데이터의 처리에 사용되지만, 이미 안드로이드에서 범용적으로 사용하고 있듯, 비동기적으로 데이터를 처리하는 reactive programming 형태에서는 데이터의 크기와 상관없이…
[태그:] android
Kotlin: Coroutines
coroutine을 알기위해선 asynchronous process의 역사를 간략이 알아야할 필요가 있다. async process, 즉 비동기 처리는 예전부터 필요한 경우들이 있다. 예를 들어 네트워킹, DB 작업등은 응답에 시간이 걸리기 때문에, 메인쓰레드에서 처리하게되면 그동안 프로그램이 멈추게된다. 그래서 쓰레드를 이용한 처리방식이 일반적이다. 문제는 쓰레드라는 놈이 다루기 너무 까다롭다는데 있다. 일단, 별도의 context를 갖기 때문에, 쓰레드를 생성하는 일은 부하가 크게 걸리는…
Android : Preferences DataStore
안드로이드에서 설정같은 간단한 값들의 저장은 DB가 아니라 가볍게 파일로 읽고 쓰는 SharedPreferences를 제공했었다. SharedPreferences는 key-value 쌍으로 값을 읽고 쓴다. 큰 문제없이 써오던 것이지만, 오래되다보니 몇가지 문제가 존재한다. 우선 제대로된 비동기 읽기/쓰기를 제공하지 않는다. 또한, 런타임 exception에 대한 처리도 제공하지 않고, UI Thread를 블럭하여 ANR을 발생 시킬 수도 있다. Kotlin이 도입되고, coroutine, Flow라는 신기술이 일상적으로 쓰이면서…
Android의 시간에 대해
일단, 날짜 년, 월, 일, 요일에 대해선 자세히 다루지 않는다. Date라는게 참 복잡 미묘한 놈이라서. 이 녀석을 제외하면 좀 단순해지는데, 나는 항상 System.currentTimeMillis() 만 이용해왔다. 이건 뭐 다들 알겠지만, 1970년 1월 1일 자정을 기준으로 현재까지 흐른 시간을 milliseconds로 돌려준다. 대부분의 경우 이걸로 해결이 되긴 하는데, 타이머를 만들면서 좀 더 유용한 것들이 있더라. 이에 대해 잘…
Application Context를 수시로 참조하고 싶다!
Shared Preference를 사용해 데이터를 읽고 저장하는 Data Model을 만들려고 했더니, Shared Preference를 얻기 위해 Application Context가 필요했다. 보통 context는 필요할 때 매번 값을 인자로 넘겨주는 사용법이 권장된다. 그런데 말이지. 언제든 사용할 수 있게 singleton으로 만들었는데, 만들다보니 lifecycle이 Application과 동일하고 데이터 저장, 읽기를 하는데 굳이 외부에서 context를 매번넘겨줘야 하는건가 생각이 들었다. Data Model에서 알아서 읽고 쓰고…