Handling multiple push providers

How to handle multiple push providers

If you use another push service alongside our SDK (like FlutterFire), then that other service takes over push handling by default and prevents your app from receiving rich push notifications from Customer.io.

There are two ways to solve this problem, but we typically recommend the first option, because it’s more flexible and lets you process notifications through another service. The second option causes our SDK to take over push handling entirely.

Option 1 (Recommended): Let Customer.io process notification payloads

You can pass the payloads of other message services to Customer.io whenever a device receives a notification, so our SDK can process it for you. The SDK exposes the onMessageReceived and onBackgroundMessageReceived methods for this purpose. A true value (the default) means that the Customer.io SDK will generate the notification and track associated metrics. A false value means that the SDK will only process the notification to track metrics but will not generate a notification on the device.

CustomerIO.messagingPush().onMessageReceived(payload).then((handled) {
  // handled is true if notification was handled by Customer.io SDK; false otherwise
  return handled;
});

CustomerIO.messagingPush().onBackgroundMessageReceived(payload).then((handled) {
  // handled is true if notification was handled by Customer.io SDK; false otherwise
  return handled;
});

Imagine that you use FlutterFire (Firebase for Flutter) alongside our SDK. You might use the onMessageReceived and onBackgroundMessageReceived methods to handle notifications ↗ like this:

FirebaseMessaging.onMessage.listen((RemoteMessage message) {
  CustomerIO.messagingPush().onMessageReceived(message.toMap()).then((handled) {
    // handled is true if notification was handled by Customer.io SDK; false otherwise
    return handled;
  });
});

// Annotation is required only for Flutter version 3.3.0 or higher (to prevent removal during tree shaking in release mode)
@pragma('vm:entry-point')
Future<void> _firebaseMessagingBackgroundHandler(RemoteMessage message) async {
  await Firebase.initializeApp();
  CustomerIO.messagingPush().onBackgroundMessageReceived(message.toMap()).then((handled) {
    // handled is true if notification was handled by Customer.io SDK; false otherwise
    return handled;
  });
}

void main() async {
  // Initialize required SDKs
  FirebaseMessaging.onBackgroundMessage(_firebaseMessagingBackgroundHandler);
  // Run the app
}

Forward token refreshes on Android

On Android, FlutterFire’s messaging service has a higher priority than Customer.io’s, so Firebase sends new tokens to FlutterFire. The Customer.io SDK fetches the current token each time your app starts. When Firebase refreshes the token while your app is running, Customer.io gets the new token the next time your app starts.

To register the new token right away, forward FlutterFire’s registration events to CustomerIO.instance.registerDeviceToken. The examples below forward tokens only on Android, because on iOS the Customer.io SDK receives new tokens itself when it fetches tokens for you.

The stream you listen to depends on whether your app registers FCM tokens or Firebase Installation IDs. FlutterFire reports a new FCM token through onTokenRefresh. In FID mode, it reports the FID through onRegistered instead, so if you switch modes, update your listener too.

import 'dart:io' show Platform;

// After you initialize Firebase and Customer.io, for example in main():
if (Platform.isAndroid) {
  FirebaseMessaging.instance.onTokenRefresh.listen((token) {
    CustomerIO.instance.registerDeviceToken(deviceToken: token);
  });
}

import 'dart:io' show Platform;

// After you initialize Firebase and Customer.io, for example in main():
if (Platform.isAndroid) {
  FirebaseMessaging.instance.onRegistered.listen((installationId) {
    CustomerIO.instance.registerDeviceToken(deviceToken: installationId);
  });
}

Option 2: Register Customer.io Messaging Service

If you add another push service along with our SDK, like FlutterFire, it takes over push notification handling and prevents your app from receiving rich push notifications from Customer.io. To fix this issue, you need to add the following code under the <application> tag in the Manifest.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>