iOS Twilio 可编程聊天推送通知

Question

我已经集成了 Twilio Programmable Chat，但我遇到了一些关于推送通知的问题，我正在尝试解决这些问题。

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

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

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

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

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

Answer 1

我是 Programmable Chat iOS SDK 团队的一员，希望对您的上述一些问题有所帮助。

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

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

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

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

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

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

我们的通知团队正在调查利用 Apple 的提供者身份验证令牌而不是证书，但我们目前尚无具体日期可透露何时提供支持。

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

谢谢你， 兰迪