In my application, I have a login screen presented as a modal view controller. Once the user logs in successfully, the modal view is dismissed and the application's data is updated from a web service. The user can then work with the new data downloaded.
Periodically, we check to see if any data needs to be synced back to the server. We do this by using a set of functions in our AppDelegate that periodically polls for any changes. We have one method that starts the polling:
- (void) startBackgroundSync {
if (self.queue == nil) {
self.queue = [[NSOperationQueue alloc] init];
}
[self performSelector:@selector(doBackgroundSync) withObject:nil afterDelay:5.f];
}
And then -doBackgroundSync actually checks for changes and adds a sync operation to the NSOperationQueue. It then resets itself like so:
-(void) doBackgroundSync {
NSLog(@"Check for changes");
// check for changes and add operation to queue
[self performSelector:@selector(doBackgroundSync) withObject:nil afterDelay:5.f];
}
Originally, we called -startBackgroundSync from the modal login view controller (before it was dismissed). We then change some other settings and dismiss the modal view controller. The login view controller is not released when dismissed, but retained by the AppDelegate (there are later times when we have to "relock" the application). After the modal view controller was dismissed, -doBackgroundSync was never getting called. If we put the call for -startBackgroundSync in the main view controller that's displayed after the modal view controller is dismissed, then -doBackgroundSync is continuously called as expected.
What would cause this behavior? Is there something in -dismissModalViewController that would invalidate anything in the run loop created by that view controller?