안드로이드에서 설정같은 간단한 값들의 저장은 DB가 아니라 가볍게 파일로 읽고 쓰는 SharedPreferences를 제공했었다. SharedPreferences는 key-value 쌍으로 값을 읽고 쓴다. 큰 문제없이 써오던 것이지만, 오래되다보니 몇가지 문제가 존재한다. 우선 제대로된 비동기 읽기/쓰기를 제공하지 않는다. 또한, 런타임 exception에 대한 처리도 제공하지 않고, UI Thread를 블럭하여 ANR을 발생 시킬 수도 있다. Kotlin이 도입되고, 더 읽기
안드로이드
안드로이드 개발내용
Android의 시간에 대해
일단, 날짜 년, 월, 일, 요일에 대해선 자세히 다루지 않는다. Date라는게 참 복잡 미묘한 놈이라서. 이 녀석을 제외하면 좀 단순해지는데, 나는 항상 System.currentTimeMillis() 만 이용해왔다. 이건 뭐 다들 알겠지만, 1970년 1월 1일 자정을 기준으로 현재까지 흐른 시간을 milliseconds로 돌려준다. 대부분의 경우 이걸로 해결이 되긴 하는데, 타이머를 만들면서 좀 더 유용한 더 읽기
Application Context를 수시로 참조하고 싶다!
Shared Preference를 사용해 데이터를 읽고 저장하는 Data Model을 만들려고 했더니, Shared Preference를 얻기 위해 Application Context가 필요했다. 보통 context는 필요할 때 매번 값을 인자로 넘겨주는 사용법이 권장된다. 그런데 말이지. 언제든 사용할 수 있게 singleton으로 만들었는데, 만들다보니 lifecycle이 Application과 동일하고 데이터 저장, 읽기를 하는데 굳이 외부에서 context를 매번넘겨줘야 하는건가 생각이 들었다. 더 읽기
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 리스트에 추가한다. 즉, 현재 더 읽기