“状态改变"APNS 失败时的应用架构 [英] App architecture when 'state changing' APNS fails

问题描述

我看到了几个关于这个主题的问题.但都只是简单地说你只需要从其他方式中恢复过来.但是没有人解释其他含义是什么！我在 SO 上找不到答案.这也是对this问题的评论的跟进.

I've seen several questions on this topic. But all simply say you just have to recover from other means. But none explain what the other means are! I couldn't find an answer on SO. This is also a follow up from the comments of this question.

假设我正在开发 Uber 应用.司机需要知道乘客的位置.

Let's say I'm working on a Uber app. Drivers need to know passenger locations.

一位乘客为 123 XYZStreet 设置了上车地点.

A passenger sets a pickup location for 123 XYZStreet.

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

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)并且还有 include "alert" : "Pickup has been cancelled. Don't go there' 所以司机也会在视觉上得到通知.显然点击通知不是管理更新的内容.content-available 设置为 1 将管理.

Send a notification that has content-available:1 so I can update the app as soon as the notification arrives, and in the didReceiveNotification I call GET(PassengerInfoModel) and also have include "alert" : "Pickup has been canceled. Don't go there' So the driver would also be visually informed. Obviously tapping on the notification is not what manages the updates. The content-available being set to 1 will manage that.

但是这样做，当通知到达失败时会发生什么 - 完全?那么最新的 GET(PassengerInfoModel) 不会发生.作为一种解决方案，我听说过 HEAD 请求:

But doing that, still what happens when the arrival of that notification fails—completely? Well then the latest GET(PassengerInfoModel) won't happen. As a solution I've heard of a HEAD request:

HEAD 方法与 GET 相同，只是服务器不得在响应中返回消息正文.包含的元信息在响应 HEAD 请求的 HTTP 标头中应该是相同的到响应 GET 请求而发送的信息.这个方法可以用于获取隐含的实体的元信息请求而不传输实体主体本身.这种方法是通常用于测试超文本链接的有效性、可访问性、和最近的修改.

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的completion Handler成功的情况下，我们是否发出GET请求?

Not sure what happens if using a HEAD request we figured out that there was an update!? Do we then make a GET request in the success case of the HEAD's completion Handler?

问题 1 我们应该如何处理 HEAD 请求响应?(我猜要使服务器能够路由 HEAD 请求，必须进行一些更改，但我们假设这超出了问题的范围).

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).

问题 2 我们必须多久执行一次此请求?基于此评论，一种解决方案可能是在viewDidAppear 例如每 2 分钟发出一个 HEAD 请求.这是一个好主意吗?

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?

Question3 现在假设我们做了那个 HEAD 请求，但是 GET(PassengerInfoModel) 也是从 2 个其他场景/视图控制器请求的.服务器无法区分不同的场景/视图控制器.我猜一个解决方案是通过单例 NetworkHandler 管理我们所有应用程序的网络请求.这是一个好主意吗?

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?

我知道这个问题很宽泛，但我认为这个问题需要整体解决

推荐答案

Question1 我们应该如何处理 HEAD 请求响应?(我猜要使服务器能够路由 HEAD 请求，必须进行一些更改，但我们假设这超出了问题的范围).

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 响应的空主体，或者如果有任何更改，则返回实际的新内容.

You probably don't need to deal with HEAD requests. Using Etags is a standard mechanism which lets you make a GET request and the server can just return an empty body with 304 response if nothing has changed, or the actual new content if something has.

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

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 的 Reachability 代码来检测您何时可以或不可以与您的服务器通话.

I think this is reasonable, especially if you want to inform your user when you are unable to make that request successfully. You might also consider using Apple's Reachability code to detect when you can or cannot talk to your server.

Question3 现在假设我们做了那个 HEAD 请求，但是 GET(PassengerInfoModel) 也是从其他 2 个场景/viewControllers 请求的.服务器无法区分不同的场景/视图控制器.我猜一个解决方案是通过单例 NetworkHandler 管理我们所有应用程序的网络请求.这是个好主意吗?

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?

是的，我认为有一个单例是合理的，但我不确定为什么服务器会关心哪个视图控制器正在发出请求.就像他们不能只请求不同的网址吗?

Yes, I think having a singleton is reasonable, though I'm not sure why the server cares what view controller is making the request. Like can't they just request different urls?

这篇关于“状态改变"APNS 失败时的应用架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！