0

Could any one please tell me what is the real advantage gained by using NSURLSessionTask inside NSOperation while making http network calls in iOS? We can get the abstraction by wrapping NSURLSessionTask inside any other plain custom class e.g APIRequest. What is the real motto behind using NSOperation for network calls? Thanks in advance.

Arjuna
  • 697
  • 4
  • 17
  • Not very sure but I feel your question is more towards `NSURLSessionTask` vs `NSOperation`. Would that be more correct? – Ganesh Somani Apr 04 '19 at 10:00
  • Yes, correct. Thank you. – Arjuna Apr 04 '19 at 10:01
  • In that case it is much simpler. NSOperationTask is more generic and can be used for any kind of tasks(e.g. function call, counters, etc) but NSURLSessionTask would be more specific for URLSession related tasks. – Ganesh Somani Apr 04 '19 at 10:19
  • But why to wrap it inside NSOperation? You can wrap it inside other custom class. By wrapping inside NSOperation you are depending on operation queues and you can't change to some thing else easily if you want to. – Arjuna Apr 04 '19 at 11:37
  • Ok. We wrap it for multiple reasons like status, priority management, cancelation, KVO Compliant behaviour. – Ganesh Somani Apr 04 '19 at 11:44
  • cancel,status we can get from normal custom class. So if don't want the other things there is no need to use it right? Even priority is supported by URLSession task which we can wrap inside our custom class. – Arjuna Apr 04 '19 at 11:47
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/191293/discussion-between-ganesh-somani-and-arjuna). – Ganesh Somani Apr 05 '19 at 06:22
  • You can, but that would be overhead for you. Also NSOperation and usage of queue lets you execute these task even when app moves to background - https://stackoverflow.com/questions/11376873/background-task-with-nsoperation-and-nsoperationqueue-ios – Ganesh Somani Apr 05 '19 at 06:23
  • OK, Thank you very much. – Arjuna Apr 05 '19 at 06:34

1 Answers1

1

My first inclination would be to say "none whatsoever", but after thinking about it a bit more, that's probably slightly too glib.

In general, if your app already uses NSOperation for performing other tasks, it may be useful to have your network operations just be another special type of operation, so that you can kind of manage them in the same way. Of course, if you do that, you almost certainly shouldn't use NSOperation directly; instead, use a custom subclass of NSOperation that actually knows how to cancel the network operation when you call its cancel method. Using the NSOperation class as-is could be even worse than useless, if misused.

The best explanation I have for why it is so common is historical. Apparently, a lot of programmers mistakenly believed that wrapping synchronous NSURLConnection requests inside of NSOperation objects gave them a way to cancel those requests. In reality, all it did was prevent the app from ever getting the data from the request, but the request continued until its completion. Unfortunately, in updating that code to use NSURLSession, that legacy baggage was often brought along for the ride, and is likely just as problematic now as it was then.

As others have mentioned in comments, you could also ostensibly use operations to allow pending requests to continue after your app gets backgrounded, but in general, doing so is probably a mistake. After all:

  • For short requests, this provides little to no advantage compared with just reissuing the request on foregrounding.
  • For long requests, background downloads/uploads are a better choice, both because they are considerably less resource intensive (because your app can be terminated by the OS to free up memory) and because you have an actual guarantee that the OS won't kill your process anyway.

So really, the advantages to using a custom NSOperation subclass are the same as the advantages of using an NSOperation for anything else in your app — no more, no less.

dgatwood
  • 10,129
  • 1
  • 28
  • 49