feat: tracking push metrics from js

[ami-aman]

Description

closes : https://github.com/customerio/issues/issues/10195

This PR fixes the problem of compatibility issues between expo-notifications and customerio-expo-plugin additionally supporting react native customers using other libraries that might be interfering in the functionality of CIO-RN package.

This feature can be tested using aman/expo-notifications branch of customerio-expo-ami-app.

Use case:

1. Track metrics when a device is in foreground and receives a push notification

const subscription = Notifications.addNotificationReceivedListener(notification => {
      .
      .
      // Fetch Customer.io payload from the push notification
      const payload = notification.request.trigger.payload
      CustomerIO.pushMessaging().trackNotificationReceived(payload)
      .
      .
    });

2. Track metrics when a device is in background and receives a push notification (handled with the help of TaskManager

TaskManager.defineTask(BACKGROUND_NOTIFICATION_TASK, ({ data, error, executionInfo }) => {
  console.log('Received a notification in the background!');
  CustomerIO.pushMessaging().trackNotificationReceived(data)
});

3. Track metrics when a user interacts with the push notification.

const subscription = Notifications.addNotificationResponseReceivedListener(response => {
     .
     .
     // Fetch Customer.io payload from the push notification and pass on to CIO method
     const payload = response.notification.request.trigger.payload
     CustomerIO.pushMessaging().trackNotificationResponseReceived(payload)
     .
     .
});

[github-actions]

Pull request title looks good 👍!

If this pull request gets merged, it will cause a new release of the software. Example: If this project's latest release version is 1.0.0. If this pull request gets merged in, the next release of this project will be 1.1.0. This pull request is not a breaking change.

All merged pull requests will eventually get deployed. But some types of pull requests will trigger a deployment (such as features and bug fixes) while some pull requests will wait to get deployed until a later time.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy!

This pull request title should be in this format:

<type>: short description of change being made

If your pull request introduces breaking changes to the code, use this format:

<type>!: short description of breaking change

where <type> is one of the following:

• feat: - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project.

• fix: - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project.

• docs: - This pull request is making documentation changes, only.

• refactor: - A change was made that doesn't fix a bug or add a feature.

• test: - Adds missing tests or fixes broken tests.

• style: - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc)

• perf: - Changes improve performance of the code.

• build: - Changes to the build system (maven, npm, gulp, etc)

• ci: - Changes to the CI build system (Travis, GitHub Actions, Circle, etc)

• chore: - Other changes to project that don't modify source code or test files.

• revert: - Reverts a previous commit that was made.

Examples:

feat: edit profile photo
refactor!: remove deprecated v1 endpoints
build: update npm dependencies
style: run formatter 

Need more examples? Want to learn more about this format? Check out the official docs.

Note: If your pull request does multiple things such as adding a feature and makes changes to the CI server and fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

[mrehan27]

Just minor queries, rest looks good to me 👍🏻

[miguelespinoza]

hey @ami-aman, wanted to get some clarification from these changes.
my main question, are there any pre-requisite configurations required for expo-notifications to play nicely with push notifications from customer.io?

I've tried several approaches, different libraries, but after going through multiple configurations, I think this is the best workflow. Our team is migration from expo-notifications to customerio-react-native, but noticing significant gaps, namely event listeners for foreground and background.

After investigating, I found this change, and it's exactly the setup we're looking for. Keeping the existing expo-notification listeners and just tracking push events using JS. But, when I send a push notification through customer.io expo-notification never picks it up. Was hoping to see your test repo, but getting a 404.

Any pointers would be super helpful!

[levibostian]

Hey there, @miguelespinoza. The latest version of the React Native SDK comes with improved push metrics tracking as well as compatibility with expo-notifications. We recommend upgrading to version 3.4+ to take advantage of these improvements.

In 3.4+, push metrics can be tracked without having to write any javascript code. This may allow you to remove expo-notifications entirely if you are only using Customer.io for sending and receiving push notifications in your app.

[miguelespinoza]

you read my mind! I just saw this a couple of mins ago: https://github.com/customerio/customerio-reactnative/pull/236/files
so was working on upgrading to 3.4. will report shortly, but if this does the trick, we'll be golden! We definitely need our own event listeners as we have a few supplementary calls to our backend.

[miguelespinoza]

hi @levibostian, I probably should have stated that I'm using Expo.
I thought upgrading customerio-expo-plugin to 1.0.0-beta.15 would do the trick, but no luck after upgrading that and customerio-reactnative to 3.4.0.

considering the steps you share reference updates to AppDelegate.h, I'm guessing customerio-expo-plugin has not made those adjustments? I'll do some digging, but figured you'd have the most context

[levibostian]

beta.15 of the Expo plugin has all of these improvements, including modifying AppDelegate files.

You will need to perform a expo prebuild --clean after installing the beta.15 version. Could you verify that you have run that step?

If you could, open a new issue or send a customer support request to [email protected]. We may need to request files from you to debug this further and having a new issue created would make that much easier then being in a pull request.

Thanks!

[miguelespinoza]

good point, if I encounter any issues I'll open a new PR. Had to switch priorities for today, but once I wrap those up, I'll follow up with the expo prebuild --clean command.

One last question, with beta.15, is it a requirement to upgrade to Expo v50, to support customerio-reactnative compatability with expo-notifications? Thanks a ton for the pointers

[levibostian]

with beta.15, is it a requirement to upgrade to Expo v50, to support customerio-reactnative compatability with expo-notifications?

No, you should not need to upgrade to v50. I would go ahead and try beta.15 on whatever version of Expo you're using today and if you encounter issues, open an issue.