iOS网络连接失败政策建议

Question

我正在寻找有关处理iPhone应用程序(iOS9/Swift2/Xcode7)网络连接问题的最佳方法的建议,以提供最佳用户体验,因为我们知道移动数据网络不可靠.我有我的编码选项,但我想知道什么对其他有经验的技术人员有效.那里有很多信息,但是当发生连接失败时,我找不到具体的策略.

这是我处理我想要实现的失败连接的基本策略(以及问题):

1. 应用程序向api.myserver.com发送请求,请求失败
2. 等待X秒(s)并再次尝试向api.myserver.com请求(您会建议多少次尝试以及在什么时间间隔？)
3. 尝试ping其他服务器(即google.com),看看我们是否可以访问api.myserver.com以外的资源
4. 如果我们能够成功ping google.com,那么我们就知道我们的互联网正在运行,所以我们再次尝试ping api.myserver.com
5. 如果最后一次ping失败,那么我们会提醒用户我们由于某种原因无法通信,请稍后再试

我正在使用Apple技术推荐的这个SO答案中概述的理念,这通常意味着您始终首先检查与服务器的连接,使用Reachability作为单独检查以确保手机硬件可用.

在此过程中的任何时候,如果Reachability为false,那么我们会将请求放入队列中,以便在恢复电话硬件连接时再次尝试.

我认为我已经掌握了所涉及的代码,但是寻找诸如"这对我们的应用程序有用并且在连接问题期间提供良好的用户体验......"并且被批准在Apple应用程序商店中使用的见解. ".我理解在失败的情况下尝试/重试连接的概念并警告用户(目前我的代码已成功完成此操作),但仍然不能很好地使用一个好的策略来使用多少次我应该尝试重新连接以及什么间隔？

Answer 1

对于我所使用的大多数应用程序,定义具有不同规则的几类请求非常有用.对于每个类别,请考虑重试是否合适以及在考虑请求失败之前您能够真正等待多长时间.

1. 最敏感的是阻塞请求,用户必须允许在继续之前完成的事情.登录,签出,一些编辑操作等.对于这些通常不值得重试(1)并且需要立即将失败传达给用户:如果设备离线,则让用户决定何时再次尝试,如果请求失败你可能已经让用户等了太久.由于故障往往会阻止用户,因此通常还需要突出地进行通信.
2. 不太敏感的通常是使用已启动但非阻止的操作:拉取刷新,加载所选集合项的详细信息或执行搜索.您的用户可能正在等待查看结果,但可能会自由放弃或导航到应用程序中的其他位置并稍后再回来查看.仍然需要传达故障,以便用户可以选择再次尝试或者至少知道停止等待,但这些故障的通知可能不那么突出.这里重试开始有意义.我通常首先尝试从用户的角度定义时间限制,他们在应用程序感觉被破坏之前等待多长时间,然后让它成为您的请求可以等待连接多长时间或作为响应进行任意数量的重试的限制连接失败.
3. 更不敏感的是仅由您的用户间接触发的请求; 轮询更新,加载非必要图像,加热缓存.这些你可能会重试,但失败的影响往往很低,可能无关紧要.

在所有这些请求中,您的重试策略实际上只影响#2,因此我会确保您在担心之前确实有此类型的请求.假设这些确实适用于您的应用程序...

等待X秒(s)并再次尝试向api.myserver.com请求(您会建议多少次尝试以及在什么时间间隔？)

我会在这里设置一些间隔(在几十到几百毫秒内,取决于你的正常api性能),以避免意外的请求泛滥.当我没有充分的理由时,我不想建议一个确切的数字.

我的经验是,优化此值不太可能对您的用户产生明显的差异,因为请求通常需要数百毫秒才能失败,用户只愿意等待几千毫秒,因此在此期间发出1或5或10个请求并没有真正改变最终的结果.如果您能够为用户设置不同的期望,那么您的结果可能会有所不同.

尝试ping一些其他服务器(即google.com),看看我们是否可以访问api.myserver.com以外的资源.如果我们能成功ping google.com,那么我们就知道我们的互联网正在运行,所以我们再次尝试ping api .myserver.com

我不认为这是真的,我也不认为向第三方提出额外请求将帮助您对何时尝试访问您自己的系统做出有用的预测.这似乎是构建和维护的额外工作,并且可能成为误导结果的来源而不是有价值的信息.在什么情况下,您认为这会为您的应用或其用户提供有用的信息？

也许不是你正在寻找的答案,希望它仍然有用.

免责声明:我的经验偏向于使用相当简单的REST或RPC样式网络请求的应用程序.如果您正在处理一个需要流数据,P2P连接或其他一些情况的问题,那么就不要从这些假设开始.

(1)这里有一个结尾注意,因为我经常将它视为失败的根源:这些请求应该是幂等的.是的,即使是创建新资源,检查购物车等的POST.当您无法安全地重复请求时,您最终会看到请求已完成但客户端从未收到确认的情况,因此看起来像是失败.通过相同请求的重试(自动或用户触发)恢复比检测重复请求并从中恢复要容易得多.