NSDefaultRunLoopMode vs NSRunLoopCommonModes

A run loop is a mechanism that provides the possibility for the system to wake up sleeping threads to manage asynchronous events. Normally when you run a thread (with the exception of the main thread) you have the option to start for it a run loop or not. If the thread does some sort or long-runnign operation with no interaction with external events and no timers, you don't need a run loop, but if your thread needs to respond to incoming events, you need to attach it to a run loop in order to wake up this thread when new events arrive. This is the case of NSURLConnection generated threads, as the live on incoming events only (from the network).

Each thread can be associated to different run loops, or it can be associated to a run loop but this run loop can be set to work on different modes. A "run loop mode" is a convention used by the OS to establish some rules on when delivering certain events or simply suspend this delivery and then collect them all to be delivered later. Usually all run loop are set to the "default mode" which establishes a default way to manage input events. As soon as some 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 woke 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 the

scheduleInRunLoop:forModes:

method, then you allow the thread's events to be associated not to a specific run loop (the default) but to a different run loop mode. In particular the special pseudo-mode called "common" allows to permanently associate the input sources to all modes that are - or will be - associated to the "common mode". Of course event tracking mode is part of this family of modes, so the method applied on NSURLConnection's instance means: please associate the connection source events to "tracking mode" in addition to "default mode".

 

Finally you can add new modes to the common modes, but this is a quite low-level operation.

I would to close by adding a few notes: - typically we need to associate to a table view a set of images or thumbnails downloaded from the network; even if we may thing that download these images from the network while the table view is scrolling could improve the UI (because we can see the images while scrolling) infact this is dangerous as the final effect will be a scrolling not fluid. So don't add NSURLConnection to the run loop in such case but use the UIScrollView delegate methods to detect when scrolling is terminated to update the table and download new items from the network - you may consider to use GCD which will help you to "shield" your code from run loop management issues. So in the example above, you may consider to add your network requests to a custom serial queue.

from: http://stackoverflow.com/questions/7222449/nsdefaultrunloopmode-vs-nsrunloopcommonmodes