处理来自后台的网络呼叫。是苹果允许的吗?

时间:2013-02-28 02:16:13

标签: ios objective-c

我们正在使用类似groupon的应用,当用户进入优惠范围时,会向用户显示提醒。

即使应用处于后台,客户也会坚持发出警报。

由于系统的体系结构,应用程序会定期获取客户端的位置,并检查服务器是否有任何新警报。如果是,则应用程序在本地数据库中执行一些处理并显示通知。

由于服务器的更改无法用于此项目,因此无法使用APN。

我的问题是Apple是否会在AppleStore中接受它,因为我已经阅读了不同的意见,并且Apple不鼓励将其用于iOS Developer Library的摘录中

http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html

  

在唤醒时,您的应用会被置于后台,并且只需要少量时间来处理位置数据。由于您的应用程序位于后台,因此应该执行最少的工作并避免任何可能阻止其在分配的时间到期之前返回的任务(例如查询网络)。如果没有,您的应用可能会被终止

由于

2 个答案:

答案 0 :(得分:2)

您的应用多久会从用户那里获得一个位置?根据Apple的Background Execution and Multitasking,如果您定期获取位置更新(我认为不到10分钟),如果您将location添加到{{1},您的应用仍然可以在后台处理在你的UIBackgroundModes中。使用这些info.plist坐标,您可以处理您的Web服务请求。

我个人没有这样做过,所以我无法确定Apple是否拒绝你的应用程序。但是,如果所有内容都符合Apple设定的指南和要求,我不明白他们拒绝您的应用的原因。

修改

来自Apple doc:

  

为用户提供连续位置更新的应用程序(甚至   在后台时)可以启用后台位置服务   包括UIBackgroundModes键(具有位置值)   Info.plist文件。在UIBackgroundModes中包含此值   key不会阻止系统暂停应用程序,但确实如此   告诉系统它应该在有新的时候唤醒应用程序   要传递的位置数据。因此,此键有效地让应用程序运行   在后台处理位置更新。

我猜即使应用程序被暂停,只要有新的位置数据要传递,它就会被唤醒。

答案 1 :(得分:1)

我认为您应该重新考虑您的申请方法。听起来你已经决定构建一组功能,这些功能不一定非常适合应用程序运行的设备的特性,或者非常适合这些功能。

您写道“应用程序每n分钟获取一次位置”,但这不是iOS位置服务的工作方式。当您的应用程序在前台运行时,偶尔查询当前位置的位置服务是一种很好的方法,但暂停或终止后这不是一个选项。相反,您需要以某种准确度订阅位置事件,并在设备位置发生变化时通知您的应用。对于您收到这些事件的时间表无法保证,这取决于您请求的准确性和设备移动的速度。

此外,获取位置是一项昂贵的操作,并且可能会快速耗尽设备的电池电量。在一两个小时内通过用户可用的电池电量进行刻录是快速卸载应用程序的一种非常好的方法。在可能的情况下,您应该使用重要的位置更改服务,以最低的功耗获得低精度的位置更新。如果您需要更高的精度,请考虑对定义的区域使用边界交叉事件,或者至少尽可能降低您所要求的准确度。

完成所有这些操作后,您仍然需要在有限的时间内工作,您的应用必须在位置更新启动后运行。这可能不足以进行到服务器的往返。如果网络连接已经处于活动状态且设备碰巧具有低延迟,您可能会在某些时候得到响应,但我希望看到应用程序经常终止该应用程序。当发生这种情况时,我不知道您将继续接收位置更新,否则可能会重新启动应用程序。

除了下载警报列表并在本地显示它们之外,更好的解决方案可能是在您看到重要的位置更改时尝试通过UDP将当前位置发送到服务器。这样您就可以在不等待响应的情况下发出网络请求。只有部分请求仍然会成功,但至少您的应用程序不会被终止。然后,您可以处理在服务器上收到的位置,并在适当时发送推送通知。

我意识到您似乎无法进行服务器端更改。在这种情况下,您可以做的最好的事情是在应用程序运行时预先获取附近区域的警报(如果您设法在后台完成往返)。这样,您可以将位置更新与该列表进行比较,而无需在每个位置更新时触发网络请求。不幸的是,听起来你可能会陷入困境,但目前的限制条件下没有可靠的解决方案。