iOS Twilio Programmable Chat Push Notifications

Question

I've integrated Twilio Programmable Chat, but I've had some issues with push notifications that I'm trying to sort out.

I'm looking at my code vs the example provided at https://www.twilio.com/docs/chat/ios/push-notifications-ios

The first thing I notice is that in the User Notification Setttings section(beyond the extra t in the name of the section), the deprecated method [self.chatClient registerWithToken:nil]; from V1.0 is used. In the current documentation for V 2.2.2, we have - (void)registerWithNotificationToken:(nonnull NSData *)token completion:(nullable TCHCompletion)completion, which specifies nonnull NSData* for the token parameter. So, we can't pass nil any longer. Is there anything we're now supposed to do for the if(notificationSettings.types == UIUserNotificationTypeNone) case within - (void)application:(UIApplication *)application didRegisterUserNotificationSettings:(UIUserNotificationSettings *)notificationSettings of our app delegate? (example provided in tutorial section mentioned above) Right now I just skip that step, and ensure that my updatedPushToken property is set to nil.

I'm also wondering what the - (void)handleNotification:(nonnull NSDictionary *)notification completion:(nullable TCHCompletion)completion method on the TwilioChatClient actually does. I see that the delegate has 5 different methods for notifications. Does this handleNotification method simply call the appropriate delegate method? I didn't use this method myself, I just show an alert view with the message of the notification right now, so I'm wondering if there are additional benefits under the hood that I'm missing out on, or even potential bugs I'm introducing by not using the TwilioChatClient handler.

The last and most important thing I'm wondering, that isn't touched in the tutorial, is how to handle registering for push notifications when a user has signed out and signed back in later. Is the deviceToken returned from - (void)application:(UIApplication*)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData*)deviceToken meant to be stored somewhere with more permanence than a property of a singleton? Can I re-obtain it elsewhere, either via Twilio or maybe an iOS method I'm unaware of? It seems once I sign a user out, I'm unable to receive Notifications again when they sign in to a different or even the same user. I see that there is a deregisterWithNotificationToken:completion: method, but since it requires a nonnull token, I can only call it based on the tutorial if my app hasn't been closed. What's the recommended way to hang on to this token? NSUserDefaults? Somewhere on my server's database?

Edit: I have another question, actually. If I uncheck the read status box, then re-check it, on a chat instance configuration, will that reset everyone's unread channel count? I had the setting of the consumption horizon / read status done improperly, and I also have a lot of channels hidden from users even though they are in them... so, with the badge count enabled, users are probably seeing very high numbers any time they get a single message, and won't be able to completely reduce this number back down to 0, even if they open every channel they can currently view. I'd prefer to just reset this number. As mentioned in my comments, I dislike that the only options I have are no notification badge, or a notification badge explicitly set to the number of channels that have unread messages... I would most prefer an option to just increment the badge, and, barring that, the notification that does not include a specific number. I want people to see that they have chats, as it is very important, but I don't want these high numbers being displayed, and those unread messages don't stay relevant permanently. Only new unread messages are relevant.

Answer 1

I'm on the Programmable Chat iOS SDK team and hope to help with some of your questions above.

The references to registerWithToken: as well as the instruction to call it with a nil parameter when no token is present/known are both deprecated as you've noted. We'll get the documentation and tutorial updated to reflect this - thank you!

Today, handleNotification:completion: is optional. Its purpose is to parse the userInfo portion of the push payload and provide the callbacks you mentioned to help your user know the events occurred. It's not detrimental to skip this step today but in the future it's likely these callbacks will be used to provide more feedback around delivery of notifications inside of Programmable Chat so you may want to look back into implementing this at a future date.

When your users log out, it is recommended you call the deregisterWithNotificationToken:completion: method to ensure their privacy. If you do not de-register the token from being associated with their identity, they will continue to receive notifications for that identity even if they later use an access token on that device with a different identity in the future. Mechanisms for managing notification bindings programmaticaly via our REST API are on our roadmap, but I do not have a release date to share at this time.

As mentioned in Apple's push notifications documentation, it is good to not cache the device token or assume push device tokens will never change since this token may change with future registrations. Likewise, it is recommended you pass along the token given by Apple to Programmable Chat whenever you receive a device token from Apple to ensure we have the most up to date token to reach your users device with.

Badge count as passed along by APNS reports the number of channels with unread messages for the given user. There are a couple of reasons that come to mind why you may be seeing an outdated result here. In your client, are you calling the setLastConsumedMessageIndex:completion: on TCHMessages (or one of the related methods in the same class) to update the unread status on the backend? After this is done, you should see an updated push come in with an updated badge count after a short period of time. Another possibility is if you do have outdated bindings for other identities still on the channel you are testing with that were not logged out/de-registered. Please note that while the application is in the foreground, you are responsible for updating the badge count yourself - iOS will not do it. This is one spot where you may wish to ensure you are calling handleNotification:completion: since we will call that if we receive a badge update. You can also look at the payload and make the call to update the badge count as needed directly in the receiving delegate on the UIApplication. One way to test this would be to set up a new channel and test messages with that, updating the consumption horizon when appropriate. You can find more info in the consumption horizon documentation. Below, you can find an example of updating the badge count in repsonse to Programmable Chat's delegate method:

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

Leveraging Apple's provider authentication tokens instead of certificates is something our notifications team is investigating but we don't have a date to share on when support for that will ship at this time.

Please let me know if I can help any further or if I missed any of your questions!

Thank you, Randy