41

Handling Multiple Push Providers

How to handle multiple push providers

If Customer.io is the only SDK that you use in your app to display push notifications, then you don’t need to do anything special to display push notifications.

But, if you use another module in your app that can display push notifications like expo-notifications, react-native-push-notification, or rnfirebase, these modules can take over push handling by default and prevent your app from receiving push notifications from Customer.io.

You can solve this problem using one (and only one) of the methods below, but we typically recommend the first option, because it doesn’t require you to write native code! Please note that the following methods will always return true for iOS.

Option 1 (Recommended): Set Customer.io SDK to handle push clicks

You can pass the payloads of other message services to Customer.io whenever a device receives a notification, and our SDK can process it for you. The SDK exposes the onMessageReceived method for this that takes two arguments:

• a message.data object containing the incoming notification payload
• a handleNotificationTrigger boolean indicating whether or not to trigger a notification.
  • true (default) means that the Customer.io SDK will generate the notification and track associated metrics.
  • false means that the SDK will process the notification to track metrics but will not generate a notification on the device.

You’ll use the onMessageReceived like this:

CustomerIO.pushMessaging().onMessageReceived(message).then(handled => {
  // If true, the push was a Customer.io notification and handled by our SDK 
  // Otherwise, `handled` is false
});

You can pass values in onMessageReceived by listening to notification events exposed by other SDKs. Make sure that you add listeners in the right places to process notifications that your app receives when it’s in the foreground and add background listeners that might be required by other SDK to process notifications that your app receives when it’s in background/killed state.

If you always send rich push messages (with image and/or link), adding event listeners is enough. But if you send custom push payloads using the notification object or send simple push messages (with just a body and title), you may get duplicate notifications when your app is backgrounded because Firebase itself displays notifications sent using the notification object.

To avoid this, You can pass false in handleNotificationTrigger to track metrics for simple and custom payload push notifications. To simplify this behavior, the SDK also exposes an onBackgroundMessageReceived method that automatically suppresses pushes with the notification object when your app is in background.

If you use rnfirebase, you can setup listeners like this:

useEffect(() => {
  const unsubscribe = messaging().onMessage(async remoteMessage => {
    CustomerIO.pushMessaging().onMessageReceived(remoteMessage).then(handled => {
        // If true, the push was a Customer.io notification and handled by our SDK 
        // Otherwise, `handled` is false
    });
  });

  return unsubscribe;
}, []);

messaging().setBackgroundMessageHandler(async remoteMessage => {
  CustomerIO.pushMessaging().onBackgroundMessageReceived(remoteMessage).then(handled => {
    // If true, the push was a Customer.io notification and handled by our SDK 
    // Otherwise, `handled` is false
  });
});

Option 2: Register Customer.io Messaging Service

You can register Customer.io’s messaging service in your Manifest file so that we handle all notifications for your app. You can do this by adding the following code under the <application> tag in the AndroidManifest.xml file in your app’s android folder.

<service
    android:name="io.customer.messagingpush.CustomerIOFirebaseMessagingService"
    android:exported="false">
    <intent-filter>
        <action android:name="com.google.firebase.MESSAGING_EVENT" />
    </intent-filter>
</service>