Notification press on foreground changes the AppState to "background"

[kneza23]

So as the title says appstate changes to background when notfication press has occurred.

We have a trigger on app state reload to refetch everything when going from background to foreground.

But we don't want that behaviour on notification press.

Does anyone have any solutions and advices how to handle that or how to avoid appstate change event to be called when notifications gets pressed?

[mikehardy]

Runtime environment, like iOS or android?
Versions?

On Android at least, this is normal. The notification is not technically part of your app, so your app is backgrounded, you've got to code accordingly.

Same for permissions popups if I recall

[kneza23]

Both platforms experience this.

The difficulty is that background event happens before the press event on the notification so i am not sure how to disable the refetch when notification is opened.

[mikehardy]

This sounds like an app design issue - the "app came to foreground + user interacted with my notification" combo could be triggered after your app was in the background for a long time (user on some other app) or a short time. Perhaps your app state "stuff refresh" should be more sensitive to how long the app was in the background, vs why it went background/foreground.

I'm not sure how you can get around having to re-think under what conditions you actually want to perform activities on app state changes

[kneza23]

Well i think refetching data when you go from background -> foreground is considered best practice in most cases.

Ok, you can make it "intelligent" by measuring time but you will never be 100% safe has the data been updated/changed while you were "gone".

I always code my applications that depend on some server data like that.

But case when notification comes while you are in foreground state and you press it - is not case that i want for refetch.

It is weird for me that application goes into the background state while it was in foreground just because you have pressed the notification.

Also as a side note - when i have pressAction in my notification options - the thing happens two times:
background -> active
background -> active

[mikehardy]

If you cannot be sure data has changed in a (making this up...) 100millisecond time slice of a notification click in foreground, then how can you be sure that the data has not changed while the app is in use? Or even that it has not changed while you were actually fetching from the network. This seems like an technical argument that is unwinnable, the more I reason about it 🤔

Whether it seems weird or not, that's what the native platforms do, in this module we have zero control over app state with regards to foreground or background.

I'm not aware of multiple appstate events happening with one transition, it could be that you are adding listeners multiple times in an unexpected way (that is, perhaps the bundle reloads and orphans a listener, or a useEffect adds them multiple times or similar). Multiple addition of listeners is a quite common mistake, I'd investigate it from that angle before suspecting that multiple events really are fired, though with software anything might be found during investigation so who knows

[kneza23]

We use sockets to sync our data when in foreground. But when app is minimised the socket connections disconnects temporary - so when you go back from background you refetch your data and connect socket again.

If you find that pressAction (when in foreground) makes the appstate to go into the background twice, pls let me know :)

[kneza23]

This is what happens when there is no pressAction:

[0] LOG background
[0] LOG NOTIFICATION PRESS
[0] LOG active

This is what happens when there is pressAction:

[0] LOG background
[0] LOG active (refetch occurs - unwanted behaviour; no way to check for notification press)
[0] LOG background (it gos into background again)
[0] LOG NOTIFICATION PRESS
[0] LOG active

I use appState from import { useAppState } from "@react-native-community/hooks";
But it should behave the same as the one from repo as this is just wrapper for use in hooks.

[kneza23]

When app is in background everything behaves like it shuld

[0] LOG background
[0] LOG NOTIFICATION PRESS
[0] LOG active (refetch)

[frozencap]

@kneza23 I had to work around this very issue recently. This is more of an appState issue than a notifee issue per se.

I did this by wrapping appState in a hook that returns a debounced value specifically for these edge cases (refetch, user presence, etc.). Trickier than expected since js timers behave unpredictably when... backgrounded. Had to use react-native-background-timer.

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[VariabileAleatoria]

I'm facing a similar issue, I wonder why a notifee.onForegroundEvent method exists if clicking a notification triggers the appstate to become background. As far as I understand with a behaviour like this it's impossibile to have a foreground event

[quicksilverr]

Yeah, this is true. I'm facing something similar as well. As soon, as pressing on a notification...and the warning for onBackgroundevent handler is triggered

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[criss02-cs]

same issue

[leolusoli]

same issue

[LightKnight3r]

i think we can custom a Notification component when app is active. Not using displayNotification to resolve this issue

[hieuminh1810]

same issue :<