안드로이드에서 설정같은 간단한 값들의 저장은 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에서 알아서 읽고 쓰고…
DeskClock 코드분석 #3 : Timer의 저장 및 Sleep, reboot등 처리 그리고 마무리 정리
DeskClock은 실행중에 wakelock을 요청하지 않는다. wakelock을 요청하는 부분은 알람이 울리는 경우에만 꺼지지 않고 알람을 울리도록 요청한다. 알람 매니저를 통해 브로드캐스트 리시버로 “times_up” 인텐트를 접수하면, TimerService를 실행하고 TimerModel.updateTimer()가 불린다. 여기서 doUpdateTimer()를 호출하는데, 여기서 updateRinger() 안에서 wakelock을 요청하고 해제한다. 타이머의 저장은 SharedPreference를 사용한다. 개인 핸드폰에서 사용하는 타이머 개수가 많지 않을거라고 가정한듯하고, 수시로 저장하고 가져오는데 적합하다고 판단한거라 추측한다….
DeskClock 코드분석 #2 : App과 Notificaiton 전환
메인 Activity인 DeskClock 에서 onStart() -onStop() 부분을 보면 isApplicationInForeground로 앱이 현재 포그라운드 상태인지 플래그를 변경해주고 있다. DataModel 의 isApplicationInForegound를 보면, NotificationModel.isApplicationInForeground를 참조하고 있음을 알 수 있다. 그리고 값을 설정하는 경우, TimerModel의 updateNotification()을 불러준다. TimerModel의 updateNotification()을 살펴보면, TimerModel이 가지고 있는 타이머 목록인 mutableTimers에서 실행중이거나 일시정지된 타이머들을 unexpired 리스트에 추가한다. 즉, 현재 동작중인 타이머들을 가지고 NotificationBuilder.build()를 이용하여…