18

I need to do the following tasks:

1) Read some data from sqlite database

2) Process the data

3) With the processed data generate some charts

If I have a user who enters many data in the application, one day this analisys can become slow and freeze the UI.

So, what is the correct way to process it allowing the user to interact with the UI, with the option to cancel the operation or exit the screen?

I need to make simple threads for all my tasks and with a cancel event or flag to stop each one? Or there is another way do to it?

For example:

Task 1: Read the data from sqlite in a thread with a flag to stop the process if needed.

Task 2: Process the data in a thread with a flag to stop the process if needed.

Task 3: Deliver the data to a 3rd party component. At this point, its possible to cancel the operation that is running on other component?

Am I thinking the right way or I could improve on something?

Rafael
  • 1,655
  • 3
  • 17
  • 25

2 Answers2

28

This is the recommended and fastest way by Apple with GCD (Grand Central Dispatch). It´s also easier to read and understand, because the logic is linear but not split between methods.

Note that it shows the weakSelf "dance" which is necessary if i.e. the async may outlive the controller it is called for, thus it makes a weak reference to it and then checks if it is alive and retains it to update:

Swift 4 & 3

 DispatchQueue.global().async() {
      print("Work Dispatched")
      // Do heavy or time consuming work

      // Then return the work on the main thread and update the UI
      // Create weak reference to self so that the block will not prevent it to be deallocated before the block is called.
      DispatchQueue.main.async() {
           [weak self] in
           // Return data and update on the main thread, all UI calls should be on the main thread 
           // Create strong reference to the weakSelf inside the block so that it´s not released while the block is running
           guard let strongSelf = self else {return}
           strongSelf.method()
      }
 }

Objective-C

// To prevent retain cycles call back by weak reference
   __weak __typeof(self) weakSelf = self;  // New C99 uses __typeof(..)

    // Heavy work dispatched to a separate thread
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        NSLog(@"Work Dispatched");
        // Do heavy or time consuming work
        // Task 1: Read the data from sqlite
        // Task 2: Process the data with a flag to stop the process if needed (only if this takes very long and may be cancelled often).

        // Create strong reference to the weakSelf inside the block so that it´s not released while the block is running
        __typeof(weakSelf) strongSelf = weakSelf;
        if (strongSelf) {

            [strongSelf method];

            // When finished call back on the main thread:
            dispatch_async(dispatch_get_main_queue(), ^{
                // Return data and update on the main thread
                // Task 3: Deliver the data to a 3rd party component (always do this on the main thread, especially UI).
            });
        }
    });

The way to cancel the process is to include a BOOL value and set it to stop from the main thread if the work being done is no longer needed. But, it may not be worth it because the user will not notice the background work so much unless it´s heavy calculations. To prevent retain cycles use weak variables like:

__weak __typeof(self) weakSelf = self; // Obj-C
[weak self] in

and call weakSelf with strong reference inside the block (to prevent crashes if the calling VC has been released). You can use the exact type like UIViewController or the __typeof() function (in C99 you need to use __typeof(..) but previously you could use __typeof(..) directly) to refer to the actual type:

Objective-C

__typeof(weakSelf) strongSelf = weakSelf;
if (strongSelf) {
   [strongSelf method];
}

Swift 4 & 3

if let weakSelf = self {
   weakSelf.method()
}

or

// If not referring to self in method calls.
self?.method()

NOTE: Use GCD or Grand Central Dispatch, it´s most simple, the recommended way by Apple and the code flow is in logical order.

Sverrisson
  • 17,970
  • 5
  • 66
  • 62
  • Hannes, its better to use GCD instead of NSOperation? Both let you do the same thing or have significant differences? – Rafael Aug 10 '12 at 14:22
  • The code is simpler and all in one place with GCD. It´s new for the iOS and is the recommended way by Apple and it´s also very efficient. It uses blocks but as you see from above the code is simple, in one place and is also in the right logical work order. – Sverrisson Aug 10 '12 at 14:25
  • Though (playing devils advocate) `NSOperation` gives you prioritisation, multiple threads in your pool and isCancelled functionality for free at the cost of making you put your code in a different class. If you are doing a small operation, use GCD. If it's more involved, I would use NSOperation. (NB I don't know where the dividing line between these two approaches is :) – deanWombourne Aug 10 '12 at 14:28
  • GCD has multiple threads that may have different priorities and asynchronous and synchronous, i.e. above the developer might also create his own thread with this customization, but it is not needed for this task. Apple puts an emphasis on using GCD. – Sverrisson Aug 10 '12 at 14:36
  • My case is very simple. I dont want to support multithreads or complex operations, just processing without freezing the UI and with a cancel option. GCD allow me to do that, then its enough for me. I will also study NSOperation to know when to use it. Thanks Hannes and dean for helping me. – Rafael Aug 10 '12 at 14:47
  • You should also look at the Concurrency Programming Guide https://developer.apple.com/library/mac/#documentation/General/Conceptual/ConcurrencyProgrammingGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40008091-CH1-SW1 – Sverrisson Aug 10 '12 at 15:10
  • NSOperation is built on GCD since iOS 5 – toasted_flakes Feb 05 '14 at 22:23
  • @grasGendarme - My point is that GCD allows much simpler code for performing background tasks. It´s linear and in one place. Further info refer to: Concurrency Programming Guide. – Sverrisson Feb 05 '14 at 23:50
  • 1
    Psst... You don't need to nil check before messaging an object. – paulrehkugler May 15 '14 at 23:56
  • @HannesSverrisson i think it should be typeof(weakSelf) strongSelf = weakSelf to avoid capturing self object within the block, what do you think? – Mert Buran May 14 '15 at 14:52
  • @MertBuran your right it´s better to refer to typeof(weakSelf) strongSelf = weakSelf, it´s referred to at runtime: http://stackoverflow.com/questions/12081502/typeof-operator-in-c. I have changed the answer accordingly. – Sverrisson May 17 '15 at 12:28
1

this is how to detach functions from your main thread

[NSThread detachNewThreadSelector:@selector(yourmethode:) toTarget:self withObject:nil];

touti
  • 1,164
  • 6
  • 18