In ASAPP Chat, users can receive Push Notifications (a.k.a. ASAPP background messages) for the following reasons:
If you are looking for a way to get the most recent Conversation Status, please see the Android or iOS documentation.
Figure 1: Push Notification Overview 1 - Device Token Registration.
Figure 2: Push Notification Overview 2 - Sending Push Notifications
After the Customer App (Figure 1) acquires the Device Token, it is then responsible to register it to the ASAPP SDK. ASAPP’s servers use this token to send push notification requests to a Customer-provided API endpoint (Customer Backend), which in turn sends requests to Firebase and/or APNs.
The ASAPP SDK and servers act as the middle-man with regards to the Device Token. In general, the Device Token must be a string that uniquely identifies the device that is defined and generated by the customer.
The Device Token format and content can be customized to include the necessary information for the Customer’s Backend service to send the push notifications. As an example, the Device Token can be a base64-encoded JSON Web Token (JWT) that contains the end user information required by the Customer’s Backend service.
ASAPP does not need to understand the content of the Device Token; however, the Device Token is persisted within the ASAPP Push Notification system.
Please consult with us if there is a requirement to include one or more PII data fields in the Device Token.
ASAPP’s servers do not communicate directly with Firebase or APNs; it is the responsibility of the customer to do so.
This section details the customer work necessary to integrate Push Notifications in two parts: the App and the Backend.
The Customer App manages the Device Token. In order for ASAPP’s servers to route notifications properly, the Customer App must register and deregister the token with the ASAPP SDK.
The Customer App also detects when push notifications are received and handles them accordingly.
Please refer to Figure 1 for a high level overview. There are usually two situations where the Customer App will need to register the Device Token:
If the user signs out of the Customer App, it is important to call the SDK API to de-register for push notifications.
This must be done before changing the ASAPP user credentials so that the SDK can use those credentials to properly disable Push Notifications for the user who is signing out.
If the device token de-registration isn’t done properly, there’s risk that the device will continue to receive Push Notifications for the user who previously signed out.
Please refer to the specific Android and iOS docs for more detailed information.
If the user is currently in chat, the message is sent directly to chat via WebSocket and no push notification is sent.
See Scenario 2 in Figure 2.
On Android: you usually receive foreground Push Notifications via a Firebase callback. To check if this is an ASAPP-generated Push Notification, call ASAPP.instance.getConversationStatusFromNotification
, which will return a non-null status object. The Customer App can now display user feedback as desired using the status object.
On iOS, if you have set a UNUserNotificationCenterDelegate
, it calls userNotificationCenter(_:willPresent:withCompletionHandler:) when a push notification is received while the app is in the foreground. In your implementation of that delegate method, call ASAPP.canHandleNotification(with: notification.request.userInfo)
to determine if ASAPP generated the notification. An alternative method is to implement application(_:didReceiveRemoteNotification:fetchCompletionHandler:), which is called when a push notification is received regardless of whether the app is in the foreground or the background. In both cases, you can access userInfo["UnreadMessages"]
to determine the number of unread messages.
See Scenario 1 in Figure 2.
When the App is in the background (or the device is locked), a system push notification displays as usual.
When the user opens the push notification:
ASAPP.instance.shouldOpenChat
. This should open chat. See more details and code examples in the Android SDK Handle Push Notifications section.launchOptions[.remoteNotification]
. Once again, call ASAPP.canHandleNotification(with:)
to determine if ASAPP generated the notification.It is common that the Customer solution already includes middleware that handles Push Notifications. This middleware usually provides the Customer App with the Device Tokens and sends Push Notification requests to Firebase and/or APNs. If the middleware provides an endpoint that can be called to trigger push notifications, ASAPP can integrate with it (given that the authentication strategy is in place). Otherwise, ASAPP requires that the Customer provides or implements an endpoint for this to take place.
ASAPP’s Push Notification adapters call the provided endpoint with a previously agreed-upon payload format. The following is a payload example:
For any new Push Notification Integration, ASAPP creates an “adapter” for ASAPP’s Notification Hub service. This adapter translates messages sent by Agents to a request that is compatible with the Customer Backend. This usually means that the Notification Hub adapter makes HTTP calls to the Customer’s specified endpoint, with a previously agreed-upon payload format.
The ASAPP Android and iOS SDKs already supply the interfaces and utilities needed for Customer Apps to register and de-register for Push Notifications.
From a Quality Assurance standpoint, ASAPP requires access to lower-level environments with credentials so that we can properly develop and test new adapters.
In ASAPP Chat, users can receive Push Notifications (a.k.a. ASAPP background messages) for the following reasons:
If you are looking for a way to get the most recent Conversation Status, please see the Android or iOS documentation.
Figure 1: Push Notification Overview 1 - Device Token Registration.
Figure 2: Push Notification Overview 2 - Sending Push Notifications
After the Customer App (Figure 1) acquires the Device Token, it is then responsible to register it to the ASAPP SDK. ASAPP’s servers use this token to send push notification requests to a Customer-provided API endpoint (Customer Backend), which in turn sends requests to Firebase and/or APNs.
The ASAPP SDK and servers act as the middle-man with regards to the Device Token. In general, the Device Token must be a string that uniquely identifies the device that is defined and generated by the customer.
The Device Token format and content can be customized to include the necessary information for the Customer’s Backend service to send the push notifications. As an example, the Device Token can be a base64-encoded JSON Web Token (JWT) that contains the end user information required by the Customer’s Backend service.
ASAPP does not need to understand the content of the Device Token; however, the Device Token is persisted within the ASAPP Push Notification system.
Please consult with us if there is a requirement to include one or more PII data fields in the Device Token.
ASAPP’s servers do not communicate directly with Firebase or APNs; it is the responsibility of the customer to do so.
This section details the customer work necessary to integrate Push Notifications in two parts: the App and the Backend.
The Customer App manages the Device Token. In order for ASAPP’s servers to route notifications properly, the Customer App must register and deregister the token with the ASAPP SDK.
The Customer App also detects when push notifications are received and handles them accordingly.
Please refer to Figure 1 for a high level overview. There are usually two situations where the Customer App will need to register the Device Token:
If the user signs out of the Customer App, it is important to call the SDK API to de-register for push notifications.
This must be done before changing the ASAPP user credentials so that the SDK can use those credentials to properly disable Push Notifications for the user who is signing out.
If the device token de-registration isn’t done properly, there’s risk that the device will continue to receive Push Notifications for the user who previously signed out.
Please refer to the specific Android and iOS docs for more detailed information.
If the user is currently in chat, the message is sent directly to chat via WebSocket and no push notification is sent.
See Scenario 2 in Figure 2.
On Android: you usually receive foreground Push Notifications via a Firebase callback. To check if this is an ASAPP-generated Push Notification, call ASAPP.instance.getConversationStatusFromNotification
, which will return a non-null status object. The Customer App can now display user feedback as desired using the status object.
On iOS, if you have set a UNUserNotificationCenterDelegate
, it calls userNotificationCenter(_:willPresent:withCompletionHandler:) when a push notification is received while the app is in the foreground. In your implementation of that delegate method, call ASAPP.canHandleNotification(with: notification.request.userInfo)
to determine if ASAPP generated the notification. An alternative method is to implement application(_:didReceiveRemoteNotification:fetchCompletionHandler:), which is called when a push notification is received regardless of whether the app is in the foreground or the background. In both cases, you can access userInfo["UnreadMessages"]
to determine the number of unread messages.
See Scenario 1 in Figure 2.
When the App is in the background (or the device is locked), a system push notification displays as usual.
When the user opens the push notification:
ASAPP.instance.shouldOpenChat
. This should open chat. See more details and code examples in the Android SDK Handle Push Notifications section.launchOptions[.remoteNotification]
. Once again, call ASAPP.canHandleNotification(with:)
to determine if ASAPP generated the notification.It is common that the Customer solution already includes middleware that handles Push Notifications. This middleware usually provides the Customer App with the Device Tokens and sends Push Notification requests to Firebase and/or APNs. If the middleware provides an endpoint that can be called to trigger push notifications, ASAPP can integrate with it (given that the authentication strategy is in place). Otherwise, ASAPP requires that the Customer provides or implements an endpoint for this to take place.
ASAPP’s Push Notification adapters call the provided endpoint with a previously agreed-upon payload format. The following is a payload example:
For any new Push Notification Integration, ASAPP creates an “adapter” for ASAPP’s Notification Hub service. This adapter translates messages sent by Agents to a request that is compatible with the Customer Backend. This usually means that the Notification Hub adapter makes HTTP calls to the Customer’s specified endpoint, with a previously agreed-upon payload format.
The ASAPP Android and iOS SDKs already supply the interfaces and utilities needed for Customer Apps to register and de-register for Push Notifications.
From a Quality Assurance standpoint, ASAPP requires access to lower-level environments with credentials so that we can properly develop and test new adapters.