coroutine을 알기위해선 asynchronous process의 역사를 간략이 알아야할 필요가 있다. async process, 즉 비동기 처리는 예전부터 필요한 경우들이 있다. 예를 들어 네트워킹, DB 작업등은 응답에 시간이 걸리기 때문에, 메인쓰레드에서 처리하게되면 그동안 프로그램이 멈추게된다. 그래서 쓰레드를 이용한 처리방식이 일반적이다. 문제는 쓰레드라는 놈이 다루기 너무 까다롭다는데 있다. 일단, 별도의 context를 갖기 때문에, 쓰레드를 생성하는 일은 부하가 크게 걸리는…
[태그:] kotlin
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()를 이용하여…
DeskClock 코드분석 #1 : 의 Timer expired시 구현 분석
타이머를 만들다가, 안드로이드의 오픈소스 앱인 DeskClock 소스를 좀 살펴봤다. 타이머 동작시, AlarmManager에 완료시간을 등록한다. 시간 변경시, AlarmManager에 등록한 알람을 업데이트 시킨다. TimerService가 시작되면, onStartCommand()에서 다음과같이 expireTimer()를 불러준다. TimerModel의 expreTimer()가 호출되고 실행중인 서비스가 저장된게 없다면, 넘겨받은 서비스를 실행중 서비스로 설정한다. 그리고 updateTimer()를 불러준다. updateTimer()를 보면, 타이머가 expired됐을 때, updateHeadsUpNotification()을 불러준다. updateHeadsUpNotification()에서는 서비스의 유무와 expired된 타이머의 유무를…