NSDefaultRunLoopMode vs NSRunLoopCommonModes NSDefaultRunLoopMode vs NSRunLoopCommonModes ios ios

NSDefaultRunLoopMode vs NSRunLoopCommonModes


A run loop is a mechanism that allows the system to wake up sleeping threads so that they may manage asynchronous events. Normally when you run a thread (with the exception of the main thread) there is an option to start the thread in a run loop or not. If the thread runs some sort or long-running operation without interaction with external events and without timers, you do not need a run loop, but if your thread needs to respond to incoming events, it should be attached to a run loop in order to wake up the thread when new events arrive. This is the case of NSURLConnection generated threads, as they only wake on incoming events (from the network).

Each thread can be associated to multiple run loops, or can be associated to a specific run loop that can be set to work in different modes. A "run loop mode" is a convention used by the OS to establish some rules for when to deliver certain events or collect them to be delivered later.

Usually all run loops are set to the "default mode" which establishes a default way to manage input events. For example: as soon as a mouse-dragging (Mac OS) or touch (on iOS) event happens then the mode for this run loop is set to event tracking; this means that the thread will not be woken up on new network events but these events will be delivered later when the user input event terminates and the run loop set to default mode again; obviously this is a choice made by the OS architects to give priority to user events instead of background events.

If you decide to change the run loop mode for your NSURLConnection thread, by using scheduleInRunLoop:forModes:, then you can assign the thread to a special run loop mode, rather than the specific default run loop. The special pseudo-mode called NSRunLoopCommonModes is used by many input sources including event tracking. For example assigning NSURLConnection's instance to the common mode means associates its events to "tracking mode" in addition to the "default mode". One advantage/disadvantage of associating threads with NSRunLoopCommonModes is that the thread will not be blocked by touch events.

New modes can be added to the common modes, but this is quite a low-level operation.

I would like to close by adding a few notes:

  • Typically we need to use a set of images orthumbnails downloaded from the network with a table view. We may think thatdownloading these images from the network while the table view isscrolling could improve the user experience (since we could see the images whilescrolling), but this is not advantageous since the fluidity ofscrolling can suffer greatly. In this example with NSURLConnection a run loop should not be used; it would be better to use the UIScrollView delegate methods to detect when scrolling is terminated and then update the table and download new itemsfrom the network;

  • You may consider using GCD which will help you to "shield" your codefrom run loop management issues. In the example above, you mayconsider adding your network requests to a custom serial queue.