iOS: scheduled NSTimer versus performSelector with delay

There are a few times when a little one-off delay in providing UI interaction or animation provides some polish to your UX in an iOS application. There are two ways that one can go about doing this:

[NSTimer scheduledTimerWithTimeInterval:1.0
                                     target:self
                                     selector:@selector(turnOffSpinner:)
                                     userInfo:nil
                                     repeats:NO];
// or
[self performSelector:@selector(turnOffSpinner:) withObject:nil afterDelay:1.0];

They work in the same way, and since there is no repeat (no nth time to consider, etc.) I don’t know if there is really a difference here besidesĀ preferenceĀ or code appearance. I can’t invalidate the performSelector of course.

I am curious if anyone has an opinion on this type of use case or not.

Personally I like the performSelector path for this type of thing – it’s cleaner in appearance and communicates the idea a bit better. To me at least.

Related Posts Plugin for WordPress, Blogger...

3 thoughts on “iOS: scheduled NSTimer versus performSelector with delay

  1. Vishal Singh

    You can not invalidate but you can cancel performSelector using

    [NSObject cancelPreviousPerformRequestsWithTarget:self selector:SEL object:nil];.

    Also if you have performSelector on some target object, that object will be retained. I dont know by who, maybe by the run loop in which the selector was scheduled.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *


× two = 12

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>