fix(ios): Remote issues: #1041 / #1096 onForegroundEvent() and getInitialNotification() #1118
Conversation
LunatiqueCoder
changed the title
…ent() and getInitialNotification()
…remote-onForegroundEvent-getInitialNotification' into bug/invertase#1109-invertase#1096-remote-onForegroundEvent-getInitialNotification
|
Hey @LunatiqueCoder 👋 ! Haven't hacked on things with you in a while, good to see you I need to focus first on making sure Notifee is compatible with react-native 0.76 as I believe we have New Architecture incompatibilities even with the compat mode But right after that I was planning on tackling all of these issues related to FCM delivery and events not firing and such - and it looks like you have beaten me to it with this PR This is an area I really only want to change once (or...one more time) though so I need to think pretty deeply about how exactly this should work (should it consume the initial notification or not? how exactly should it interoperate with react-native-firebase? etc). So please be patient as it may be a little bit before I get to this, but it is pretty important to get right and I'm excited to see you've already thought through it with this patch here |
|
For one specific question:
The app is started and brought to the foreground and I believe a Notifee event handler is called, to deliver the event? |
|
@mikehardy 🍺 Hehe, long time indeed. Happy to talk to you again Click to see devs chit chatI 'm still tinkering, but I was very excited to see I might have fixed some Github issues while I was working on my stuff, especially when I saw you're a core contributor here as well.I'm also planning to open source an Expo config plugin for Notifee's iOS remote notifications. Basically it follows these steps here: https://notifee.app/react-native/docs/ios/remote-notification-support Anyway, back to our issues:
EDIT: ☝️ Updated first post with answerAs a side note, since We ended up using this following snippet with Firebase Node.js SDK import type {NextApiRequest, NextApiResponse} from 'next';
import type {Notification} from '@notifee/react-native/src/types/Notification';
import {AndroidImportance} from '@notifee/react-native/src/types/NotificationAndroid';
import {MulticastMessage} from 'firebase-admin/lib/messaging/messaging-api';
const notifeeOptions: Notification = {
id: Date.now().toString(),
title: 'Title',
subtitle: 'Subtitle',
body: 'Main body content of the notification',
android: {
channelId: 'default',
importance: AndroidImportance.HIGH,
pressAction:
},
ios: {
sound: 'default',
criticalVolume: 1,
critical: true,
foregroundPresentationOptions: {
badge: true,
banner: true,
list: true,
sound: true,
},
},
};
const message: MulticastMessage = {
// ✅ We can continue using local notifcation for Android
// 👍 while triggering iOS remote notifications from `apns`
data: {notifee_options: JSON.stringify(notifeeOptions)},
tokens: [],
android: {
priority: 'high',
},
apns: {
payload: {
notifee_options: notifeeOptions,
aps: {
alert: {
// 🚧 This is needed to trigger an alert/remote notification only for iOS
// 👍 but Android will continue using data-only notifications
title: 'Hello World',
},
mutableContent: true,
},
},
},
};
export default async (req: NextApiRequest, res: NextApiResponse) => {
try {
await admin.messaging().sendEachForMulticast(message);
res.status(200).end();
} catch (e) {
res.status(400).end();
}
}; |
|
FYI, I just tested the fix, and on my side, the first index in the patch differed from mine. Also, after some JS debugging, the call to |
|
Hmm, just noticed those changes were made with |
|
I'm also on |
…Notification - call onForegroundEvent() when app starts from terminated state - same as getInitialNotification()
…planatory comment
| } | ||
|
|
||
| // Call onForegroundEvent() on Javascript side with payload: | ||
| [[NotifeeCoreDelegateHolder instance] didReceiveNotifeeCoreEvent:event]; |
There was a problem hiding this comment.
🚧 Update:
I found another funny issue with the patch :( But should be an easy fix. This is the workaround however:
useEffect(() => {
/** 🚧 Bug with Notifee patch
* if we don't call this, we don't get onForegroundEvent if app was opened
* from a terminated state by pressing notification
* @todo Remove once this is fixed:
* @link https://github.com/invertase/notifee/pull/1118 */
notifee.getInitialNotification();
const unsubscribe = notifee.onForegroundEvent(async ({ type, detail }) => {
});
return unsubscribe;
}, [dispatch]);
};
mikehardy
changed the title
|
Amazing work hope to see news about this PR soon 👀 thanks ! |
|
Did I just read "just learned Objective C and Swift in order to fix those issues." Great stuff man, looking forward to see this PR merged, thanks! |
|
when we can expect the latest version with the updated code? |
|
@TestWts2017 you can't. It is open source and I am always very clear with people - when you interact with open source you must abandon your expectations of release dates. If it is important to you, use patch-package and integrate the changes in your project directly, no need to wait |
|
☝️ the referenced issues above might be duplicated |
|
They probably are, most of the complaints in this repo are all actually the same complaint / disagreement with how it functions, or some ridiculously niche thing which is hard to solve 😆 Been traveling all week but will be back to work next week |
|
Hey there! I partly agree with this because the Notifee documentation can be pretty unclear, especially when it comes to integration. It often feels like you have to dig through issues or PRs to get answers. Also, I wonder why Invertase promotes Notifee in react-native-firebase if it’s considered niche? Notifee is such a powerful library and a great addition to any React Native project. Ideally, it should work seamlessly on both iOS and Android with Firebase—if not, maybe it shouldn’t be featured as an option! |
|
Just to answer one part: Notifee is not at all considered niche! However, a full screen notification is a niche case, as is a permanent notification attached to a foreground service of a niche type, as is scheduling exact alarms. Each of those is a niche feature just based on query traffic here related to them. Non-niche use is "I want to receive an FCM and post a notification, perhaps with styling and an image, in the foreground and background case" It just so happens that this PR is right in that area of work, which is great. But also why it needs careful consideration as it will affect the majority case. However, my mention of the other stuff as niche is not to say Notifee shouldn't be supporting it. And in either case, react-native-firebase had to eject the local-notification device API surface area specifically because all those niche use cases (which are each important to someone!) were a huge drag on the core purpose of react-native-firebase which is to wrap firebase APIs. It is not possible (we tried!) to support the local device notification APIs people want and all the firebase APIs in the react-native-firebase repos, we had to split it out, thus Notifee exists. And unfortunately, with the pace of device-local notification API change (typically in the form of increasing restrictions to curb abusive behavior from app developers...) and the pace of change of device-local power management which affects message delivery (typically in the form of increasing restrictions to curb abusive behavior from app developers...) there is no simple integration. Troubleshooting unfortunately always starts with a tree of questions of the form "okay, iOS or Android? okay is it a notification, data, or mixed FCM? okay, what version of the operating system?" and gets worse from there. There is no seemless unfortunately. The work in this PR should make it a great deal better though because yes, it is rough going right now. Hope that's sort of clear with regard to maintainer goals and repo motivation at least? |
|
I completely agree that separating Notifee from react-native-firebase was the right approach! I also understand the difficulty of meeting OS requirements for both Android and iOS—each has its own set of complexities. Over the past few months, I’ve read through many Notifee issues and comments to better understand how notifications work across platforms, and I want to acknowledge and appreciate all the hard work put into this package. I’m excited to see the improvements in the PR, as they’ll make these features more accessible. That said, I know that adding new functionality without impacting other areas is a significant challenge, especially given the wide range of use cases Notifee supports. Enhanced documentation, particularly around Firebase integration, could also help more developers avoid common pitfalls and make setup easier. I’ve noticed that this repo used to get frequent responses from you and other maintainers, so better documentation could help lighten that load too. Thanks for the insight—it really clarifies the goals and challenges behind Notifee! |
|
I know there is a lot of interest in this one and I am as well. Just wanted to let everyone know it won't sit forever but I'm still backlogged on urgent items - that is there is one repo left that still does not seem to be behaving well with new architecture at all in the form of @invertase/react-native-apple-authentication and I must get that working first. cocoapods/xcodeproj blowing up all react-native-firebase builds last week was unexpected and took time as well. There is one other new architecture issue here that came up where foreground services appear to freeze and I'll need to handle that as a regression before coming back to this, but once all the new arch stuff is done, this is first. It will happen but I'll appreciate the patience in the meantime |
|
Getting closer on this - apple auth qualified on new arch, and got reproduction scaffolding setup in react-native-firebase in order to test this stuff over the weekend invertase/react-native-firebase#8143 - there is methodical progress towards having real test coverage for all the foreground / background stuff. I continue to appreciate the patience |
|
Thanks man! This fix really helped!!!! |
|
I'm wondering if this PR also fix the problem where you can't update the badge in the |
|
Great library!!! |
|
@LunatiqueCoder thanks for the quick reply. Actually, I'm able to see notifications in iOS but when a notification comes and trying to log the payload then nothing happens, which means I think |
|
@TestWts2017 on iOS, you will not receive anything in EDIT:
This is an iOS issue. It is not an issue with Personally, I'm using shared group preferences to store background notifications within the notifications extension, and retrieve them on JS side with |
@LunatiqueCoder this sounds interesting but it is not so clear to me. Could you explain with more details? |
|
@LunatiqueCoder This patch make my app to crash when pressing on a local notification to open app in killed state. I'm using xcode 16.2, "react-native": "0.74.3", "@notifee/react-native": "9.1.1" |
|
@ng-ha "....and the stack trace from the crash is...." |
|
@mikehardy Sorry for the delayed reply. I had to reproduce the crash. The previous crash was more informative, with the specific location of the crash. It came from NotifeeCore+UNUserNotificationCenter.m, but I didn't save that stack trace. Here is the stack trace I got this time with "@notifee/react-native": "^9.1.8". Thank you in advance! |
|
Here is the stack trace with "@notifee/react-native": "9.1.1" |
👋 Hello!
This PR fixes
🙏 Please keep in mind I just learned Objective C and Swift in order to fix those issues.
What's changed?
onForeground()is called withgetInitialNotification()forPRESSandPRESS_ACTIONevents when app is opened from a terminated state.getInitialNotification()will return the correct payload on app start.onForeground()is called forDELIVEREDevents by removing this condition, but I have mixed feelings about it. Might need a deeper look.How to test
patch-package, in yourpatchesfolder create a file called@notifee+react-native+9.1.1.patch