NSTimer erroneously invalidated

Discussion in 'Mac Programming' started by ramy1989, Dec 21, 2012.

  1. macrumors newbie

    Joined:
    Nov 7, 2012
    #1
    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?
     
  2. macrumors 603

    Joined:
    Aug 9, 2009
    #2
    Make a test case. A timer whose action method simply calls NSLog would suffice.

    Also, have you used the debugger?
     
  3. thread starter macrumors newbie

    Joined:
    Nov 7, 2012
    #3
    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.
     
  4. macrumors 603

    Joined:
    Aug 9, 2009
    #4
    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.
     
  5. thread starter macrumors newbie

    Joined:
    Nov 7, 2012
    #5
    I tried it: Unfortunately the problem is the combination.

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

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

    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.
     

Share This Page