I've been messing around with the Chronometer class. It's a weird little beast. It only has one direction of timing -- and that's "up". It also continuously updates even when stopped. Stopping just affects the text field updates -- the timer keeps on running in the background. So, if you stop it and then start it, you'll see a jump in displayed time as the thing takes off again.
To get around these idiosyncrasies, I created a derived class that I named ChronoRelative. I gave it the option to count up or down, and stopping the object halts accumulation. It works. Meh, sort of. Running it on the emulator, I've noticed that occasionally it likes to skip over a second. We're talking about once or twice a minute. Ugh. Very annoying.
I think this stems from a couple of issues. The emulator is just that -- an emulator. It's not going to operate as fast (slow?) as the real device. My host machine is a beefy Intel Quad-core Q6600 running close to 3GHz. Still, depending on the emulator, even this may not be fast enough. The other issue might be due to the code that I implemented in my derived class. When the timer changes, it calls OnChronometerTickListener. I use this to insert a check when the chronometer is configured to count down. There are some multiply and (worse) division operations going on as well as some parsing of text fields. All of this could be inducing a time delay to cause the problem.
I tested my derived class in a "count-up" configuration. This has minimal code in the listener method. I still see the problem of skipping a second, but it is not nearly as frequent as when I have it in the "count-down" configuration.
I need to explore a few options first. First and foremost -- can I minimize the amount of calculations that my listener performs. Will this have an effect? Second, and maybe more importantly, how does the code behave on the actual device? If the 'real' device doesn't have any problems, maybe this is a problem that I can just ignore.
Time to attach my HTC Eris...