Wonderpush and FCM

Hello,

I already use FCM cloud messaging on Android. With the new Android SDK v3, the WonderPushInitializerImpl class disappears, and the notification is received in the onMessageReceived of the FirebaseMessagingService class.

Is there a way to catch the Wonderpush notification in another receiver?

Another question, if the FCM notification server is delayed, will Wonderpush notifications be affected?

Thank you

Hi,

With the new Android SDK v3, the WonderPushInitializerImpl class disappears

The WonderPushInitializerImpl is not truly gone, to ease transitioning, but it’s no longer documented nor encouraged.
Thanks to the buildConfigField entries added in your app/build.gradle the SDK can now automatically initialize itself. But should you disable auto-init, you can initialize it yourself in the Application class.
The Application class is also the place of choice to setup a delegate or LocalBroadcastListeners.

Is there a way to catch the Wonderpush notification in another receiver?

You can use your own FirebaseMessagingService but you will first need to remove the one added by the SDK using the manifest merger with something along these lines:

<!-- Add the xmlns:tools attribute to the root manifest tag -->
<manifest xmlns:tools="http://schemas.android.com/tools">
    <application>
        <!-- Remove WonderPush SDK FirebaseMessagingService -->
        <service
            android:name="com.wonderpush.sdk.WonderPushFirebaseMessagingService"
            tools:node="remove"
        />
        <!-- Add your own FirebaseMessagingService implementation -->
        <service
            android:name="com.yourcompany.yourapp.YourFirebaseMessagingServiceImplementation">
            <intent-filter>
                <action android:name="com.google.firebase.MESSAGING_EVENT" />
            </intent-filter>
        </service>
    </application>
</manifest>

In your implementation, do not forget to forward the onNewToken() and onMessageReceived() methods to the SDK as follows:

public class YourFirebaseMessagingServiceImplementation extends FirebaseMessagingService {

    @Override
    public void onNewToken(String token) {
        WonderPushFirebaseMessagingService.onNewToken(this, token);
    }

    @Override
    public void onMessageReceived(RemoteMessage message) {
        WonderPushFirebaseMessagingService.onMessageReceived(this, message);
    }

}

You can also make your implementation extend the WonderPushFirebaseMessagingService class. In such case, don’t forget to forward the call to super.

Another question, if the FCM notification server is delayed, will Wonderpush notifications be affected?

What do you mean by the FCM notification server being delayed?
WonderPush uses FCM to send push notifications on Android.

Best,

Thank you for all these clarifications,

In your implementation, do not forget to forward the onNewToken() and onMessageReceived() methods to the SDK as follows:

public class YourFirebaseMessagingServiceImplementation extends FirebaseMessagingService {

    @Override
    public void onNewToken(String token) {
        WonderPushFirebaseMessagingService.onNewToken(this, token);
    }

    @Override
    public void onMessageReceived(RemoteMessage message) {
        WonderPushFirebaseMessagingService.onMessageReceived(this, message);
    }

}

I have already implemented this method, but to receive the FCM notification. I would like to separate notification from Wonderpush in another receiver, if possible.

What do you mean by the FCM notification server being delayed ?
WonderPush uses FCM to send push notifications on Android.

Imagine that the FCM servers are slowing down, for any reason, how do Wonderpush notifications react?

Hi,

Inspect the intent extras, there is a from property that gives you the sender id. onMessageReceived() returns true when the SDK has processed the notification successfully, false if it ignored a notification, typically sent by another provider.

As we entirely depend on FCM for transport, in such a scenario the notifications would be delayed, like for any other push provider.
The only way around this would be to maintain a persistent connection, one for each application, which would quickly drain the device battery.

Best,