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[bot]]

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: ``` : short description of change being made ``` **If your pull request [introduces breaking changes](https://web.archive.org/web/20220725195319/https://nordicapis.com/what-are-breaking-changes-and-how-do-you-avoid-them/)** to the code, use this format: ``` !: short description of breaking change ``` where `` 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](https://www.conventionalcommits.org/). **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.

[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 win@customer.io. 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.