iOS Twilio 可编程聊天推送通知

Question

我已经集成了 Twilio Programmable Chat，但我在尝试解决推送通知方面遇到了一些问题。

我正在查看我的代码与 https://www.twilio.com/docs/chat/ios/push-notifications-ios 中提供的示例

我注意到的第一件事是在 User Notification Setttings部分(超出部分名称中的额外 t)，不推荐使用的方法 [self.chatClient registerWithToken:nil];从 V1.0 开始使用。在 V 2.2.2 的当前文档中，我们有 - (void)registerWithNotificationToken:(nonnull NSData *)token completion:(nullable TCHCompletion)completion ，它指定 nonnull NSData*对于 token 参数。所以，我们不能再通过 nil 了。我们现在应该为 if(notificationSettings.types == UIUserNotificationTypeNone) 做些什么吗？ - (void)application:(UIApplication *)application didRegisterUserNotificationSettings:(UIUserNotificationSettings *)notificationSettings 内的案例我们的应用程序委托(delegate)？ (上面提到的教程部分提供了示例)现在我只是跳过这一步，并确保我的 updatedPushToken属性设置为零。

我也想知道 - (void)handleNotification:(nonnull NSDictionary *)notification completion:(nullable TCHCompletion)completion 是什么TwilioChatClient 上的方法实际上确实如此。我看到 delegate有 5 种不同的通知方法。这个handleNotification方法只是调用适当的委托(delegate)方法？我自己没有使用这种方法，我现在只是显示带有通知消息的警报 View ，所以我想知道是否还有我错过的其他好处，甚至潜在的错误我'我通过不使用 TwilioChatClient 来介绍处理程序。

我想知道的最后一个也是最重要的事情，在本教程中没有涉及，是如何在用户退出并稍后重新登录时处理注册推送通知。是deviceToken从 - (void)application:(UIApplication*)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData*)deviceToken 返回意味着存储在比单例属性(property)更持久的地方？我可以通过 Twilio 或我不知道的 iOS 方法在其他地方重新获得它吗？似乎一旦我将用户注销，当他们登录到不同甚至相同的用户时，我就无法再次收到通知。我看到有一个deregisterWithNotificationToken:completion:方法，但由于它需要一个非空 token ，如果我的应用程序尚未关闭，我只能根据教程调用它。保留此 token 的推荐方法是什么？ NSUserDefaults？我服务器数据库的某个地方？

编辑:
实际上，我还有一个问题。如果我取消选中已读状态框，然后在聊天实例配置中重新选中它，这会重置每个人的未读 channel 数吗？我的消费水平/阅读状态的设置不正确，而且我还有很多对用户隐藏的 channel ，即使它们在其中......所以，启用角标(Badge)计数后，用户可能会看到非常高的数字他们收到一条消息的时间，并且无法将这个数字完全减少到 0，即使他们打开了他们当前可以查看的每个 channel 。我宁愿重设这个数字。正如我在评论中提到的，我不喜欢我唯一的选项是没有通知角标(Badge)，或者通知角标(Badge)明确设置为具有未读消息的 channel 数量......我最喜欢一个选项来增加角标(Badge)，并且，除此之外，不包含特定数字的通知。我希望人们看到他们有聊天，因为这非常重要，但我不希望显示这些高数字，并且这些未读消息不会永久保持相关性。只有新的未读消息是相关的。

Answer 1

我是 Programmable Chat iOS SDK 团队的一员，希望能帮助您解决上面的一些问题。

对 registerWithToken: 的引用以及使用 nil 调用它的指令如您所述，不推荐使用不存在/已知 token 时的参数。我们将更新文档和教程以反射(reflect)这一点 - 谢谢!

今天，handleNotification:completion:是可选的。它的目的是解析userInfo推送有效负载的一部分，并提供您提到的回调以帮助您的用户了解发生的事件。今天跳过这一步并没有什么害处，但在 future ，这些回调可能会用于提供更多关于在可编程聊天内传递通知的反馈，因此您可能希望在 future 回顾实现这一点。

当您的用户注销时，建议您调用 deregisterWithNotificationToken:completion:方法来确保他们的隐私。如果您不取消注册与他们的身份相关联的 token ，他们将继续接收该身份的通知，即使他们以后在该设备上使用具有不同身份的访问 token 也是如此。通过我们的 REST API 以编程方式管理通知绑定(bind)的机制在我们的路线图中，但我目前没有发布日期可以分享。

正如 Apple 的推送通知文档中所述，最好不要缓存设备 token 或假设推送设备 token 永远不会更改，因为此 token 可能会随着将来的注册而更改。同样，建议您在收到 Apple 的设备 token 时将 Apple 提供的 token 传递给 Programmable Chat，以确保我们拥有最新的 token 来访问您的用户设备。

APNS 传递的角标(Badge)计数报告给定用户的未读消息的 channel 数。有几个原因可以让您想到为什么您可能会在这里看到过时的结果。在您的客户中，您是否调用 setLastConsumedMessageIndex:completion:在 TCHMessages (或同一类中的相关方法之一)更新后端的未读状态？完成此操作后，您应该会在短时间内看到更新的推送，其中包含更新的角标(Badge)计数。另一种可能性是，如果您确实在您正在测试的 channel 上还有其他身份的过时绑定(bind)，但尚未注销/注销。请注意，当应用程序在前台时，您有责任自己更新角标(Badge)计数 - iOS 不会这样做。这是您可能希望确保您调用 handleNotification:completion: 的地方。因为如果我们收到角标(Badge)更新，我们会调用它。您还可以查看有效负载并根据需要直接在 UIApplication 上的接收委托(delegate)中调用以更新角标(Badge)计数。测试这一点的一种方法是建立一个新 channel 并使用它测试消息，并在适当的时候更新消费范围。您可以在 consumption horizon documentation 中找到更多信息.下面，您可以找到将响应中的角标(Badge)计数更新为可编程聊天的委托(delegate)方法的示例:

- (void)chatClient:(TwilioChatClient *)client notificationUpdatedBadgeCount:(NSUInteger)badgeCount {
    [[UIApplication sharedApplication] setApplicationIconBadgeNumber:badgeCount];
}

利用 Apple 的提供者身份验证 token 而不是证书是我们的通知团队正在调查的事情，但我们目前还没有日期可以分享何时提供支持。

如果我能提供进一步的帮助，或者我错过了您的任何问题，请告诉我!

谢谢，
兰迪