“状态更改” APNS失败时的应用架构

Question

我已经看到了有关此主题的几个问题。但是所有人都只是说，您只需要从其他方法中恢复过来即可。但是没有人解释其他的意思！我找不到关于SO的答案。这也是该问题评论的后续内容。

假设我正在开发Uber应用。驾驶员需要知道乘客的位置。

一名乘客为设置接送地点123 XYZStreet。

2分钟后，她决定取消整个接送。所以现在我需要通知司机。 这是重要的状态更改更新。

首先想到的是：

发送一个包含通知的通知，`content-

available:1 以便我可以在通知到达后立即更新该应用程序，并且在didReceiveNotification中我调用了该通知，GET(PassengerInfoModel) 并且还包含include。“alert”

“Pickup has been canceled. Don’t go
there’ 因此，驱动程序也将在视觉上得到通知。显然，点击通知不是管理更新的因素。content-available 被设置为1`将对此进行管理。

但是这样做，当通知完全 失败
时，仍然会发生什么呢？那么最新的GET(PassengerInfoModel)将不会发生。作为解决方案，我听说了一个HEAD请求：

HEAD方法与GET相同，除了服务器 在响应中 不得 返回消息正文
。响应HEAD请求的HTTP标头中包含的元信息应该与响应GET请求发送的信息相同。此方法可用于获取有关请求所隐含的实体的元信息，而无需转移实体主体本身。此方法通常用于测试超文本链接的有效性，可访问性和
最新修改 。

不知道如果使用HEAD请求我们发现有更新！会发生什么？然后，在HEAD的完成处理程序成功的情况下，我们是否发出GET请求？

Question1 我们应该如何处理HEAD请求响应？（我猜测服务器要能够路由HEAD请求，必须进行一些更改，但是我们假设这不在问题范围内）。

问题2 我们必须多久执行一次此请求？基于此评论，一种解决方案可以是在viewDidAppear例如HEAD每2分钟发出一次请求中设置一个重复计时器。这是一个好主意吗？

Question3 现在，我们执行了HEAD请求，但是GET(PassengerInfoModel)另外2个场景/
viewControllers也请求了HEAD 。服务器无法区分不同的场景/
viewController。我猜测一个解决方案是通过单例NetworkHandler管理我们所有应用程序的网络请求。这是一个好主意吗？

我知道这个问题是广泛的，但是认为这个问题需要从整体上解决

Answer 1

Question1我们应该如何处理HEAD请求响应？（我猜测服务器要能够路由HEAD请求，必须进行一些更改，但是我们假设这不在问题范围内）。

您可能不需要处理HEAD请求。使用Etags是一种标准机制，它使您可以发出GET请求，并且如果没有任何更改，则服务器可以返回一个带有304响应的空正文，如果有任何更改，则可以返回实际的新内容。

问题2我们必须多久执行一次此请求？基于此注释，一种解决方案是在viewDidAppear中设置重复计时器，例如每2分钟发出HEAD请求。这是一个好主意吗？

我认为这是合理的，尤其是当您想在无法成功发出请求时通知用户时。您可能还考虑使用Apple的可达性代码来检测何时可以与服务器通信。

Question3现在让我们说我们执行了HEAD请求，但是另外2个场景/
viewControllers也请求了GET（PassengerInfoModel）。服务器无法区分不同的场景/
viewController。我猜测一个解决方案是通过单例NetworkHandler管理我们所有应用程序的网络请求。这是一个好主意吗？

是的，我认为拥有一个单身人士是合理的，尽管我不确定为什么服务器会关心哪个视图控制器正在发出请求。就像他们不能只是要求不同的网址吗？