getInitialNotification always get the previous notification received

[kennethpdev]

I've been pulling my hair out with this problem. The getInitialNotification event always gets the previous notification whenever you tap a notification from a tray. For both background and not running app. Everytime the app starts or opens, this gets emitted. I already clearing it using the ID but no joy.

What version of RN and react-native-fcm are you running? RN 0.40.0 / FCM 6.0.2 What device are you using? (e.g iOS9 emulator, Android 6 device)? Android emulator, Android 6 device Is your app running in foreground, background or not running? background and not running

[evollu]

interesting, let me check

[kennethpdev]

Thank you looking forward. My temporary work around is to store the previous notification ID (coming from tray) to some store/state and then whenever the app starts and if the notification(the supposedly removed) is still there, I can check whether that notification was already delivered, and that seems to be working solution for me.

[evollu]

if you can debug android, you can add break point here and see why it happens. It will be very helpful. I can't find out by just looking at the code now. https://github.com/evollu/react-native-fcm/blob/master/android/src/main/java/com/evollu/react/fcm/FIRMessagingModule.java#L59

[kennethpdev]

what do you mean by adding breakpoint? To be honest I have a rusty java knowledge.

[evollu]

adding breakpoint in IDE, like android studio and run debug

[kennethpdev]

I don't think I can help you with that. I only use atom as my editor no Android Studio or something.

[evollu]

no problem. I will take a look when I have time

[n8stowell82]

@evollu I am having this problem as well. I have set a breakpoint where you have indicated, and it is getting hit as soon as the application is launched. I see a promise passed in as a param, but I don't know what I am looking for to help you debug. Please let me know what I can be looking for.

Is there not a way to clear the initial notification once it has been read? I am calling FCM.removeAllDeliveredNotifications(); now as soon as I have read the initialNotification.

BTW I am running RN 0.35 and v2.5.6 of this library

[evollu]

Ok I will check

[evollu]

Initial notification is the notification that launches the app. It will remain unchanged through the whole app lifetime. When app is in background and user click the banner to resume the app, there will be a notification event triggered with special flag "open_from_tray". When app is not running and user click the banner to launch the app, you should get notification data in initial notification

I've checked behavior and seems both background and killed app work as expected.

[n8stowell82]

Ok, I may need to test this further. I recently upgraded to RN 41 and the latest of this repo. What could possibly be happening is that I am just refreshing the JS package each time (in dev mode) and that is not actually flushing the initial notification from the native side. What I was seeing was that once I received a notification, initial notification was firing every time despite having "read" that message. My memory is a bit fuzzy right now, but I am wondering if it is just when the js refreshes is not clearing that flag. I will try and test this tomorrow (Monday) and report back. thanks for your time

[Msspl-KrishnenduBhattacharyya]

Yes, I am facing same problem. After using FCM.getInitialNotification(), I used FCM.removeAllDeliveredNotifications() but the same problem I am facing.

[krishbhattacharyya]

Every moment, When I open the closed app it triggers FCM.getInitialNotification() but it should not trigger.

[ As per documentation; When app is not running and user clicks notification, notification data will be passed into FCM.getInitialNotification event ]

But for the quick solution I did: FCM.getInitialNotification().then((notif)=> { // is_push is a flag passing in data if(notif.is_push){ // Your code // I used this.props.navigator.push({}); } });

May be it can help temporary. FCM.removeAllDeliveredNotifications() should work.

[evollu]

@krishbhattacharyya FCM.getInitialNotification() is not a event listener, rather a async function call. If you trigger it every time resume the app, it means the function gets called. Move it to root component. Also, FCM.getInitialNotification() is getting the initial notification that starts the app from not running state (you have to kill the app to get the value changed)

[krishbhattacharyya]

Thank you @evollu

I think the documentation should be updated, you have described beautifully.

Specially this portion: [ When app is not running and user clicks notification, notification data will be passed into FCM.getInitialNotification event ]

[evollu]

will update

[maciejrrr]

Is there any way to clear this initial notification besides killing the app?

[andresmeidla]

@mradziwon calling notification.finish(); will clear the notification.

[andresmeidla]

actually scratch that, finish() is not available for the initial notification :/

[diegorodriguesvieira]

@andresmeidla do you have any workaround to finish initial notification?

[andresmeidla]

@diegorodriguesvieira got a workaroound for android only atm. in my case, im launching the app from a data notification myself using a launch intent. I just added the FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS flag to the launch intent, so it wouldn't be possible to launch the the same intent from the recent apps list after exiting from the app. If youre not launching the intent yourself, i think you can detect the FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY flag from the intent to determine the cases where the app was launched by clicking the window in the recent apps list, so you know that you can ignore the initial notification.

Haven't tried iOS yet, though, so don't know how to work around that yet.

[nkov]

@radev @andresmeidla I think what @evollu was saying in his previous comment was if you move FCM.getInitialNotification() from componentDidMount() to outside of the component entirely (I have mine above the component class definition for my main component), then the event fires when I open it from a notification, and if I minimize and open it again, it's either not displaying the initial notification at all or showing that it was started with the main intent, and I don't need to catch it.

For now also tried only in Android.

[beeglebug]

This seems related to #339, a lot of people are seeing weird calls to getInitialNotification, even when it is only called once on app load, and when there was no notification interaction

[evollu]

@nkov might be right. FCM.getInitialNotificaiton() can be placed outside of component lifecycle. May be in redux init?

[jqn]

+1 I running into the same issue, is this a misunderstanding about how this library works or is it a bug? anyone found a good solution yet?

[jqn]

I figured out most of the issue here is due to a misunderstanding on how this library works. Moving FCM.getInitialNotificaiton() and FCM.on(FCMEvent.Notification, async notif => { console.log('notification payload', notif); }); out of the component lifecycle works the way it is expected with no problems. At least for me.

Example:

import {
  AppState,
  Image,
  TouchableOpacity,
  Text,
  View
} from 'react-native';

import FCM, {
  FCMEvent,
  RemoteNotificationResult,
  WillPresentNotificationResult,
  NotificationType
} from 'react-native-fcm';

FCM.getInitialNotification().then(notification => {
// app was killed by the user
  console.log('initial notification', notification);
});

FCM.on(FCMEvent.Notification, async notif => {
    // app was in the background
    // notif will contain 
    // open_from_tray: 1
    console.log('notification payload', notif);
    // app was in the foreground
    // will not contain 
    // open_from_tray flag
});

class PushNotificationManager extends Component {
  ....
}

export default PushNotificationManager;

[beeglebug]

I think that's a separate issue.

Even outside of component lifecycle methods it still triggers every time the app boots, so everyone who uses the library needs to write similar boilerplate to filter the spurious calls which don't actually contain a real notification.

On Thu, 30 Nov 2017, 22:42 Joaquin Guardado, [email protected] wrote:

I figured out most of the issue here is due to a misunderstanding on how this library works. Moving FCM.getInitialNotificaiton() and FCM.on(FCMEvent.Notification, async notif => { console.log('notification payload', notif); }); out of the component lifecycle works the way it is expected with no problems. At least for me.

Example:

import { AppState, Image, TouchableOpacity, Text, View } from 'react-native';

import FCM, { FCMEvent, RemoteNotificationResult, WillPresentNotificationResult, NotificationType } from 'react-native-fcm';

FCM.getInitialNotification().then(notification => { console.log('initial notification', notification); });

FCM.on(FCMEvent.Notification, async notif => { console.log('notification payload', notif); });

class PushNotificationManager extends Component { .... }

export default PushNotificationManager;

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/evollu/react-native-fcm/issues/305#issuecomment-348344829, or mute the thread https://github.com/notifications/unsubscribe-auth/AA6QMLe8Sk_dQNV3hLwj6Wj31d7I16mOks5s7y89gaJpZM4L3-0d .

[jqn]

correct, after the app is killed and boots again getInitialNotification could return something similar to the following:

this still needs to be handled with a special filter, but notice the previously received notification is not longer there making that process easier.

[Ashwin-Mothilal]

But in the example sample-fcm-client the initial notif is stored in a state. So the thing is where should we use it? In the parent Navigator or outside of component or using it in a state?

[evollu]

@Ashwin-Mothilal it is up to you. it doesn't have to be in a state if you consume it right away