【问题标题】:Long running requests on iOSiOS 上长时间运行的请求
【发布时间】:2016-06-07 10:03:00
【问题描述】:

我正在开发一个应用程序,它对服务器的请求最终可能会持续相当长的一段时间,想想 10 到 30 分钟。我认为可以肯定地说,毫无疑问,用户将在请求执行期间进入后台。

我已经让这个使用后台任务正常工作,但是因为它们只给你 3 分钟,所以请求会很快;在我的用例中不允许这样做。

我已经阅读了后台模式并可能使用下载和上传任务,但我的用例不符合其中任何一个。这是一个大型 JSON 请求/响应。

我想到的可能是将 JSON 保存到文件并发送文件本身。这应该符合 NSURLSession 支持的后台下载。

有人知道另一种方法吗?所以我不必更改请求/响应结构。

提前致谢!

【问题讨论】:

  • 你到底在做什么,它需要 30 分钟下载 Watchdog 不会让这种情况发生,一旦应用程序进入后台,所以我建议你改变你的数据库和结构或响应。
  • 30分钟的事情可以应用于上传,下载通常持续更短。上传时间可能会很长,因为它是一个离线应用程序,用户可以创建需要同步到服务器的新内容 - 有时可持续长达 30 分钟。
  • 所以你应该把它拆开并发送更小的部件 - 这是一个移动设备,你的工作是以适当和同情的方式设计它......
  • 我可能在这里遗漏了一些东西,但是在整个过程的长度上不会将大请求分成更小的、单独的请求吗?我假设每个进程总共有 3 分钟 - 每个后台任务是 3 分钟吗?
  • 也许会增加开销,但会让整个过程更易于管理。不要依赖于设定的后台时间,操作系统可以选择你获得多少。

标签: ios networking background nsurlsession long-running-processes


【解决方案1】:

这种情况应该按照发送“作业”请求的方式处理,该请求基本上会立即返回一个令牌并简单地安排/启动服务器上的活动。然后,应用可以请求该令牌的结果,以确定作业是否完成并获取数据。

您不一定会检查后台,或者无论如何也不会定期检查 - 您会检查应用程序何时打开或可能使用后台刷新。

更好的方法是让服务器向用户/设备发送推送通知,可能是内容可用通知,因此应用在知道数据准备就绪之前不需要发出请求。

【讨论】:

  • 我真的很喜欢这个主意,谢谢!目前,我们有一些限制阻止我们实施这样的事情,但似乎这个建议会一直伴随着我们,可能会在某个地方实现。
猜你喜欢
  • 2011-01-12
  • 2012-02-16
  • 2011-01-23
  • 1970-01-01
  • 2017-10-05
  • 1970-01-01
  • 1970-01-01
  • 2017-02-06
  • 1970-01-01
相关资源
最近更新 更多