Switch from main queue to current NSOperation Thread

Question

I want to download and process a image from Firebase to local directory on secondary thread and then update the UI. The problem is firebase returns in completion on main thread and not on the thread on which my NSOperation is being executed. I want to switch back to the thread on which my NSOperation is working. Is there a way I can achieve it ?

1. Download Meta Data from Firebase Realtime DB
2. Process and Store in Local Db
3. Update UI
4. Download image From Firebase to temp location
5. Once properly downloaded move to appropriate Directory
6. Update UI

Below is the sample code and have mentioned thread on which the completion is called.

    [photosDetailReferenceDB observeEventType:FIRDataEventTypeValue  withBlock:^(FIRDataSnapshot * _Nonnull snapshot) {

     //Main Thread  

    [self.downloadQueue addOperationWithBlock:^{

                //Bg Thread 2 

                [[[FirebaseHelper sharedManager].storageuserRef child:serverPath] writeToFile:[NSURL fileURLWithPath:tempPath] completion:^(NSURL * _Nullable URL, NSError * _Nullable error) {

                    //Main Thread 
                    // Here I want to switch back to Thread 2. 
                    // Since yet I have to move the image back to proper directory and update the image status in core data. 


                }];

        }];

 }];

Answer 1

It helps to stop thinking in terms of threads and start thinking in terms of queues.

Specifically, the thread of execution is, beyond the main thread, irrelevant. What is relevant, though, is the queue upon which the code is executed and whether or not that queue concurrent or serial execution.

So, in your case, the FirebaseHelper's callback to the main queue would immediately dispatch a block or operation to your background computation queue.

It may be as simple as dispatch_async() in the pure GCD queue case or, since you are using NSOperation, adding an operation to the appropriate NSOperationQueue.

---

If I add an operation to NSOperationQueue it would be different then the one already executing. Firebase will be returning 100's of object that means there would be 100's of NSOperations already and this would lead to create another sub operation for each of them

If your operation queue is serial, then the operations will be executed one after the other, effectively as if it were the same thread (the actual thread of execution is irrelevant).

However, you don't want to have 100s or thousands of operations in flight, even in a serial queue.

You need to separate the work from the execution of the work. That is, you need to store a representation of the work that needs to be done in your data model and then pick off bits of work to be executed as your work queue or work queues (if parallelization makes sense) are emptied.