Question

Here’s the scenario:

-A UIViewController (A) is pushed onto the navigation stack
-On viewDidLoad an async GET is called using AFNetworking (a singleton AFHTTPClient shared throughout the application) to populate various user elements on the view (say a UILabel).
-The user presses the back button before the request returns
-Assume other active view controllers may be making requests so you can’t cancel all open operations

So question #1 is, should you track the open requests made by UIViewController A and cancel the outstanding ones when the user leaves that view, or should you let them finish up and ignore them? Since AFNetworking uses blocks, the user elements being updated are retained inside the block and therefore won’t cause a crash when the success/fail block is executed after the view has been popped. However the downside to ignoring them seems to be unnecessary network traffic.

Question #2 is, where would you execute the code to cancel the operations made by UIViewController A? viewDidDisappear doesn’t seem right because the user may have gone forward (pushed a new view onto the stack) instead of back (popped the current view), in which case you don’t want to cancel the open requests because the user may come back to the current view and it won’t load again. However, I don’t think dealloc or viewDidUnload will be called while the request is executing since the block will keep a retain on the user elements so I don’t think it can go there.

Would appreciate thoughts on this. What do you think is best practice?

Answer 1

Generally speaking, you don’t really need to cancel requests when a user leaves a view controller. In terms of memory management, a reference to block self will prevent any crashes caused by sending messages to deallocated instances, so no worries there.

As far as user experience, I would say that you shouldn’t really worry about it until it’s a problem (we developers have a knack for guessing completely wrong on what will be slow in our applications). If you are making large GET requests, though, and it’s creating noticeable sluggishness, my suggestion would be to have the controller do HTTPClient -cancelAllHTTPOperationsWithMethod:path: in -viewDidUnload: (any other callback would be premature).