Feature Recommendation: Callback for raw push object after notification pressed

[jehartzog]

We are currently in the process of migrating our react native application to use this lib for all push notifications. We previously used the more general libs react-native-push-notification v4.0.0, @react-native-community/push-notification-ios v1.3.0, and react-native-firebase v5.6.0. We used Iterable to actually send push notifications, but just processed the raw payload ourselves to get the routing & tracking we needed.

So far the integration of this lib has been smooth, but we found one rather custom thing we had set up exposed a gap in the functionality of this (and the underlying iOS/Android) SDK.

Our Current Solution

We previously used the Push Payload field to add our custom JSON which told our app how to handle the push once the user pressed on it.

Example

Why This Approach Broke with this SDK

We realized early on that we basically had custom-built a lot of the functionality this SDK provides. We did so a year ago, before this SDK was around. After this lib was released we noticed it would be better to use the OpenURL action, and just insert deep-links that we can use in our app, rather then continuing to use our custom approach.

However we were forced to do so by the fact what we see as two omissions in this SDK:

1. No callback fires to our app when a user presses on a notification (without using an action to do that)
2. Since we don't have the above callback, we also can't reliably get a custom payload (`Push Payload) that the user pressed

Here is an example of the kind of callback you'd expect, if you just want to have non-sdk code to have access to the entire push object.

I thought this was an omission in this react-native version, but I dug around the root ios-sdk and saw this wasn't the case. The notification object is processed, tracked, and passed to an action handler, but there's no option to pass the raw object down the client.

Your docs really only mention the ability to read this payload using IterableApi.lastPushPayload in client code to poll for the last payload received, but this leaves out the important cases of if an app is backgrounded/foregrounded when a push is pressed. The client has no way to know a push came through, except perhaps by polling the above to see if there is a change (not an approach we tried or recommend).

Our Workaround

We saw that we could get the 'callback' functionality we desired by using the Open URL action and hooking in there. But it did seem odd to use that there is apparently know way to know if a push is pressed by the user unless it happens to have a openURL or other action attached to it.

Our Recommendation

We were able to quickly work around this, and end up with a cleaner implementation that met our needs. However, I expect most react-native developers will expect an option to hook into the raw push object arrival to enable additional customization/processing if desired.

[grifotv]

@jehartzog thanks for sharing this.

I was wondering what was your final approach after all? Did you keep @iterable/react-native-sdk as well as react-native-push-notification and @react-native-community/push-notification-ios?

Also curious to know if you checked the in-app API such as inAppHandler and Iterable.inAppManager.

[jehartzog]

@grifotv We simply went through all (hundreds) of our templates to remove the custom push payloads and place that data as query parameters in the openURL action. A bit of work to transition, but dramatically safer for the long run. It worked great, no complaints.

We used the IAM features of the Iterable SDK extensively. The biggest surprise we hit was #92 which seems to be resolved now. We did not upgrade yet so didn't eval the fix.

[grifotv]

@jehartzog thanks for the quick response. Regarding your push notification callback workaround, could you please explain where you added this? Would it be the config.urlHandler ? Wondering if you managed to get any other info in addition to the url (eg: push notification title and message).

We saw that we could get the 'callback' functionality we desired by using the Open URL action and hooking in there. But it did seem odd to use that there is apparently know way to know if a push is pressed by the user unless it happens to have a openURL or other action attached to it.

[jehartzog]

@grifotv Yes, we used urlHandler and only captured data via the url passed in. We didn't get any additional data from the push itself.