多用户应用程序中推送通知的最佳实践？答案

【问题标题】：Best practices for push notifications in multi user applications?多用户应用程序中推送通知的最佳实践？
【发布时间】：2012-09-11 06:50:00
【问题描述】：

我正在开发一种推送架构，该架构需要支持允许多用户使用的应用程序。这意味着多个用户可以使用他们的凭据登录应用程序。我遇到的问题是，如果用户 A 允许推送通知，然后注销，然后用户 B 登录并开始获取用户 A 的推送通知，该怎么办？

处理此类事情的最佳做法是什么？我的一个想法是你可以记住最后一个登录的用户，并且只向“登录”用户显示推送通知。您必须在消息有效负载中发送某种用户上下文，以便可以根据登录用户对其进行检查。然而，这感觉有点时髦。

还有其他人遇到过这个吗？这似乎是一个非常相关的问题，尤其是对于家庭倾向于共享设备的平板电脑。

【问题讨论】：

虽然您的应用程序可以检查是否通知预期收件人和当前登录用户之间的匹配；当应用程序在后台或根本没有运行时，先前注册令牌的通知仍将到达手机/平板电脑，并根据设置显示为横幅或警报弹出窗口。我认为最终您的服务器必须知道用户何时注销（明确地，或在超时后，或其他人登录时），并且在该用户再次登录之前不发送通知。

标签： push-notification push apple-push-notifications google-cloud-messaging

【解决方案1】：

我们通过向 APSN 注册设备、获取设备令牌并通过 ws 将其发送到我们的服务器来实现这一点。

在服务器端，设备令牌仅与最后登录的用户相关联。

New app
User A (first ever user) uses IPAD A
Register with APSN, get token
Send token to our servers through ws
Search for token in db, token is new, store it
assign token to USER A

Next user logs into app
Register with APSN, get token
Send token to our servers through ws
Search for token in db, token exists already
Remove connection to USER A
assign token to USER B

SEND Notification to device WITH USERNAME
if username is logged in show it - else dont

仍然不完美，因为它首先发送到主屏幕，所以所有用户

【讨论】：

【解决方案2】：

我认为您的建议在多用户应用中是可以接受的。在客户端实现这一点比在服务器端简单得多。缺点是浪费了额外的带宽来发送不需要的通知。但绝大多数使用可能是单用户，所以这可能无关紧要。

另一种方法是跟踪您服务器上的登录用户及其当前的 reg_id。这可能更复杂，因为 A 可以登录多个设备，然后从设备 1 注销，B 登录设备 1，等等，您的服务器必须跟踪所有这些。所以可能是另一个表来跟踪“登录用户”与“注册 ID”之间的关系。

如果您讨厌发送不需要的通知，请使用服务器路由。如果您重视 Keep-It-Simple 原则，请选择客户路线。

【讨论】：

很好的分析 - 感谢您分享您的想法。在这里给我一些好东西供我考虑。

【解决方案3】：

假设您应用的用户可以在多台设备上登录。

我们必须在服务器端制作两个 API：

    func setUserDeviceNotifyToken(userId: Int, deviceToken: String) {}
    func removeUserDeviceNotifyToken(userId: Int, deviceToken: String {}

在您的应用端，您必须在每次登录时调用 setUserDeviceNotifyToken API，并在每次注销时调用 removeUserDeviceNotifyToken。

在服务器端，您可以使用其deviceNotificationToken 跟踪每个用户并发送正确设备的通知。

注意：如果您的服务不支持一个用户的多设备登录，您可以通过一个updateUserDeviceNotifyToken 处理它并传递null 以删除用户的设备令牌。

注意 2：在调用removeUserDeviceNotifyToken API 之前不要让用户注销。

【讨论】：