Reputation: 1071
I know that it is strongly recommended to update UI only in the main thread. Otherwise it can lead to unexpected crashes.
But I tried to use both ways, but have not faced any problems yet. Maybe my scenarios were simple enough the problems only occur in the complex code, but I wonder to know this matter deeper. And try to find the situation when neglecting this rule gives 100% program abortion or some other serious problems (deadlocks, race conditions etc.).
Maybe some of you have faced this 'enemy' or remember the exact examples in your practice. Would be very grateful for the possible illustrations in a code (or pseudocode).
Thanks
Upvotes: 0
Views: 56
Reputation: 104065
The whole UIKit used to be threading unsafe, so that calling almost anything from a background thread used to crash, almost always. Now the situation is much better, but with GCD, it’s dead simple to update the UI on the main thread anyway. The current pattern is something like this:
[someWorker runBackgroundOperationAndCall:^{
dispatch_async(dispatch_get_main_queue(), ^{
// update UI
});
}];
It’s so simple I guess it’s not really worth a second thought. When I forget to update the UI from the main thread, it sometimes works, sometimes doesn’t – UI isn’t updated immediately, there’s a strange flicker or similar stuff. With threading, it’s a good idea to do things the officially sanctioned right way, otherwise you will enter the world of pain when least expected.
(And sorry, I don’t have a short snippet that would demonstrate things going wrong when updating the UI from a background thread.)
Upvotes: 1