views:

687

answers:

2

Is there some way when sending this message to specify that I rather have my selector performed after all pending UI events, if any? Ie. give my aterDelay timer a lower priority in the event queue.

+1  A: 

Not directly. If you use performSelector:withObject:afterDelay: the selector is performed on the main thread, so by definition it will occur after all current "pending" UI events have been performed—but this might be in the middle of a scroll or animation, which you would probably consider to be one continuous event but is actually hundreds of separate ones.

However, you can achieve something similar using performSelectorInBackground:withObject:, and then calling [NSThread setThreadPriority:0.01] in the method being called. Be careful—you're opening a background thread, so you can't do any UI calls. However, this will allow you to do the work on a background thread with lower priority than the main UI thread. (Remember to set up an autorelease pool since it's in its own thread!)

Adam Ernst
Thanks. At least I kno now not to chase a red herring. I'll look into suppressing animation since I have a suspicion that is what makes my UI unresponsive sometimes.
Remus Rusanu
+2  A: 

Actually, performSelector:withObject:afterDelay: doesn't necessarily have to occur on the main thread; that's why there's a separate method performSelectorOnMainThread:withObject:waitUntilDone:. The documentation for performSelector:withObject:afterDelay: says

Invokes a method of the receiver on the current thread using the default mode after a delay.

If you want to perform a task in the background, you might look into +[NSThread detachNewThreadSelector:toTarget:withObject:], which will launch a new thread to perform your task, and leave the UI responsive. Using a separate thread to execute a long-running task which might otherwise lock up your UI is generally a good idea, but it does add complexity. If you're not familiar with threading, you may end up with bugs that won't make any sense.

In a comment above, you mentioned that you think animation may be at fault for making your UI unresponsive. If you're using the built-in support for animation (Core Animation or one of the Cocoa wrappers), animation shouldn't make your UI unresponsive. An unresponsive UI generally means that your program is doing a lot of work on the main thread before letting the run loop get back to service UI events.

BJ Homer