Best practices using Chat SDK

• There is no need to implement shutdown/create cycle on network drops → SDK reconnects automatically after regaining network .
• There is no need to implement shutdown/create cycle on going to background then returning to foreground → SDK reconnects automatically after becoming foreground app .
• Shutdown needs to be called only when doing logout / login within the same SDK session.
• It is highly recommended to create a new Chat SDK instance, do not reuse the old instance for the new SDK initialization after shutting down inside the same session.

• Register for push notifications on every application start to avoid cumbersome logic of checking if registration exists or not. To not do excessive registrations, remember current device token as provided by the OS in the persistent memory. Compare the values on startup and re-register only if the tokens differ.
• React to device token changes provided by the OS events (iOS, Android, and FCM in browsers support these events) and re-register with new token.

• Push registration Time-To-Live (TTL) is 1 year of idle time - it is worth it to unregister from push notifications using SDK methods when re-launching applications with different Chat identity. Otherwise your app might receive pushes for the previously logged in user.

  • Push deregistration when uninstalling the application is still not fully solved. We rely on OS to stop providing push notifications for the apps that are no longer installed.
  • Deallocate and release all objects referencing the old SDK instances as this may complicate the troubleshooting process.

• It is highly recommended to use several hours (up to 24H) for token's TTL.

  • Tokens with TTL under 3 minutes won't work in Twilio Chat infrastructure.
• Implement update token methods in respective SDKs, reacting to the token expiration events provided by SDKs.
• Pre-fetch token and store in temporary storage in case you would need faster startup - you can save round trip time to your token generator.
• Token is the authorization to use your service instance (and thus charge you for this usage) - secure it properly.

Some additional details about the JavaScript SDK behavior:

1. Promise to create Client is resolved after we started all connections, not all channels fetched.

2. Fetching of user's subscribed channels starts asynchronously and continues after Client instance is

   resolved in Promise.

3. Due to (1) and (2) to get the list of subscribed channels, you will need first to subscribe to

   Client#channelAdded and Client#channelJoined events and only after call the getSubscribedChannels method.

   • getSubscribedChannels is paginated, hence duplicated channels might arrive from two sources: from events and from this method call, it's up to the developer to resolve it.

4. Channel's Messages are not fetched on Channel load automatically - hence, only Channel#messageAdded event is emitted on new messages.

   • if customer deliberately fetched some messages, then Channel#messageUpdated and Channel#messageRemoved events are emitted only on those fetched messages.

5. Some methods are semi-realtime, i.e. guarded by caching with some lifetime, calling them rapidly might not reflect actual value, but will catch up after cached value expires:

   • Channel.getMembersCount()
   • Channel.getMessagesCount()
   • Channel.getUnconsumedMessagesCount()

All these practices are applicable to Android and iOS Chat SDKs.

1. You could perform ChatClient operations only after it has fully synchronized (you should have received the ChatClient.onCientSynchronization callback with status equivalent to .ALL → this means the synchronization operation has completed).
2. Similarly, you can perform operations on the Channel only after the channel has completed the synchronization process.
3. When updating various attributes you need to wait for corresponding Updated event, otherwise you may get stale data. All operations that take a listener or a delegate are asynchronous, so when you receive the successful result in the listener/delegate it means the SDK has merely sent the command - and you must now wait for the actual Update event to arrive before you could see actual updated values.
4. All references to Chat objects (Channels, Members, Messages, Users etc) must be released prior to releasing ChatClient.

Next: Channels and Messages