“状态更改”APNS失败时的应用程序架构 [英] App architecture when 'state changing' APNS fails

问题描述

我在这个主题上看到了几个问题。但所有人都只是说你必须从其他方式中恢复过来。但没有人解释其他方法是什么！我无法找到答案。这也是对此问题的评论的后续跟进。

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

乘客为 123设置一个取货地点XYZStreet 。

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

首先想到的是：

发送通知 content-available：1 所以我可以在收到通知后立即更新应用程序，并在didReceiveNotification我调用 GET（PassengerInfoModel）并且还包含alert：取消已取消。不要去那里'因此，驱动程序也会在视觉上得到通知。显然，点击通知并不是管理更新的内容。 content-available 设置为 1 将管理它。

但是这样做，当通知的到达失败时会发生什么 - 完全？那么最新的 GET（PassengerInfoModel）将不会发生。作为解决方案，我听说过 HEAD 请求：

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

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

问题1 我们应该如何处理HEAD请求响应？ （我猜测服务器能够路由 HEAD 请求，必须有一些更改，但我们只是假设它超出了问题的范围。） / p>

问题2 我们多久要做一次这样的请求？基于此评论，一个解决方案可能是设置重复计时器 viewDidAppear 例如每2分钟发一次 HEAD 请求。这是一个好主意吗？

问题3 现在让我们说我们做了那个HEAD请求，但 GET（PassengerInfoModel）还要求来自其他2个场景/ viewControllers。服务器无法区分不同的场景/ viewControllers。我猜测解决方案是通过单一的NetworkHandler管理我们所有应用程序的网络请求。这是一个好主意吗？

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

解决方案

Question1我们应该如何处理HEAD请求响应？ （我猜测服务器能够路由HEAD请求，必须有一些更改，但我们只是假设它超出了问题的范围）。

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

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

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

问题3现在让我们说我们做了那个HEAD请求，但是从其他2个场景/ viewControllers请求GET（PassengerInfoModel）。服务器无法区分不同的场景/ viewControllers。我猜测解决方案是通过单一的NetworkHandler管理我们所有应用程序的网络请求。这是一个好主意吗？

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

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.

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

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.

The first thought that comes to mind is:

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.

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:

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.

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?

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

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 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?

I understand that this question is broad, but believe the issue needs to be addressed as a whole

解决方案

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

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.

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?

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 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屋！