Sorry, I'm not sure of the right language here, but when methods are called because they are either delegate methods, or methods called as a result of being listed as the target of an observer, are they executed on the main thread?
I'm wondering if I can just make UI changes in these methods, or do I have to wrap them in
dispatch_async(dispatch_get_main_queue(), ^{ UI stuff });
TIA: John
For delegates this can vary. If the documentation does not specify, then usually they are sent on the main thread. Traditionally UIKit must be used on the main thread so those delegates will almost always be called from the main thread.
For notifications I think you want this little snip.
A notification center delivers notifications to observers synchronously. In other words, the postNotification: methods do not return until all observers have received and processed the notification. To send notifications asynchronously use NSNotificationQueue. In a multithreaded application, notifications are always delivered in the thread in which the notification was posted, which may not be the same thread in which an observer registered itself.
And finally for KVO, the notifications can come in from other threads. Here is what an Apple Engineer had to say about handling them.
http://lists.apple.com/archives/cocoa-dev/2007/May/msg00022.html
As stated, the thread will vary based on the caller. In your delegate method, if you need to adapt, you can always do something like this:
if ([NSThread isMainThread]) {
// do the UI stuff as normal
} else {
dispatch_async(dispatch_get_main_queue(), ^{ UI stuff });
}
The basic idea is that in all cases the observer or delegate method are called in the same thread the initial notification (for the observer pattern) or delegating code are running, so if you're not sure it's recommended to dispatch your UI block in the main thread. I will try to justify this statements in the reasoning below, of course I can be wrong.
Unless explicitly specified in the delegate protocol documentation, in the delegate pattern a method is called directly in the same thread the caller is running at the moment of the call. E.g. if the caller (delegating object) wants to call his delegate and is currently running on "Thread-1" then the call will happen in the same thread:
// this is running in "Thread-1" --> then aDelegateMethod will continue on "Thread-1"
[myDelegate aDelegateMethod]
As far as the observer pattern, I don't see any valid reason for the system to send an observing notification explicitly on the main thread, especially if the original value change that originates the notification is running in another thread. In fact in the KVO case the runtime changes the class definition by adding some private methods that override the setter methods to do the notifications, and I don't see a valid reason to do this call explicitly in the main thread. So according to me a KVO notification can originate from any thread and this thread is the same that is running the value change in the observed class.
Finally the NSNotificationCenter based mechanism sees his notifications called by the same thread where the original notification has been posted. This is clearly stated in Apple documentation (and it's worth to say that every thread has its own notification queue).
So in all cases the thread is maintained and if you want to be sure your UI block is called in the main queue then use the GCD call that you posted in your question.
© 2022 - 2024 — McMap. All rights reserved.