iOS Twilio 可编程聊天推送通知
iOS Twilio Programmable Chat Push Notifications
我已经集成了 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。
我还想知道 - (void)handleNotification:(nonnull NSDictionary *)notification completion:(nullable TCHCompletion)completion method on the TwilioChatClient actually does. I see that the delegate 有 5 种不同的通知方法。这个 handleNotification 方法是否只是调用适当的委托方法？我自己并没有使用这种方法，我现在只是显示一个带有通知消息的警报视图，所以我想知道是否还有我遗漏的额外好处，或者我什至是潜在的错误'通过不使用 TwilioChatClient 处理程序进行介绍。
我想知道的最后也是最重要的事情是如何在用户注销并稍后重新登录时处理推送通知的注册，这在本教程中没有涉及。从 - (void)application:(UIApplication*)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData*)deviceToken 返回的 deviceToken 是否意味着存储在比单例的 属性 更持久的地方？我可以通过 Twilio 或我不知道的 iOS 方法在其他地方重新获得它吗？似乎一旦我将用户注销，当他们登录到不同甚至相同的用户时，我就无法再次收到通知。我看到有一个 deregisterWithNotificationToken:completion: 方法，但由于它需要一个非空令牌，所以我只能在我的应用程序尚未关闭的情况下根据教程调用它。保留此令牌的推荐方法是什么？ NS用户默认值？在我服务器数据库的某处？
编辑：
实际上，我还有一个问题。如果我取消选中已读状态框，然后在聊天实例配置上重新选中它，是否会重置每个人的未读频道数？我的消费范围/阅读状态设置不当，而且我还有很多频道对用户隐藏，即使它们在其中......所以，启用徽章计数后，用户可能会看到非常高的数字当他们收到一条消息时，即使他们打开当前可以查看的每个频道，也无法将此数字完全减少回 0。我宁愿只重置这个号码。正如我在评论中提到的，我不喜欢我唯一的选择是没有通知徽章，或者通知徽章明确设置为具有未读消息的频道数量......我最喜欢一个选项来增加徽章，并且，除此之外，不包含特定号码的通知。我希望人们看到他们有聊天，因为这非常重要，但我不希望显示这些高数字，那些未读消息不会永久保持相关性。只有新的未读消息是相关的。
我在 Programmable Chat iOS SDK 团队，希望能帮助您解决上述一些问题。
如您所述，对 registerWithToken: 的引用以及在没有标记 present/known 时使用 nil 参数调用它的说明均已弃用。我们将更新文档和教程以反映这一点 - 谢谢！
今天，handleNotification:completion: 是可选的。其目的是解析推送负载的 userInfo 部分并提供您提到的回调以帮助您的用户了解事件的发生。今天跳过这一步并没有什么坏处，但将来可能会使用这些回调来提供更多关于在可编程聊天中传递通知的反馈，因此您可能希望在未来的某个日期回顾一下实现这一点。
当您的用户注销时，建议您调用deregisterWithNotificationToken:completion:方法以确保他们的隐私。如果您不取消注册与他们的身份关联的令牌，他们将继续收到该身份的通知，即使他们以后在该设备上使用具有不同身份的访问令牌也是如此。通过我们的 REST API 以编程方式管理通知绑定的机制在我们的路线图上，但我目前没有发布日期可以分享。
如 Apple 的推送通知文档中所述，最好不要缓存设备令牌或假设推送设备令牌永远不会更改，因为此令牌可能会随着未来的注册而更改。同样，建议您在收到来自 Apple 的设备令牌时将 Apple 提供的令牌传递给 Programmable Chat，以确保我们拥有最新的令牌来访问您的用户设备。
APNS 传递的徽章计数报告给定用户未读消息的频道数。您可能会在此处看到过时的结果，原因有几个。在您的客户端中，您是否在 TCHMessages 上调用 setLastConsumedMessageIndex:completion:（或同一 class 中的相关方法之一）以更新后端的未读状态？完成此操作后，您应该会在短时间后看到更新的推送和更新的徽章计数。另一种可能性是，如果您确实有其他身份的过时绑定仍在您正在测试的频道上，但未记录 out/de-registered。请注意，当应用程序在前台运行时，您有责任自行更新徽章计数 - iOS 不会这样做。这是您可能希望确保调用 handleNotification:completion: 的地方，因为如果我们收到徽章更新，我们会调用它。您还可以查看负载并根据需要直接在 UIApplication 的接收委托中调用更新标记计数。对此进行测试的一种方法是设置一个新通道并使用该通道测试消息，并在适当的时候更新消费范围。您可以在 consumption horizon documentation 中找到更多信息。下面，您可以找到一个更新徽章计数以响应可编程聊天的委托方法的示例：
- (void)chatClient:(TwilioChatClient *)client notificationUpdatedBadgeCount:(NSUInteger)badgeCount {
[[UIApplication sharedApplication] setApplicationIconBadgeNumber:badgeCount];
}
我们的通知团队正在研究利用 Apple 的提供者身份验证令牌而不是证书，但我们目前无法确定何时会提供支持。
如果我能提供进一步的帮助，或者如果我遗漏了您的任何问题，请告诉我！
谢谢，
兰迪
我已经集成了 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。
我还想知道 - (void)handleNotification:(nonnull NSDictionary *)notification completion:(nullable TCHCompletion)completion method on the TwilioChatClient actually does. I see that the delegate 有 5 种不同的通知方法。这个 handleNotification 方法是否只是调用适当的委托方法？我自己并没有使用这种方法，我现在只是显示一个带有通知消息的警报视图，所以我想知道是否还有我遗漏的额外好处，或者我什至是潜在的错误'通过不使用 TwilioChatClient 处理程序进行介绍。
我想知道的最后也是最重要的事情是如何在用户注销并稍后重新登录时处理推送通知的注册，这在本教程中没有涉及。从 - (void)application:(UIApplication*)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData*)deviceToken 返回的 deviceToken 是否意味着存储在比单例的 属性 更持久的地方？我可以通过 Twilio 或我不知道的 iOS 方法在其他地方重新获得它吗？似乎一旦我将用户注销，当他们登录到不同甚至相同的用户时，我就无法再次收到通知。我看到有一个 deregisterWithNotificationToken:completion: 方法，但由于它需要一个非空令牌，所以我只能在我的应用程序尚未关闭的情况下根据教程调用它。保留此令牌的推荐方法是什么？ NS用户默认值？在我服务器数据库的某处？
编辑： 实际上，我还有一个问题。如果我取消选中已读状态框，然后在聊天实例配置上重新选中它，是否会重置每个人的未读频道数？我的消费范围/阅读状态设置不当，而且我还有很多频道对用户隐藏，即使它们在其中......所以，启用徽章计数后，用户可能会看到非常高的数字当他们收到一条消息时，即使他们打开当前可以查看的每个频道，也无法将此数字完全减少回 0。我宁愿只重置这个号码。正如我在评论中提到的，我不喜欢我唯一的选择是没有通知徽章，或者通知徽章明确设置为具有未读消息的频道数量......我最喜欢一个选项来增加徽章，并且，除此之外，不包含特定号码的通知。我希望人们看到他们有聊天，因为这非常重要，但我不希望显示这些高数字，那些未读消息不会永久保持相关性。只有新的未读消息是相关的。
我在 Programmable Chat iOS SDK 团队，希望能帮助您解决上述一些问题。
如您所述，对 registerWithToken: 的引用以及在没有标记 present/known 时使用 nil 参数调用它的说明均已弃用。我们将更新文档和教程以反映这一点 - 谢谢！
今天，handleNotification:completion: 是可选的。其目的是解析推送负载的 userInfo 部分并提供您提到的回调以帮助您的用户了解事件的发生。今天跳过这一步并没有什么坏处，但将来可能会使用这些回调来提供更多关于在可编程聊天中传递通知的反馈，因此您可能希望在未来的某个日期回顾一下实现这一点。
当您的用户注销时，建议您调用deregisterWithNotificationToken:completion:方法以确保他们的隐私。如果您不取消注册与他们的身份关联的令牌，他们将继续收到该身份的通知，即使他们以后在该设备上使用具有不同身份的访问令牌也是如此。通过我们的 REST API 以编程方式管理通知绑定的机制在我们的路线图上，但我目前没有发布日期可以分享。
如 Apple 的推送通知文档中所述，最好不要缓存设备令牌或假设推送设备令牌永远不会更改，因为此令牌可能会随着未来的注册而更改。同样，建议您在收到来自 Apple 的设备令牌时将 Apple 提供的令牌传递给 Programmable Chat，以确保我们拥有最新的令牌来访问您的用户设备。
APNS 传递的徽章计数报告给定用户未读消息的频道数。您可能会在此处看到过时的结果，原因有几个。在您的客户端中，您是否在 TCHMessages 上调用 setLastConsumedMessageIndex:completion:（或同一 class 中的相关方法之一）以更新后端的未读状态？完成此操作后，您应该会在短时间后看到更新的推送和更新的徽章计数。另一种可能性是，如果您确实有其他身份的过时绑定仍在您正在测试的频道上，但未记录 out/de-registered。请注意，当应用程序在前台运行时，您有责任自行更新徽章计数 - iOS 不会这样做。这是您可能希望确保调用 handleNotification:completion: 的地方，因为如果我们收到徽章更新，我们会调用它。您还可以查看负载并根据需要直接在 UIApplication 的接收委托中调用更新标记计数。对此进行测试的一种方法是设置一个新通道并使用该通道测试消息，并在适当的时候更新消费范围。您可以在 consumption horizon documentation 中找到更多信息。下面，您可以找到一个更新徽章计数以响应可编程聊天的委托方法的示例：
- (void)chatClient:(TwilioChatClient *)client notificationUpdatedBadgeCount:(NSUInteger)badgeCount {
[[UIApplication sharedApplication] setApplicationIconBadgeNumber:badgeCount];
}
我们的通知团队正在研究利用 Apple 的提供者身份验证令牌而不是证书，但我们目前无法确定何时会提供支持。
如果我能提供进一步的帮助，或者如果我遗漏了您的任何问题，请告诉我！
谢谢， 兰迪