views:

841

answers:

3

I am just about finished with my app and beta testing found a bug in the stopwatch portion... The stopwatch uses an nstimer to do the counting and has a table for storing laps, but when the lap table is scrolled the watch stops or pauses and does not make up for the lost time.

This was stalling was eliminated by using:

startingTime = [[NSDate date] timeIntervalSince1970];

to calculate the elapsed time.

but I am still using the NSTimer to trigger every 0.1 secs and that means that the scrolling still stalls the timer even though the elapsed time will be updated correctly in the end... and comparing this to the Apple stopwatch it makes me wonder if that stopwatch has a separate thread just for the elapsed time counting. Does anyone know if that is how it is done?

Now, using the time since the Epoch is working well in one sense, but it complicates the matter of starting, stopping, & restarting the stopwatch

when the watch is stopped the time is stored and used to calculate an offset for when the watch is restarted, but there seems to be some latency introduced and the time jumps ahead visibly when the watch is restarted.

Any thoughts toward the root cause or a solution would be greatly appreciated.

+9  A: 

If the event loop isn't running, any timers will not fire until the event loop can run again. Even if the event loop isn't block, the timer isn't guaranteed to fire at exactly its configured interval. If your timings were based entirely on timers firing, the amount of error will grow over time.

You need to keep track of the duration separately from the firing of the timers. Each time a timer fires, recalculate your duration and redisplay.

For a start/pause/restart/stop type of setup, you generally want to:

  • grab the time upon start (either as an NSDate instance or as an NSTimeInterval value)

  • upon pause or stop, grab the time upon pause/stop. Subtract the start time from this time and you have the interval's duration

  • upon restart, grab the time upon restart but also keep around the already elapsed duration

  • upon pause/stop, grab the time at pause/stop and add the already elapsed duration

In general, doing all of this with NSTimeInterval values -- which are just doubles -- is easiest. However, if you need to keep track of the actual moment in time when the events happened, use NSDate instances instead.

bbum
+7  A: 

bbum's answer provides a better way to design your application, but if you want your timer to fire regardless of whether the user is manipulating the UI or not you'll need to add it to the tracking mode of the runloop.

Assuming that you're developing for the iPhone, that mode is UITrackingRunLoopMode. If you're developing for the Mac there is a similarly named NSEventTrackingRunLoopMode.

NSRunLoop *runloop = [NSRunLoop currentRunLoop];
NSTimer *timer = [NSTimer timerWithTimeInterval:0.1 target:self selector:@selector(myTimerAction:) userInfo:nil repeats:YES];
[runloop addTimer:timer forMode:NSRunLoopCommonModes];
[runloop addTimer:timer forMode:UITrackingRunLoopMode];
Ashley Clark
That still won't guarantee accuracy of overall timing. Timers aren't guaranteed to fire at exactly their configured interval. Worse, if each timer firing adds to the overall interval, the amount of error will increase with each timer firing!
bbum
I didn't intend to argue that they would guarantee anything other than the timers would fire while controls were tracking. Storing the date at the lap start and using that to calculate elapsed time is far more accurate (and simpler IMO) as you had stated in your answer.
Ashley Clark
A: 

That's just what I needed! Now the calls can continue while the user interacts with the UI. Thanks Ashley!

Timo