如何确定何时更新 deviceToken 以获取推送通知/如何获取？答案

【问题标题】：How to determine when to update deviceToken for push notifications / how to get it?如何确定何时更新 deviceToken 以获取推送通知/如何获取？
【发布时间】：2017-03-27 18:11:16
【问题描述】：

在我的应用程序使用过程中，我遇到了各种推送通知问题，这些问题似乎可以通过卸载来解决。我相信我已将其范围缩小到过期的 deviceTokens。

阅读Apple's Push notification documentation，我发现了这个：

注册成功但未收到通知

。 . .

您的应用可能向您的提供商发送了错误的设备令牌。您的应用应始终通过注册来请求设备令牌每次启动推送服务。不要存储设备令牌从您的应用程序中提取并尝试重用它，因为令牌可以更改。您的然后，提供者应该将相同的令牌传递给推送服务。

他们建议在每次启动应用程序时进行注册。他们还建议推送通知的最佳做法是不要这样做，因为用户不喜欢在看到您的应用程序之前就被访问请求轰炸。因此，仅将注册调用放入应用程序委托并不是最佳选择。但是，我没有看到有关 deviceToken 何时过期或如何查看它是否已过期的更多信息。

我能找到的最接近的东西是this documentationUIApplication 的实例方法isRegisteredForRemoteNotifications：

返回如果应用注册了远程通知，则返回 YES，并且收到其设备令牌，如果没有注册，则为 NO，已失败，或被用户拒绝。

我的理解是，这是用来检查用户是否启用推送通知服务的方法。我了解特定通知类型的权限可以全部关闭，如果用户允许推送通知，这仍然可能是真的。但措辞看起来要求应用程序必须使用当前的 deviceToken 进行注册。这是否意味着我可以打电话给

[[UIApplication currentApplication] isRegisteredForRemoteNotifications]

在 appDelegate 中，如果为真，注册远程通知以更新我服务器上的 deviceToken 并确保我的推送通知不会过期？或者，这个函数是否会遇到与我目前相同的情况，即最终 deviceToken 将过期并且此方法将开始返回 false 而不是 true，即使用户已允许推送通知？

tl;dr - Apple 表示 deviceTokens 最终会因推送通知而过期。他们建议在每次应用启动时进行注册。我不想用那个警报轰炸新用户。如何确保只有已接受推送通知的用户才能重新注册？

【问题讨论】：

标签： ios objective-c notifications remote-notifications

【解决方案1】：

警报只会显示一次。

如果用户之前允许通知，您的代码将获得新令牌，而无需用户进行任何交互（或 UI 通知）。

【讨论】：

在 application didRegisterForRemoteNotifications 方法中，我处理更新服务器上的 deviceToken，但这似乎不起作用，因为我有很多用户使用过时的令牌。仅显示一次的警报就是为什么我不想在启动过程中直接抛出注册方法。我想在我的应用程序中等到适当的时间，这样我就可以显示一条相关消息，包括我们为什么要使用推送通知，并在官方 Apple 提示之前使用我们自己的提示，这样我们就不会浪费它了会说不。这是 Apple 推荐的最佳做法。
话虽如此，您是说设备仍会知道令牌已更新，所以如果我检查 isRegisteredForRemoteNotifications 布尔值，这是真的，我应该准备好了吗？
据我了解，是的...isRegisteredForRemoteNotifications 应该返回正确的值。所以你可以等到准备好提示，检查isRegisteredForRemoteNotifications的值...如果是TRUE，调用registerForRemoteNotifications静默检查/获取新的Token...如果是FALSE，显示您自己的提示，然后根据需要调用registerForRemoteNotifications（或不调用）。
@DonMag 更重要的是，当设备令牌更改时，用户主题订阅会发生什么？当我检测到令牌更改时，我是否必须从他们订阅的所有主题中取消订阅用户原始令牌，然后使用新令牌为所有相同主题重新注册用户？或者这是在后台以某种方式自动管理的 - FCM 自动删除坏令牌并为所有用户订阅的主题重新分配新令牌？

【解决方案2】：

好的，最佳实践如下，我们没有失败地遵循它

始终注册以在应用启动时或在合适的 AppDelegate 生命周期方法中使用以下代码进行推送

[[UIApplication sharedApplication] registerUserNotificationSettings:  [UIUserNotificationSettings settingsForTypes:(UIUserNotificationTypeAlert | UIUserNotificationTypeBadge | UIUserNotificationTypeSound) categories:nil]];

[[UIApplication sharedApplication] registerForRemoteNotifications];

Push 的代理如果注册成功会被调用 deviceToken
```
- (void)application:(UIApplication*)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData*)deviceToken
```
如果 deviceToken 总是有变化，上面的委托将被调用。因此，每当您获得 deviceToken 时，请在服务器中更新它。
如果您在沙盒或生产模式下运行，请确保在服务器中选择正确的模式，丢弃来自模拟器的值，它们通常会失败并阻止服务一段时间。

您可以随时使用您的 pem 文件和设备令牌检查 Push 是否在使用 this online service。

希望对你有帮助。

干杯。

【讨论】：

感谢@iphonic，但我不想在发布时为新用户爆破注册。 Apple 不建议这样做。他们建议自己将其包装在您自己的提示中，解释您为什么要使用推送通知，并在相关时间显示。然后，只有在用户有兴趣接受时才显示官方提示，这样就不会浪费系统提示。这就是为什么我想要一种仅在用户已经接受时才调用 register 方法的原因，并且我正在寻找确认 isRegisteredForRemoteNotifications 在用户接受时将始终为 Yes，
@JakeT。在用户允许推送之前，您不需要在启动时执行此操作，并且一旦用户允许推送，警报将不会提示它在您第二次调用注册时静默生成设备令牌，并且您的服务器调用仅获取设备令牌时触发。
这正是我想要弄清楚的。如果我在用户接受之前调用 registerForRemoteNotifications，它将提示他们，因此 1) 在您的列表中将触发该提示，我不想这样做。我只想为已经接受的用户致电registerForRemoteNotifications，并努力确保我概述的方法是可靠的，并正在寻找确认。
@JakeT。无论您接受还是拒绝，推送提示只会出现一次，但是如果您拒绝，用户可以从应用程序的设备设置中启用它。但是，即使需要，您也不能跳过提示。多次调用 register 不会触发多次提示。
是的。同样，这就是为什么我不想按照您的建议在启动时在应用程序委托内抛出一个全面的注册调用。但是，我想确保我的服务器上有一个更新的 deviceToken，而目前只通过一次调用 registerForRemoteNotifications 就不会发生这种情况。所以我只想为已经接受的用户再次调用它，这样我可以确保我的服务器上有一个最新的令牌。问题是关于可靠地检查他们是否已接受通知，以便我知道再次调用 register 方法。