macOS NSTimer erroneously invalidated

ramy1989 · Dec 21, 2012

I have an application that works like a feed and should keep me updated about the changes (read from a html page).
There is how I create the timer:

Code:

timer=[NSTimer scheduledTimerWithTimeInterval: [interval integerValue ] target: self selector: @selector(updateInfo:) userInfo: nil repeats: YES];
//

Now the updateInfo: method works well, the problem is with the timer.
Sometimes I am not updated about the page (I can check this manually), so I suppose that for some reason the timer is invalidated, even if I don't invalidate it anywhere.
Now the question is: There is a possibility that if the computer goes to background, when it restarts the timer gets invalidated?

chown33 · Dec 21, 2012

Make a test case. A timer whose action method simply calls NSLog would suffice.

Also, have you used the debugger?

ramy1989 · Dec 21, 2012

Yes, I tried a lot of debug but I still can't find the problem.
I tried the following: I put a breakpoint in the triggered method, I close the laptop and see if reopening it the debugger steps inside that method.
It does step inside that method, but I still can't find the reason of the bug.
The problem is that this site updates very rarely (I'm also ignoring cache to make the update be detected more frequently), so I just find this to happen occasionally without knowing the reason.
I need to know what are the possible causes for a timer to be invalidated.

chown33 · Dec 21, 2012

I repeat: make a test case. It should be as simple as possible, using only a timer and NSLog. If that exhibits the same symptoms under the same conditions, then post again, describing exactly what happened and post your code. But if the simplified test case works as expected, and is called when expected, then the timer isn't the problem, something else is.

This debugging strategy of making a test case is part of a larger approach called "Break It Down", or decomposition. It means breaking the problem down into smaller simpler parts, each of which can be verified independently of the others. If each part works correctly, but the combination of them fails, then the problem lies in the combination. If an isolated part fails independently of the others, then the problem is likely in that part. But unless and until you break it down into individually testable parts, you can't possibly determine which individual part is at fault, if any, nor can you distinguish between a failing part (i.e. your assumption that the timer is being invalidated) and the possibility there's something wrong with your particular combination (a timer + your code).

I'm also a bit confused about your terminology. Your first post said "goes to background", but your later post says you're closing a laptop, which means the computer is going to sleep, not that your app is going into the background. "Background" is not "sleep".

So you need to describe exactly what your test conditions are that are causing the problem, and identify which OS version it's on.

ramy1989 · Dec 21, 2012

chown33 said:
I repeat: make a test case. It should be as simple as possible, using only a timer and NSLog. If that exhibits the same symptoms under the same conditions, then post again, describing exactly what happened and post your code. But if the simplified test case works as expected, and is called when expected, then the timer isn't the problem, something else is.

I tried it: Unfortunately the problem is the combination.

This debugging strategy of making a test case is part of a larger approach called "Break It Down", or decomposition. It means breaking the problem down into smaller simpler parts, each of which can be verified independently of the others. If each part works correctly, but the combination of them fails, then the problem lies in the combination. If an isolated part fails independently of the others, then the problem is likely in that part. But unless and until you break it down into individually testable parts, you can't possibly determine which individual part is at fault, if any, nor can you distinguish between a failing part (i.e. your assumption that the timer is being invalidated) and the possibility there's something wrong with your particular combination (a timer + your code).

Unfortunately I haven't followed this approach, the classes are too much related each other.They're all controller classes.

I'm also a bit confused about your terminology. Your first post said "goes to background", but your later post says you're closing a laptop, which means the computer is going to sleep, not that your app is going into the background. "Background" is not "sleep".

You're right, I've written background but though sleeping.

So you need to describe exactly what your test conditions are that are causing the problem, and identify which OS version it's on.

The conditions are apparently casual.I know they aren't, but I was unable to identify the common conditions.I would say "sometimes works sometimes not"
Now I've changed the code in a way that if the timer is invalid, I run a NSAlertPanel.I'm still testing it but till now hans't occurred yet, I'll let you if I get other clues.
And btw I'm under OS X Mountain Lion.

Search

Search

macOS NSTimer erroneously invalidated

ramy1989

macrumors newbie

chown33

Moderator

ramy1989

macrumors newbie

chown33

Moderator

ramy1989

macrumors newbie

Our Staff