开放式异步Web请求打交道时的UIViewController被弹出(AFNetworking) [英] Dealing with open async web requests when UIViewController is popped (AFNetworking)

查看:273
本文介绍了开放式异步Web请求打交道时的UIViewController被弹出(AFNetworking)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

下面的情况:

-A的UIViewController(A)推到导航堆栈结果
-On viewDidLoad中异步GET使用AFNetworking(单身AFHTTPClient整个应用程序共享)以填充视图(比如一个UILabel)各种用户的元素调用。结果
- 用户presses后退按钮请求返回结果之前,
-Assume其他活动视图控制器可以发出请求,所以你不能取消所有打开的操作

-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

所以,问题#1,你应该通过跟踪一个的UIViewController作出的公开请求,当用户离开该视图取消的优秀分子都要,还是应该让他们完成了和忽略它们?因为AFNetworking使用块,被更新的用户元件被保留在块中,因此不会导致崩溃时的观点已被弹出之后执行块的成功/失败。然而,缺点忽略它们似乎是不必要的网络流量。

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.

问题#2,在那里你会执行code取消由一个的UIViewController所做的操作? viewDidDisappear似乎权利并不因为用户可能已经向前(推新视图压入堆栈),而不是背面(弹出当前视图),在这种情况下,你不想取消打开请求,因为用户可能会回到当前视图,它不会再次加载。不过,我不认为的dealloc或viewDidUnload将被调用,而请求,因为该块执行将保持对用户元素的保留,所以我不认为它可以去那里。

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.

将在该AP preciate的想法。你认为什么是最好的做法?

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

推荐答案

一般来说,你并不需要在用户离开视图控制器取消请求。在内存管理方面,参考阻止自我将prevent造成邮件发送到释放实例的任何崩溃,所以不用担心那里。

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.

至于用户体验,我会说,你真的不应该担心它,直到它是一个问题(我们的开发人员有猜测完全​​错了什么将是我们的应用程序缓慢的诀窍)。如果要进行大的GET请求,不过,它的创造显着的缓慢,我的建议是让控制器做了HTTPClient -cancelAllHTTPOperationsWithMethod:在:路径> -viewDidUnload:(其它任何回调将是premature)

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).

这篇关于开放式异步Web请求打交道时的UIViewController被弹出(AFNetworking)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆