![]() While I didn't directly use any ideas from this source for this problem, I do think that it is going to be my Android go-to information source for the foreseeable future. On an unrelated note, during my investigation I treated myself to a CommonsWare Warescription. Another approach would be to adjust the postDelayed() delay time to take into account the time spent in postDelayed(). I'm hoping that spawning a thread to do the processing will address this issue, allowing postDelayed() to more or less mimic an asynchronous call. The next problem to tackle is with the clock-drift caused by the non-zero execution time associated with postDelayed() processing. Granted, these methods still have uses, but they are overkill when implementing a simple elapsed-time clock or timer. Success! No need to use AlarmManager, PartialWakeLock, or anything else substantially more complicated. All that was required to track time across deep sleep cycles was to replace the use of uptimeMillis() with elapsedRealtime(). But the elapsedRealtime() method does include time spent in "deep sleep" mode. Careful reading of the javadoc reveals that uptimeMillis() doesn't include time spent in "deep sleep", e.g., when the user presses the power button. As stated above, the original implementation used uptimeMillis(). The difference between the 2 is subtle, but important.Īs you might expect, my solution keeps track of elapsed time by accumulating durations between calls to postDelayed() - i.e., elapsed time = elapsedTime + lastClockInterval. It turns out I was using SystemClock.uptimeMillis() when I should have been using SystemClock.elapsedRealtime(). In addition, it's deceptively simple, always a good sign. It doesn't yet address the clock drift associated with the time spent in calculations during the postDelayed() processing, but it is a step forward. I've got a partial solution to my original post above. I'm hoping that this approach will result in a reasonable balance between power conservation, code complexity, and user expectations. The idea is that AlarmManager will help combat clock-drift and PartialWakeLock to help keep the code simple (fingers-crossed). I'm going to try a combination of AlarmManager and PartialWakeLock. Using PartialWakeLock also looks promising, but by itself it doesn't address the clock-drift problem I'm experiencing. AlarmManager seems like a good approach, but I'm concerned that this isn't an appropriate use of AlarmManager (i.e., very short intervals between alarms). Java timers, like services, don't solve the problem with the device going to sleep. Services by themselves won't solve the problem associated with the device going to sleep. The actual numbers are still accurate, but instead of being aligned, for example, on 5 second boundaries which are easily understood by users - the timers involved start to drift, resulting in some understandable user confusion.Īfter a bit of research I found techiques for using services, java timers, AlarmManager, and PartialWakeLock to implement timers. In addition, the postDelayed() approach is experiencing some clock drift, apparently a result of the time spent in the run() method. But I soon learned that it was possible to circumvent this approach by pressing the power button to manually put the device to sleep. ![]() My first attempt at this involved using Handler.postDelayed() to trigger the clock ticks every 200ms and _KEEP_SCREEN_ON to ensure that the "clock" wasn't stopped by a screen timeout. The game clock needs to continue to run even if the user explicitly places the device in sleep mode by pressing the power button. Elapsed time needs to be accurate to the second. I'm writing a sports app that needs to track the elapsed time of quarter/half/period.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |