Kodeco Forums

Video Tutorial: Networking With NSURLSession Part 3: NSURLSessionTask

Learn how NSURLSessionTask has several subclasses that do the work of the network requests.


This is a companion discussion topic for the original entry at https://www.raywenderlich.com/3759-networking-with-nsurlsession/lessons/4

One of the most interesting video tutorials so far. Thank you for this!

You’re welcome! Glad it was helpful.

Nice video Jerry, I did not know about NSURLComponent

I usually do this to escape my string, I will now consider NSURLComponent

urlString.stringByAddingPercentEncodingWithAllowedCharacters(NSCharacterSet.URLQueryAllowedCharacterSet())

as for the returning to the main thread, is there an advantage to use the NSOperationQueue.mainQueueBlock

over a

dispatch_async(dispatch_get_main_queue(), { }

thanks

The biggest problem with NSURLSessionTask is the omission of task dependencies,

I usually wrap them into an NSOperation to have more flexibility

Alex

True, if you want more control over them, you can wrap them in an NSOperation and get full control. Of course, you don’t have to do that, and for simpler cases, you can just use the task directly.

No, it’s really a matter of style. Some people prefer the object syntax of NSOperationQueue while others prefer the simplicity of GCD and don’t mind the C-style method call. I usually prefer GCD, but am open to either.

I know this is not the purpose of this tutorial but I think that using the NetworkClient in the PhotoCell is not a very good pattern. The view should not know about the networking at all. I’d put this logic in the controller

It’s definitely something that would be open for discussion in a real-world project. There’s always a balance between strict adherence to rules and simplicity. In this case, the actual networking code is still broken out into its own layer, and while views wouldn’t normally call into that layer, it would make it more complex to have the controller try to track the lifecycle of the cell and cancel the network request for the appropriate cell when it gets reused.

Ok, for the challenge:

  1. Create a new background session & create a dictionary that holds the completion handler & its url
  2. Create the getImageInBackground() which takes the url and a completion block & returns task.
  3. This function will take the completion block “passed in by the caller which is didSet” and stores it in the dict with its url.
  4. We then create the request and a task for that url and resume the task and return it.
  5. Why don’t we call a completion here like we did in getImage()?

Jerry, do you know if we can do batch processing using NSURLSession ?

OData batch processing allows to send multiple requests at once

thanks

A background session is required to use the delegate method of communicating progress. When you create a background task, it actually gets handed off to a system process that is responsible for running the task. That system process uses the delegate methods to call back to your app. You saved the completion block in the dictionary so you could then call it in the NSURLSessionDelegate and NSURLSessionDownloadDelegate methods. Video tutorial #4 talks more about the difference in using the delegate methods and completion closures.

It looks like OData uses Multipart MIME messages to request a batch. While I think you could create this kind of request using only NSURLSession, it is one of the examples I use where a third party library probably makes more sense. Several of the popular networking libraries make dealing with multipart requests nicer and I would suggest using one of them, probably.

1 Like

Hi Jerry I like this point of using operation queue and just have a doubt if I would make a operation then which kind of operation It would be . Will it be sync or async operation and why .

You would usually think about a “chunk” of work that your app has to do and wrap that in an operation. Then the nature of this work and how it will be used is what will determine what kind of operation. Long-running tasks, like network or file tasks, almost always are going to be async. If your operation is doing anything with UIKit, it will have to run on the main thread and will be sync.