iOS Repeating a method until a Boolean is changed.

[gwelmarten]

Hi
So, I am trying to run a method as soon (well, within 0.2 seconds off) a boolean value changing. I'm doing it with an IF function that only runs the first part if the BOOL is set to NO. If the BOOL is set to YES, it starts an NSTimer to run the same method again in 0.2 seconds. For some reason this doesn't work - I presume to prevent you calling the same method and entering a crash loop. My code it below, however I expect I will have to change it for some suitable alternative method. Can anybody suggest one of these? My code looks like this:

-(void)checkForMessage {
    if (alertCurrentlyShowing == NO) {
            }
    else if (alertCurrentlyShowing == YES) {
        [NSTimer timerWithTimeInterval:0.2 target:self selector:@selector(checkForMessage) userInfo:nil repeats:NO];
    }
}

I'm sure there must be an alternative system for doing this. Can somebody point me in the direction of it please?

Thanks in advance,

Sam

 

[xStep]

How about;

[self performSelector: @selector(checkForMessage) withObject: nil afterDelay: 0.2];

If the compiler blocks this for some reason, they try placing the line into another method can call that.

By the way, the format of your method is wrong for calling from a time. The time expects to pass it's id.

 

[robbieduncan]

There is nothing preventing a method from scheduling itself to be called again via a timer. But the overall idea here seems wrong. If you are trying to make something happen when an alert (I can only assume a view of some sort) is closed why to just start it from the event handler for closing the alert?

 

[gwelmarten]

How about;

[self performSelector: @selector(checkForMessage) withObject: nil afterDelay: 0.2];

If the compiler blocks this for some reason, they try placing the line into another method can call that.

By the way, the format of your method is wrong for calling from a time. The time expects to pass it's id.

Thanks - that worked! I never knew you could call methods like that - it kind of reduces the need for NSTimer.

Sam

----------

There is nothing preventing a method from scheduling itself to be called again via a timer. But the overall idea here seems wrong. If you are trying to make something happen when an alert (I can only assume a view of some sort) is closed why to just start it from the event handler for closing the alert?

Hi
Thanks for replying. The problem was that I have loads of alerts that can all be called at various times (obviously not all at once) and they all run a method when completed (the same method). Unless I was going to re-write that method for each one to run different methods depending on BOOL values, this was the easiest way of doing it. And it worked.

Sam

 

[KnightWRX]

There is nothing preventing a method from scheduling itself to be called again via a timer. But the overall idea here seems wrong. If you are trying to make something happen when an alert (I can only assume a view of some sort) is closed why to just start it from the event handler for closing the alert?

What robbie said is much more efficient indeed. Especially since [self] is the one that seems to be aware of what alertCurrentlyShowing is. Instead of setting that BOOL in your code, why not change checkForMessage to doneWithAlert and call that ?

alertCurrentlyShowing = NO;
[self doneWithAlert]

-(void) doneWithAlert
{
     // code from your if goes here.
}

 

[dejo]

Are these "alerts" using UIAlertView? If so, do you know that it has UIAlertViewDelegate methods?

If not, you may want to look into using NSNotifications or KVO, since you want a method to run in response to a value changing.

Regardless, it sounds like you already have a solution in mind. Perhaps if you described the problem, we might have other ideas for how to solve it.