ios - 'state changing' APNS 失败时的应用架构

Question

我已经看到几个关于这个主题的问题。但所有人都简单地说，你只需要通过其他方式恢复。但没有人解释其他手段是什么!我找不到关于 SO 的答案。这也是 this 评论的跟进问题。

假设我正在开发一款优步应用。司机需要知道乘客的位置。

A passenger sets a pickup location for 123 XYZStreet.

2 minutes later she decides to cancel the entire pickup. So now I need to inform the driver. This is an important state changing update.

首先想到的是:

发送包含 content-available:1 的通知所以我可以在通知到达后立即更新应用程序，并在 didReceiveNotification 中调用 GET(PassengerInfoModel)并且还包括"alert" : "Pickup has been canceled. Don't go there'因此，驾驶员也会从视觉上得到通知。显然，点击通知并不是管理更新的方式。 content-available被设置为 1将管理它。

但是这样做，当通知到达失败时仍然会发生什么——完全？那么最新的GET(PassengerInfoModel)不会发生。作为解决方案，我听说过 HEAD要求:

The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.

不确定如果使用 HEAD 请求我们发现有更新会发生什么!？那么我们是否在 HEAD 的完成处理程序的成功案例中发出 GET 请求？

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

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

问题 3 现在假设我们执行了 HEAD 请求，但是 GET(PassengerInfoModel)也从其他 2 个场景/ View Controller 请求。服务器无法区分不同的场景/ View Controller 。我猜一个解决方案是让我们所有应用程序的网络请求都通过单例 NetworkHandler 进行管理。这是一个好主意吗？

我知道这个问题很宽泛，但我相信这个问题需要作为一个整体来解决

Answer 1

Question1 How should we handle the HEAD request response? (I'm guessing that for the server to be able to route HEAD requests, there must be some changes, but let's just assume that's outside the scope of the question).

您可能不需要处理 HEAD 请求。使用 Etags 是一种标准机制，它允许您发出 GET 请求，如果没有任何变化，服务器可以返回一个带有 304 响应的空主体，或者如果有变化，则返回实际的新内容。

Question2 How often do we have to do this request? Based on this comment one solution could be to set a repeating timer in the viewDidAppear e.g. make a HEAD request every 2 minutes. Is that a good idea?

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

Question3 Now let's say we did that HEAD request, but the GET(PassengerInfoModel) is requested from 2 other scenes/viewControllers as well. The server can't differentiate between the different scenes/viewControllers. I'm guessing a solution would be have all our app's network requests managed through a singleton NetworkHandler. Is that a good idea?

是的，我认为有一个单例是合理的，但我不确定为什么服务器关心哪个 View Controller 正在发出请求。比如他们不能只请求不同的 url 吗？