CODEWITHSUNDEEP
multithreadingswiftconcurrencynsurlsession
Jack Walsh
Jack Walsh

Reputation: 141

Function/Code Design with Concurrency in Swift

I'm trying to create my first app in Swift which involves making multiple requests to a website. These requests are each done using the block

var task = NSURLSession.sharedSession().dataTaskWithRequest(request, completionHandler: {data, response, error -> Void in ... } 
task.resume()

From what I understand this block uses a thread different to the main thread.

My question is, what is the best way to design code that relies on the values in that block? For instance, the ideal design (however not possible due to the fact that the thread executing these blocks is not the main thread) is

func prepareEmails() {
    var names = getNames()
    var emails = getEmails()
    ...
    sendEmails()
}

func getNames() -> NSArray {
    var names = nil
    ....
    var task = NSURLSession.sharedSession().dataTaskWithRequest(request, completionHandler: {data, response, error -> Void in 
        names = ...
    }) 
    task.resume()
    return names
}

func getEmails() -> NSArray {
    var emails = nil
    ....
    var task = NSURLSession.sharedSession().dataTaskWithRequest(request, completionHandler: {data, response, error -> Void in 
        emails = ...
    }) 
    task.resume()
    return emails
}

However in the above design, most likely getNames() and getEmails() will return nil, as the the task will not have updated emails/name by the time it returns.

The alternative design (which I currently implement) is by effectively removing the 'prepareEmails' function and doing everything sequentially in the task functions

func prepareEmails() {
    getNames()
}

func getNames() {
    ...
    var task = NSURLSession.sharedSession().dataTaskWithRequest(request, completionHandler: {data, response, error -> Void in 
        getEmails(names)
    }) 
    task.resume()
}

func getEmails(names: NSArray) {
    ...
    var task = NSURLSession.sharedSession().dataTaskWithRequest(request, completionHandler: {data, response, error -> Void in 
        sendEmails(emails, names)
    }) 
    task.resume()
}

Is there a more effective design than the latter? This is my first experience with concurrency, so any advice would be greatly appreciated.

Upvotes: 3

Views: 677

Answers (2)

Alex Lynch
Alex Lynch

Reputation: 1

The answers above (particularly Rob's DispatchQueue based answer) describe the concurrency concepts necessary to run two tasks in parallel and then respond to the result. The answers lack error handling for clarity because traditionally, correct solutions to concurrency problems are quite verbose.

Not so with HoneyBee.

HoneyBee.start()
        .setErrorHandler(handleErrorFunc)
        .branch {
             $0.chain(getNames)
             +
             $0.chain(getEmails)
        }
        .chain(sendEmails)

This code snippet manages all of the concurrency, routes all errors to handleErrorFunc and looks like the concurrent pattern that is desired.

Upvotes: 0

Rob
Rob

Reputation: 438277

The typical pattern when calling an asynchronous method that has a completionHandler parameter is to use the completionHandler closure pattern, yourself. So the methods don't return anything, but rather call a closure with the returned information as a parameter:

func getNames(completionHandler:(NSArray!)->()) {
    ....
    let task = NSURLSession.sharedSession().dataTaskWithRequest(request) {data, response, error -> Void in 
        let names = ...
        completionHandler(names)
    }
    task.resume()
}

func getEmails(completionHandler:(NSArray!)->()) {
    ....
    let task = NSURLSession.sharedSession().dataTaskWithRequest(request) {data, response, error -> Void in 
        let emails = ...
        completionHandler(emails)
    }
    task.resume()
}

Then, if you need to perform these sequentially, as suggested by your code sample (i.e. if the retrieval of emails was dependent upon the names returned by getNames), you could do something like: 

func prepareEmails() {
    getNames() { names in 
        getEmails() {emails in
            sendEmails(names, emails) // I'm assuming the names and emails are in the input to this method
        }
    }
}

Or, if they can run concurrently, then you should do so, as it will be faster. The trick is how to make a third task dependent upon two other asynchronous tasks. The two traditional alternatives include

  1. Wrapping each of these asynchronous tasks in its own asynchronous NSOperation, and then create a third task dependent upon those other two operations. This is probably beyond the scope of the question, but you can refer to the Operation Queue section of the Concurrency Programming Guide or see the Asynchronous vs Synchronous Operations and Subclassing Notes sections of the NSOperation Class Reference.

  2. Use dispatch groups, entering the group before each request, leaving the group within the completion handler of each request, and then adding a dispatch group notification block (called when all of the group "enter" calls are matched by their corresponding "leave" calls):

    func prepareEmails() {
    let group = dispatch_group_create()

    var emails: NSArray!
    var names: NSArray!

    dispatch_group_enter(group)
    getNames() { results in
        names = results
        dispatch_group_leave(group)
    }

    dispatch_group_enter(group)
    getEmails() {results in
        emails = results
        dispatch_group_leave(group)
    }

    dispatch_group_notify(group, dispatch_get_main_queue()) {
        if names != nil && emails != nil {
            self.sendEmails(names, emails)
        } else {
            // one or both of those requests failed; tell the user
        }
    }
}

Frankly, if there's any way to retrieve both the emails and names in a single network request, that's going to be far more efficient. But if you're stuck with two separate requests, you could do something like the above.

Note, I wouldn't generally use NSArray in my Swift code, but rather use an array of String objects (e.g. [String]). Furthermore, I'd put in error handling where I return the nature of the error if either of these fail. But hopefully this illustrates the concepts involved in (a) writing your own methods with completionHandler blocks; and (b) invoking a third bit of code dependent upon the completion of two other asynchronous tasks.

Upvotes: 4

Related Questions