Moving MParticle-specific messaging logic into a router for reusability

[dallasgutauckis]

Core changes:

• PushAnalyticsReceiver#onNotification* methods are now part of an interface (PushAnalyticsReceiverCallback)
• PushAnalyticsReceiver now delegates processing of the intent and calling of callbacks into MPMessagingRouter
• MPMessagingRouter abides by a contract of only consuming what it should, and lets the caller know if the given Intent was consumed

[dallasgutauckis]

This might make more sense to share the MPMessagingRouter prefix instead of the Receiver implementation.

[samdozor]

hey @dallasgutauckis - first of all, thanks again for the PR. The original intention that we had was for developers to optionally subclass PushAnalyticsReceiver and override onNotificationReceived and/or onNotificationTapped. I think that accomplishes the same thing, but maybe I'm missing something. Is there a reason why subclassing doesn't work for your setup?

[dallasgutauckis]

I'm assuming you mean subclassing PushAnalyticsReceiver — didn't see the Callback you mentioned when I was looking the other day — and yeah I understand the suggested implementation.

Besides preferring not to depend on third party SDKs for our super classes (composition over inheritance), some other things:

• Calling the super implementation doesn't let us know if the intent provided is handled by MParticle or not
• Our existing GCM receiver implementation utilizes WakefulBroadcastReceiver, and with this implementation we'll still be sending our own messages

I think that accomplishes the same thing, but maybe I'm missing something

It's close, but not quite the same. I would say the main benefit is knowing if the result should be handled by MParticle