[ios] Adds an assert to test if the timer runs on the main thread. #349
Conversation
| @@ -59,7 +59,8 @@ - (void)animatePolyline { | |||
| self.currentIndex = 1; | |||
|
|
|||
| // Start a timer that will simulate adding points to our polyline. This could also represent coordinates being added to our polyline from another source, such as a CLLocationManagerDelegate. | |||
| self.timer = [NSTimer scheduledTimerWithTimeInterval:0.05 target:self selector:@selector(tick:) userInfo:nil repeats:YES]; | |||
There was a problem hiding this comment.
So, the docs say that +[NSTimer scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:] “create[s] the timer and schedule[s] it on the current run loop in the default mode.”
Looking at this example’s view controller, this timer should have already been called on the main thread and current run loop — there don’t appear to be any dispatch calls or other threading methods.
That would make the difference in this PR just that we now use NSRunLoopCommonModes (and not NSDefaultRunLoopMode), which looks like it will improve how often the timer fires (e.g., during input tracking), but I’m not we’ve found/solved whatever the underlying problem is.
There was a problem hiding this comment.
From which thread/loop is mapViewDidFinishLoadingMap: called? Presumably the main/current one?
fabian-guerra
force-pushed
the
fabian-fix-timer-runloop
branch
from
4d08b94 to
f568e5e
Compare
fabian-guerra
force-pushed
the
fabian-fix-timer-runloop
branch
from
f568e5e to
9c5b2f6
Compare
fabian-guerra
changed the title
We have an outstanding issue with the line animation example. Randomly fails. My hypothesis is that for some reason the timer that triggers the animation runs in a background thread. I added an assertion to collect such information.