Im new to UITableViewDiffableDataSource,
When I prepare the DiffableDataSourceSnapshot and apply? I can see that update is triggering from Dispatch queue: com.apple.uikit.datasource.diffing Im expecting all UI operations has to be in the main-thread, does anyone having idea on how to push it in the main thread?
Related
Which queue is the best to place firebase operations? Is it the background queue, the main queue, or does it depend on how heavy the operation is?
It sort of depends on how much work you're doing in Firebase.
You can start out doing everything on the main thread. If you notice your UI lagging, switch to a background queue, and wrap all of your UI calls in a Dispatch.async call to the main thread.
I am just curious is there anyway to use a different thread rather than the main thread for the main queue?
Thanks,
The whole point of the main queue is to have it run on the main thread - the UI thread.
So no, there is no way to run the main queue on any other thread than the main thread.
Curious - why do you want the main queue on a different thread?
This doesn't so much apply on iOS, but on OS X if you're writing a program which is not an application and does not run the run loop of the main thread, you can have some other thread call dispatch_main() and that thread will host the main queue. There's rarely a need to do this.
I created this thread in my iOS app, and I'd like to stop it:
dispatch_queue_t myDispatch = dispatch_queue_create("com.myqueue", DISPATCH_QUEUE_CONCURRENT);
myDispatch thread within it invokes dispatch_global_queue and dispatch_main_queue respectively to execute heavy operations and to execute graphics operations.
But in response to a user action in the app can be called another function that uses another queue very similar to myDispatch. If myDispatch thread is terminated, there are no problems, but this call can also occur during the execution of myDispatch thread, and so my app crashes because both thread use the same arrays.
There is a way to stop or kill a thread before its termination? I'd like to kill the thread currently running and start the new thread.
If you want to cancel/stop background work you should be using NSOperation since as far as I know once you dispatch a block with GCD you lose control of it.
To cancel a GCD thread you have to use your own atomic flag.
I have just started working on iOS and have been going through Apple Reference material on GCD. dispatch_get_global _queue returns a concurrent queue to which one can submit a block to be executed.
However, we can achieve the same using dispatch_get_main_queue as well, right? Then, what exactly is the difference between dispatch_get_global_queue and dispatch_get_main_queue?
The global queue is a background queue and executes its blocks on a non-main thread. The main queue executes its blocks on the main thread.
You should put background work that does not involve changes to the user interface on the global queue, but use the main queue when the blocks make changes to the user interface. A very common pattern, for example, is to execute a "work" block on the global queue, and to have the work block itself dispatch back to the main queue to update a progress indicator.
dispatch_get_main_queue - should be used when you want to manipulate UI elements.
(It gets a background queue that you can dispatch background tasks that are run asynchronously... it won't block your user interface)
dispatch_get_global_queue - Can be used for network calls/core data.
I am studying this source code which demonstrates how to use NSURLConnection with NSOperation:
link
I am confused about the code at line 76
if (![NSThread isMainThread])
{
[self performSelectorOnMainThread:#selector(start)
withObject:nil waitUntilDone:NO];
return;
}
Why is the author making sure that the code is run on main thread?
Isn't the whole point of NSOperation to not run on main thread and in a background thread so that it doesn't block?
The code is from this article that explains it although it doesn't answer my questions: http://eng.pulse.me/concurrent-downloads-using-nsoperationqueues/
From the NSURLConnection docs, you can see;
NSURLConnection’s delegate methods—defined by the NSURLConnectionDelegate Protocol protocol—allow an object to receive informational callbacks about the asynchronous load of a URL request. [...] These delegate methods are called on the thread that started the asynchronous load operation for the associated NSURLConnection object.
Starting an operation on an NSURLConnection works on any thread, however it's very useful to get the delegate callbacks on the GUI/main thread if you want to - for example - display progress.
If you use NSURLConnection asynchronous you need to launch this operation on Main Thread for getting the callback. If you launch an asynchronous NSURLConnection from a background thread you can lose it callback if your background thread from you launched your NSURLConnection is busy for other activity.
If you call start method in main thread, A current operation main method will be run in main thread, but you push current operation to NSOperationQueue（not main queue), start method call in sub thread, a current operation main method in sub thread.
Sub Thread Photo
Main Method in Sub Thread
If this is an example I believe that this is put into there in order for you to see the difference between having that code in there and not. If this code were to be executing concurrently and is supposed to leave your main thread alive then indeed that section of code should not be there however it may have been put in there for you to remove and see the difference. However you are indeed correct. Browsing through the rest of the file it looks like that should not be in there if you are wanting to leave your main thread open.
The reason is, on iOS 4.0+, wether the operation is concurrent or not, the operation is ran in a background thread. Since in this case the operation is concurrent, the method exists immediately and the thread is killed so no delegate method is called (NSURLConnection calls delegate method on the thread from which it started).
The only options are, either to start an NSRunLoop (very hectic) or use a thread that already has one (main thread) - so that's why the start method is run from the main thread.
Has nothing to do with updating UI as many suggested (although i understand the point but the entire reason to run an NSURLConnection in a queue is to process the delegate callbacks in a seperate thread to avoid blocking UI). That wasn't the intention of the author, the fact that it is UIKit safe is a mere consequence.