-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
getInitialNotification() message still remains after receiving notification #2618
Comments
you didn't really fill out the template. react-native info output? where are you experiencing the problem? A snippet of the code where you try to do the thing you want and it returns unexpected problems? |
Hi @mikehardy, Any solution? Thanks |
Interesting. My solution would be to check that on app bootstrap once, and no where near anything that renders |
But |
Are you expecting getInitialNotification to be like a queue, and once you call it you dequeue the data? I'm thinking it is more like a store, and if there was an initial notification the info will always be there. I think there is a misunderstanding of the API. onNotificationOpened() is for when your app is open, and a notification is clicked. getInitialNotification() is for when your app was stopped and is started by clicking on a notification. They are different cases. https://rnfirebase.io/docs/v5.x.x/notifications/receiving-notifications#App-Closed I might be totally confused about your use case, but I think based on what I'm reading getInitialNotification is just supposed to behave different than what I infer are your expectations |
Is there any way to dequeue the data of Thanks |
Any solution? |
Not yet 👎 |
As long as your app is running, you can maintain state right? So, set a static boolean somewhere that indicates you have handled the initialNotification data already. Then only redirect if you have not handled it? For me something like ReSub or redux or similar would be perfect for this. Where ever you store state in your app, this is the time to use it. |
It would be better to dequeue the data of |
Sure, but don't let an idea of "better" stop you from "make it work" :-). APIs don't always behave the way we want for our project, and I'm sure if you proposed a PR that did this change and it was merged, the comments thread would fill up with people wondering why you changed it, since it worked already for them as it was 🤷♂ |
@mikehardy ,
Is there any way to control it using state or any way to unsubscribed Thanks |
This is an imprecise description of the Android activity lifecycle https://developer.android.com/guide/components/activities/activity-lifecycle Additionally, you keep describing getInitialNotification as being subscribed to. It is not an event. There is no subscription. It is just available data that you can fetch repeatedly or not. When you use the hardware back button you are not closing the app. The activity is pausing. It still exists as a unix process in the android system, and all of its state is preserved, including the data you could fetch from getInitialNotification It may be stopped (at which point state will be destroyed, including the state of getInitialNotification There are plenty of ways to control state in your app. I mentioned redux. You could use a Singleton pattern service initialized from bootstrap and toggled as to whether you responded or not. You can use the ReSub package and have a Store you subscribe to with this information. Each of those is a viable solution, and with the information I've posted above it should be possible to get something working. |
With @mikehardy in this case the "static boolean somewhere" you suggested won't work, as the react native instance gets restarted. We are forced to persist this information, which (you'll agree) is far from be the ideal solution. I too think that By the way, this very easily reproducible in dev:
This is not the behavior a developer expects, in any use case. |
Hmm. Interesting. So you're saying that for code-push the native code keeps running but the Javascript bundle restarts so it "feels" (at the javascript layer) like a fresh start programmatically but the user has already seen whatever you wanted from the initial notification (which might have been hours ago) and to workaround you use async storage or something to mark you've consumed it since memory state is not reliable? I could be wrong about any of that - I'm trying to active listen / restate to make sure I understand. In that case I could more easily understand why you could want an API you might unambiguously call call consumeInitialNotification or getInitialNotificationOneTime (if you get my meaning). 🤔 |
@mikehardy that's correct. You are right when you say that |
Well, I have very bad luck with statements like "this won't break any use case" especially when coupled with a definition of "normal" - and by that I just mean to say that I am constantly surprised at the ingenuity of people when solving problems with software, and how they use APIs in unconsidered ways :-). But maybe there is something that can be done like a second "once only" API or something. I am not officially proposing anything, but I personally hadn't thought of the javascript layer as disposable like in the code-push scenario so this has much more merit (whatever that is worth) in my opinion now |
Another API would work too, of course. I still think a developer expects |
@Salakar / @Ehesp something philosophical for you - should getInitialNotification consume the notification data, thus only returning it once and returning empty after the first call, or should it be (like it is now) a continuous fountain of the initial notification (if it existed). And if it is continuous, should there be a separate one-shot api. I take no position but you two probably have some experience / thoughts in the area |
Facing the same issue when I open the app by clicking on the notification it wents to the Notification tab |
A possible workaround is to use global variable (global.MyVar) to ensure How I did it:
|
@appli-intramuros this does NOT work in the codepush (i.e. JS reload) case, which is (so far) the most concerning one. |
On my work project I'm chewing through Deep Linking right now and I thought since they have a similar API (getDynamicLink()) it would be useful to contrast. In that implementation they clear the link as you fetch it, so as opposed to being a flag, it is more of a queue or stack (1 item, so queue vs stack the same) https://firebase.google.com/docs/dynamic-links/android/receive#handle_deep_links
So the Google SDK team has definitely taken a side here, but it's important to note that complexity - every Activity has to implement it. Not too bad for react-native where it's normally one activity but important to note. @Salakar / @Ehesp this might be interesting design-thinking as you shape the API of a v6-compatible notifications package. |
@39otrebla your current workaround would be async-storage I think (to store the flag consumed-or-not status) |
@appli-intramuros Thanks, But I already thought about the same logic but was just curious that is there is any way to deque the getInitialNotification. |
@mikehardy yes, we store in async handleInitialNotification(initialNotification) {
if (initialNotification !== null) {
try {
const lastInitialNotificationId = await AsyncStorage.getItem(AS_KEY_LAST_INITIAL_NOTIFICATION_ID)
if (lastInitialNotificationId !== null) {
if (lastInitialNotificationId === initialNotification.notification.notificationId) {
return
}
}
await AsyncStorage.setItem(AS_KEY_LAST_INITIAL_NOTIFICATION_ID, String(initialNotification.notification.notificationId))
} catch (e) {
// don't mind, this is a problem only if the current RN instance has been reloaded by a CP mandatory update
}
}
} Thanks for pointing out Google's point of view. BTW, this workaround has been deployed few weeks ago. Now we can finally kick out campaigns at will, without thinking about whether we have a CP mandatory update rolling out... |
As far I know below module will work only when your app is in foreground firebase.messaging().onMessage((message: RemoteMessage) => { |
Yes @Dhirajbhujbal i know onMessage() function is working on foreground but when user click on notification while its on foreground or background i did't get any call back
This both function provided by the react-native-firebase team but its not working on both os android/ios And here is my terminal log data :- If any one have a proper solution then please help me for that |
@lovekothari123 are you facing issue on android only? |
@r4mdat it appears you removed your comment connecting #1820 and this one but you may be on to something there. I think they are slightly different, but also related and that PR might fix the issue here. Anyone here want to give it a go with patch-package to test the PR? It was only closed for lack of testing, not any reason it can't merge |
@mikehardy I was ready to merge the PR to a fork but realized its iOS specific. Experiencing this issue on Android (haven't tested iOS) but regardless, didn't seem like the quick fix I was hoping for. FWIW, I believe the design of this could be better. I honestly can't think of a primary use case that supports having the notification constantly returned by the method. And certainly, if there was value in having that, it not's entirely lost by using Async Storage as well -- or having an additional method to manually clear the opened notification. |
Yes @r4mdat I agree with you after reading the similar getInitialLink API as mentioned here #2618 (comment) - at this point my opinion is that getInitialNotification should work once then mirror getInitialLink by not clearing itself. If you can get anything together for #1820 I am at least paying attention :-), cheers |
Hm, I intend to submit a new issue but I found this is exactly my issue: Then I think this would be the best workaround at this time: Thanks to @39otrebla 👍 |
I tested #1820, I don't have experience in iOS objective C so I cannot estimate what will be affected.
Be noted that this issue appears on both iOS & Android, #1820 is just for iOS. So my safer workaround is the mentioned JS approachment, to keep my production app stable. |
Hello 👋, to help manage issues we automatically close stale issues.
|
Still require community's attention. |
Hello 👋, to help manage issues we automatically close stale issues.
|
Still requires community's attention. |
"community" is you, I don't see a PR referenced? Submit one and we can look into it. |
We fixed this issue on Notifee, however the implementation is vastly different & would require a major overhaul on v5. Happy to accept PRs to sort this on v5. |
Hello 👋, to help manage issues we automatically close stale issues.
|
Thank you for your solution!!! |
Perfect, thanks! |
in solved my problem this way, in my case i have "remoteMessage.messageId" as an ID
|
Thanks for the solution! |
Issue
After receiving the notification, when the app is closed, the notification message is subscribed with the
notifications().getInitialNotification()
method. But the method returns the previous message again and again even after re-rendering.Project Files
iOS
Click To Expand
ios/Podfile
:AppDelegate.m
:Environment
Click To Expand
react-native info
output:react-native-firebase
version you're using that has this issue:5.5.6
TypeScript
?N
The text was updated successfully, but these errors were encountered: