feat: multiple push providers

[sdenaci]

this pr reimplements #1128 (see description below) on current development branch
I needed to use this library with multiple push providers on a project I was working on, and saw on the 1128 discussion that @shercoder and @Dallas62 planned to reimplement it on dev. So I tried to do that with minimal changing, and submit it back to library in case it is useful.

This change only impacts Android

The need for this change came because the project I work has a need to support multiple push providers. We have an internal provider where we manager our in-house push notifications and then there is a need for external/marketing push notifications that we depend on a third-party to deliver.

Since there can only be one FirebaseMessagingService with intent-filter of com.google.firebase.MESSAGING_EVENT, we cannot have a service from Localytics and RNPushNotificationListenerService declared in our AndroidManifest. Android by default will only pick the first declaration.

In order to support multiple providers, a developer can create a custom FirebaseMessagingService that distributes the push notification to providers. Please see this issue I created that explains the problem and the solution in more details #952

Basically this change now allows the developer in need to do the following in their custom FirebaseMessagingService:

private RNReceivedMessageHandler receivedMessageHandler = new RNReceivedMessageHandler(this);

...
...
...

@Override
    public void onMessageReceived(RemoteMessage remoteMessage) {
        Map<String, String> data = remoteMessage.getData();

        String from = remoteMessage.getFrom();
       
            try {
                if (from first provider) {
                    receivedMessageHandler.handleReceivedMessage(remoteMessage);
                } else {
                    // pass remote message to another provider
                }
            } catch (Exception e) {
                Log.e(e, "Failed to extract Push Message", remoteMessage.getMessageId());
            }
        
    }

NOTE: There will be no change in behavior in how the current version of this library works and the users who don't need the support for multiple push providers won't have to change anything in their code base and continue to use the RNPushNotificationListenerService as it is.

Testing

1. For single provider, you can just go through the normal setup as described.

2. For multiple providers, go through the normal setup for this library but instead use your customer `FirebaseMessagingService` instead of `RNPushNotificationListenerService` as mentioned above.

[Dallas62]

Hi @sdenaci
Thanks for the PR, I'm not sure if onNewToken is still working.

[sdenaci]

hi @Dallas62 ! thanks for pointing that out. I have now added an explicit override in the listener file.

[Dallas62]

Thanks for the fast change!
Another question which comes into my mind. I don't know why exactly you need this features (use-case), but how did we know which provider give us the token ? (or notification)

[sdenaci]

For notifications: The other library I am using provides a method to check whether the push comes from their server. In the case that users are using other libraries that do not provide methods like this, the push would have to include some kind of key in push that listener could switch on in order to determine which handler should be invoked.
For token: User's custom listener implementation of onNewToken would have to use both libraries' on newToken method (because both libraries have to do whatever they have to do with the new token)

[Dallas62]

Ok, since onNewToken is not the initial request, and we should add the origin of the token (here Firebase).
I will merge and move the method, thanks again for the PR !