Core timekeeping facilities. Since I am developing a Poker Timer (where an alarm, rings every 10/15 minutes or so) I wanted to highlight some important things that need to be accounted for in these APIs in order to use them with PokerTimer.
from SystemClock Javadocs:
Three different clocks are available, and they should not be confused:
System.currentTimeMillis()is the standard "wall" clock (time and date) expressing milliseconds since the epoch. The wall clock can be set by the user or the phone network (see
setCurrentTimeMillis(long)), so the time may jump backwards or forwards unpredictably. This clock should only be used when correspondence with real-world dates and times is important, such as in a calendar or alarm clock application. Interval or elapsed time measurements should use a different clock. If you are using System.currentTimeMillis(), consider listening to the
Intentbroadcasts to find out when the time changes.
uptimeMillis()is counted in milliseconds since the system was booted. This clock stops when the system enters deep sleep (CPU off, display dark, device waiting for external input), but is not affected by clock scaling, idle, or other power saving mechanisms. This is the basis for most interval timing such as
System.nanoTime(). This clock is guaranteed to be monotonic, and is the recommended basis for the general purpose interval timing of user interface events, performance measurements, and anything else that does not need to measure elapsed time during device sleep. Most methods that accept a timestamp value expect the
elapsedRealtime()is counted in milliseconds since the system was booted, including deep sleep. This clock should be used when measuring time intervals that may span periods of system sleep.
- Standard functions like
Object.wait(millis)are always available. These functions use the
uptimeMillis()clock; if the device enters sleep, the remainder of the time will be postponed until the device wakes up. These synchronous functions may be interrupted with
Thread.interrupt(), and you must handle
SystemClock.sleep(millis)is a utility function very similar to
Thread.sleep(millis), but it ignores
InterruptedException. Use this function for delays if you do not use
Thread.interrupt(), as it will preserve the interrupted state of the thread.
Handlerclass can schedule asynchronous callbacks at an absolute or relative time. Handler objects also use the
uptimeMillis()clock, and require an
event loop(normally present in any GUI application).
AlarmManagercan trigger one-time or recurring events which occur even when the device is in deep sleep or your application is not running. Events may be scheduled with your choice of
The Poker timer I'm writing will have to use the AlarmManager and elapsedRealtime to account for the device being run over long periods... the only caveat here is that I need a mechanism for pausing, so the alarmmanager needs to be able to dynamically change it's schedule if the user pauses the timer.