Before i was using firebase 5+ and everything was working just fine. But few months ago i updated firebase to 7.0.1 (it was latest version) and over time users have started to report issues that they can't open specific page from push notification. After investigation i found steps to reproduce this bug, here it is:
It looks like they become expired or something, since you already opened app from another notification. Can that be possible ?
I'll update issue with code snippets if necessary, but seems like the problem is not in the code.
Versions:
"react-native": "0.61.2",
"@react-native-firebase/messaging": "^7.0.1",
"@react-native-firebase/app": "^7.0.1",
@Noolie Hii can you please tell me how you are calling your listeners in your app because, on android, I am not receiving notification when app is in quit state. Please have a look at #4071
I'm also experiencing this bug on Android, on iOS it is working as expected. I've upgraded to the latest version and it's still an issue.
Does anyone have an idea on how to debug this?
@Noolie Hii can you please tell me how you are calling your listeners in your app because, on android, I am not receiving notification when app is in quit state. Please have a look at #4071
Just exactly how it explained in react-native-firebase docs
I did some digging in getInitialNotification
: I get a messageId
as expected but the ReactNativeFirebaseMessagingReceiver.notifications
is empty.
@Wedin common cause, a splash screen intercepting (and not passing along) the Intent required to ferry the data through. react-native-splash-screen is a known failing, unmaintained culprit. react-native-boot-splash is a maintained package that works. You're piggy-backing on someone else's issue, so you haven't posted the information we request for troubleshooting, meaning this is just a guess
Yeah sorry, let me add some more info! It's not related to any other package as far as I can see, as this can be reproduced in a clean react-native project with only react-native-firebase as deps. I've verified this here: https://github.com/Wedin/test-react-native-firebase-messaging.
Dependencies
package.json
:"@react-native-firebase/app": "^8.3.1",
"@react-native-firebase/messaging": "^7.7.1",
"react": "16.13.1",
"react-native": "0.63.2"
firebase.json
for react-native-firebase v6:# N/A
The code is copied from the documentation on how to use getInitialNotification
. With those things added, I believe the bug should be come from this package, but Android development isn't something I know a lot about.
I believe I am having the same issue. I haven't installed any RN splash screen modules in my project. Easiest way for me to reproduce is by receiving a notification, opening app normally, close app, tap notification and see that getInitialNotification
is null
. iOS seems to work as intended.
Yep, i have encountered the same issue at Android app, iOS app is working as expected, any solution for that? @Wedin @alexwasner ?
Step to reproduced:
1, Open app as normal and hide app to background.
2, App received firebase notification message.
3, Kill app from recent menu app. (At the first time notification maybe will be disappear in status bar, but in the seconds time notification will be keep stay in status bar on my phone).
4, Tap to notification item from status bar and BUM... getInitialNotification from RN code will be null.
As as know, ReactNativeFirebaseMessagingReceiver.notifications array will be keep all remote messages, but when we kill application from recent menu app, this array will be free because app process died.
@vannt1991 there is no one I'm aware of (community or Invertase) working on this at the moment. I'm not sure what a solution would look like but if the app goes away then I assume there will need to be some sort of storage used instead of an in-memory array. Thinking about that practically, are there any patterns to follow in the current codebase where the library uses app-local storage already? (prefs, async-storage, something else?) Because if there is an existing pattern, then I would just re-use that to store information allowing for old notifications to be handled well. If there is not, then it seems a small JSON in the app cache dir that is stored with current notification information whenever they come in, with notifications removed as they are handled/cleared would do the trick
@mikehardy Thanks 馃憤 Yep, Pls do that assap, this issue is very common case and easy to reproduced with user. What we need todo:
1, transform Remote message to json and store to local storage at Receiver. (Maybe share preferences, by key is message id)
2, when getInitialNotification we can get from ReactNativeFirebaseMessagingReceiver.notifications otherwise check more get from share preferences by message id and removed it if existed data to free memory.
Thanks for your effort 馃憤
I will not do this. You, or someone else will do this - for the avoidance of doubt. No one is working on this currently (not me), and we are waiting for a PR. Someone here needs to propose a PR
https://github.com/invertase/react-native-firebase/pull/4203
@mikehardy Pls help me review this pull request, thanks 馃憤
Patch-package format patch bundle available here for the PR! https://github.com/invertase/react-native-firebase/suites/1137916996/artifacts/16295093 any independent confirmation that it works for you or not is very helpful 馃檹馃榿
I've tested the patch-package and I can no longer reproduce the issue :+1:
Excellent! Thank you for testing that - it helps a lot
I've reviewed the PR and it needs a little bit of work to be ready but I believe the style in general of the PR can work. The problem you will experience is that the PR is persisting notification information in your app preferences area, which is great in order to reference them across restarts but there is no cleaning function so there may be unbounded growth in storage space consumed by preferences.
I have proposed a solution to that deficiency and I/we are waiting on response from @vannt1991
Most helpful comment
https://github.com/invertase/react-native-firebase/pull/4203
@mikehardy Pls help me review this pull request, thanks 馃憤