[unimodules][android][notifications] Event listener can miss emit() calls made soon after app launch

[cruzach]

🐛 Bug Report

Summary of Issue

If you call Notifications.addResponseReceivedListener in useEffect for example, the listener will not be triggered when opening an app from a completely killed state via a notification. This can also be demonstrated by adding a timeout to componentDidMount as shown here. Without 1 second timeout- events come through; with 1 second timeout- event's do not come through.

I should note that the emit method is getting called in this case.

Environment - output of expo diagnostics & the platform(s) you're targeting

Reproducible Demo

https://snack.expo.io/@charliecruzan/push-notifications

Steps to Reproduce

Need to run the app as a published experience or standalone app (or bare debug build) to see the behavior. Press "show notification" and kill the app, tap the notification, observe that response listener isn't triggered.

Workaround

The workaround (and possibly long-term solution) is to add the listener outside of any component, then it works as expected (presumably bc of how much sooner it's getting called?). I changed the docs to suggest this so fewer people run into this issue

[cruzach]

exp.notification is not documented and not explicitly supported, so relying on that feature isn't recommended

[Aryk]

exp.notification is not documented and not explicitly supported, so relying on that feature isn't recommended

Got it, so for ios is there any work around at the moment (besides ejecting)? I suppose checking for exp.notification and using that is better than nothing.

[cruzach]

Using the legacy notifications API listener works, as well. Other than that there's no workaround besides waiting for SDK 39 🙁 sorry that you pretty much just have to wait

[dmitri-wm]

If you're testing this while running locally in the Expo client, e.g. with expo start, notification responses don't come through when the app is killed. You should build your app with expo build:android

Thank you for reply, yes this works. Just to clarify - to test any changes related to handling notifications when app is killed I have 2 options 1) eject from expo and test locally 2) create expo build. No other options, correct?

Thanks again for your help

[cruzach]

You can also run expo publish and test in the Expo client app through the published project

[cruzach]

I opened this new issue to try and keep the conversation focused around the root issue, and this thread is turning into troubleshooting one of the resulting problems, which I've already shared the answer for in the original issue- #6943. Any comments posted here that are answered in the other issue will be marked as off-topic (sorry to do this, but too many off-topic comments makes discussing the original issue I posted much more difficult)

@arveenkumar55 please refer to this comment

@xLesterGG as far as I know there's no problem running Linking.openUrl from addResponseReceivedListener. However, maybe it's easier for you to follow this react navigation guide on navigating outside of your component, rather than using Linking.openUrl

[ozerty]

Hi @cruzach,
Works when app is in background, but not when the app is killed.
The issue still persist on Android with both SDK 38 and SDK 39 in a managed workflow.
I try to move out addNotificationResponseReceivedListener outside of my component as suggested, but it doesn't work.

Thanks

[JamieS1211]

It is noted in the React documentation that useEffect is called after paint and useLayoutEffect is called 'synchronously after all DOM mutations' hence 'useLayoutEffect fires in the same phase as componentDidMount and componentDidUpdate'.

https://reactjs.org/docs/hooks-reference.html#timing-of-effects
https://reactjs.org/docs/hooks-reference.html#uselayouteffect

As such I have tested useLayoutEffect and still had no success.

Further to that, my specific implementation to navigate on notification was rather inconvenient when being placed outside the navigation container. For any others who have this issue and use ReactNavigation, my specific workaround here was to make a navigation container ref with a promise version, allowing await for the navigation to be mounted before completing the notification handling.

Setup the ref for the navigation container (ignore the typescript typings if relevant), the navigation ref promise only resolves after items have been mounted inside the navigation container (this is reason for checking "getRootState())".

import { createRef } from "react"

import { NavigationContainerRef } from "@react-navigation/core"

const navigationRef = createRef<NavigationContainerRef>()

export const navigationRefPromise: Promise<typeof navigationRef> = new Promise((resolve) => {
    const checkValue = () => {
        if (navigationRef.current && navigationRef.current.getRootState()) {
            return resolve(navigationRef)
        }

        setTimeout(checkValue, 50)
    }

    checkValue()
})

export default navigationRef

When processing the notification, if navigation data is present and results in a valid navigation action (based on navigation linking config), complete the navigation dispatch after the navigation ref promise has resolved.

addNotificationResponseReceivedListener((notificationResponse) => {
    const notificationData = notificationResponse.notification.request.content.data

    if (hasKeyGuard(notificationData, "navigationLink") && typeof notificationData.navigationLink === "string") {
        try {
            const state = getStateFromPath(notificationData.navigationLink, linking.config)

            if (state) {
                const action = getActionFromState(state)

                navigationRefPromise.then((navRef) => {
                    if (action && navRef.current) {
                        navRef.current.dispatch(action)
                    }
                })
            }
        } catch (error) {
            alert(error)
        }
    }
})

[KlasRobin]

Hi @cruzach,
Works when app is in background, but not when the app is killed.
The issue still persist on Android with both SDK 38 and SDK 39 in a managed workflow.
I try to move out addNotificationResponseReceivedListener outside of my component as suggested, but it doesn't work.

Thanks

Same problem here. Have also tried moving addNotificationResponseReceivedListener outside of App.js with no luck. Background and foreground works fine. Edit: Running SDK 39 in managed workflow.

[antwaven]

Hi @cruzach,
Works when app is in background, but not when the app is killed.
The issue still persist on Android with both SDK 38 and SDK 39 in a managed workflow.
I try to move out addNotificationResponseReceivedListener outside of my component as suggested, but it doesn't work.
Thanks

Same problem here. Have also tried moving addNotificationResponseReceivedListener outside of App.js with no luck. Background and foreground works fine. Edit: Running SDK 39 in managed workflow.

Hi, I too have the exact same issue. SDK 39 managed workflow. Tried it on standalone Android and iOS, inside useEffect or in the same place as Notifications.setNotificationHandler with no luck. If I can provide any other information to help find this issue please let me know.

[coopbri]

Confirming same problem as @KlasRobin, @antwaven, and @ozerty. Background/foreground work fine, just not when app is killed/not running. Also managed workflow, SDK 39.

[coopbri]

Hi @imhazige, I had issues on iOS 14, and still on Android for some reason (I think it had to do with the navigation mounting or something). I know this is not an ideal solution, but I switched to OneSignal for our app and it's been working great on both platforms (minus the typical FCM/APNs pitfalls, particularly slightly delayed notifications). This may be considered off-topic for the thread, but wanted to mention my success story just to indicate it as an option for you. Keep in mind it is a library with native bindings, so the Expo bare workflow is required if you choose to go that route.

I have no doubt the Expo notifications API will continue to improve over time, but I did not have time to wait, unfortunately.

[imhazige]

Hi @imhazige, I had issues on iOS 14, and still on Android for some reason (I think it had to do with the navigation mounting or something). I know this is not an ideal solution, but I switched to OneSignal for our app and it's been working great on both platforms (minus the typical FCM/APNs pitfalls, particularly slightly delayed notifications). This may be considered off-topic for the thread, but wanted to mention my success story just to indicate it as an option for you. Keep in mind it is a library with native bindings, so the Expo bare workflow is required if you choose to go that route.

I have no doubt the Expo notifications API will continue to improve over time, but I did not have time to wait, unfortunately.

@coopbri

Thank you for the response.

I am using SDK40 and it works on android, for ios it seems to have this issue (#11343) need to be fixed.

I have no choice for now as I have to bind to expo managed flow. Onesignal is better choice if I can use bareflow.

[sjchmiela]

Issue has been closed for fixes have been merged, please allow up to 24 hours for them to be available when you run expo build:ios (it's pretty late where I am and although I believe there will be no problems when we deploy to production I want to be a responsible citizen and not deploy and go to sleep).

As a foretaste and to some degree proof let me share with you this video — https://www.dropbox.com/s/u2ih7umzt1zbxbp/RPReplay_Final1608160452.mp4?dl=0 🙂

[sjchmiela]

Fix has been deployed to production Turtle builders! 🎉 All iOS apps built after December 17, 2020, 15:45 UTC will have fixes included and should not longer suffer from this problem.

This being said, let us know if this or similar problem ever rises again!

[Aryk]

@sjchmiela - Just upgraded to SDK 40

On my Galaxy S8, standalone app, managed, with Android Version 9 (I cannot upgrade the OS bc phone is not supported), the problem still persists.

See above: #9866 (comment)

Yes, I've also tried useLastNotificationResponse, but as I suspected in my previous comment, because it relies on the same hook, it still didn't work.

I've tried to make a minimal repro case but seems I can't reproduce it without the complexity of my app.

Should I make a new issue for this?

[Aryk]

Can anyone tell me if they can do:

1. Open notification from dead start on Android version 9.
2. Have background locations already running on Always via hasStartedLocationUpdatesAsync when the app is being opened.

While background location updates are on, the notifications are not being received from a dead start. When I turned it off, it works.

[alexandrius]

Can anyone tell me if they can do:

1. Open notification from dead start on Android version 9.
2. Have background locations already running on Always via hasStartedLocationUpdatesAsync when the app is being opened.

While background location updates are on, the notifications are not being received from a dead start. When I turned it off, it works.

For me notifications aren't wotking even without location updates. I still use #9866 (comment) this workaround

[github-actions]

Some changes in the following packages that may fix this issue have just been published to npm under next tag 🚀

📦 Package	🔢 Version	↖️ Pull requests	📝 Release notes
expo-notifications	0.9.0	#11382	CHANGELOG.md

If you're using bare workflow you can upgrade them right away. We kindly ask you for some feedback—even if it works 🙏

They will become available in managed workflow with the next SDK release 👀

Happy Coding! 🎉

[imhazige]

Fix has been deployed to production Turtle builders! 🎉 All iOS apps built after December 17, 2020, 15:45 UTC will have fixes included and should not longer suffer from this problem.

This being said, let us know if this or similar problem ever rises again!

Just to confirm, this works for me. on ios and android. have not see problem yet.
I am using SDK 40.

[webuijorgeGL]

Fix has been deployed to production Turtle builders! 🎉 All iOS apps built after December 17, 2020, 15:45 UTC will have fixes included and should not longer suffer from this problem.
This being said, let us know if this or similar problem ever rises again!

Just to confirm, this works for me. on ios and android. have not see problem yet.
I am using SDK 40.

But do you received a warning expected expo-notification V 0.8.2?

[webuijorgeGL]

Some changes in the following packages that may fix this issue have just been published to npm under next tag 🚀

📦 Package 🔢 Version ↖️ Pull requests 📝 Release notes
expo-notifications 0.9.0 #11382 CHANGELOG.md
If you're using bare workflow you can upgrade them right away. We kindly ask you for some feedback—even if it works 🙏

They will become available in managed workflow with the next SDK release 👀

Happy Coding! 🎉

will work with the expo SDK 40?

[brentvatne]

@webuijorgeGL - #11382 is in sdk 40, if that's what you're looking for. you cannot, however, use expo-notifications 0.9.0 in sdk 40 - that includes other changes (see the changelog).

https://github.com/expo/expo/blob/sdk-40/packages/expo/bundledNativeModules.json#L103

[MrIceman]

Still doesn't work with latest SDK

[Fuel0]

Any news ?
In my case addNotificationResponseReceivedListener is not working on background and killed app. I am using Expo SDK 42

[alexandrius]

@MrIceman @Guilhemfuel Just use the useLastNotificationResponse hook

[Fuel0]

@MrIceman @Guilhemfuel Just use the useLastNotificationResponse hook

It doesn't work either on background and killed. The response will be null...

[federicoromandemo]

Have you found a workaround for this issue? useLastNotificationResponse didn't work for me either.