🐛 [firebase_messaging] In terminated state on iOS main is called instead of onBackgroundMessage #7407
Comments
vishnukvmd
added
Needs Attention
vishnukvmd
changed the title
|
@vishnukvmd |
darshankawar
added
blocked: customer-response
|
Hey @darshankawar , I've already made sure that the app is never manually terminated. |
google-oss-bot
added
Needs Attention
|
@vishnukvmd |
darshankawar
added
blocked: customer-response
|
@darshankawar Since a server/script is required to send out an intermittent push, an example that includes the service would be non-trivial. This is reproducible behavior for all pushes with a data-only message that looks like this: message := &messaging.MulticastMessage{
Tokens: tokens,
Data: map[string]string{"action": "sync"},
APNS: &messaging.APNSConfig{
Headers: map[string]string{
"apns-push-type": "background",
"apns-priority": "5", // Must be `5` when `contentAvailable` is set to true.
"apns-topic": "io.ente.frame", // bundle identifier
},
Payload: &messaging.APNSPayload{Aps: &messaging.Aps{ContentAvailable: true}},
},
}The message results in an app startup 100% of the times, so there are no delivery issues. The problem here is that there's no way to identify if the app was started in the foreground, or if it was started as a result of a background push. |
google-oss-bot
added
Needs Attention
|
Keeping it open for further insights from the team on correct / expected behavior in this case. |
darshankawar
added
plugin: messaging
platform: ios
|
Any update on this issue? We are also facing this issue. The main flutter application starts running in the background and it is causing the side-effects. The expected behaviour should be to execute only the high level function mentioned in We noticed that on background application launch, the execution gets stopped if any Screen navigation code is present like So one workaround we found was to launch the application in dummy screen and automatically shift to FirstScreen/HomeScreen after 0.1 seconds of delay. We need to remove the screen navigation animation in this case. Now if user opens the application it is working, user would not notice the dummy screen and when application is launched in background because of data-only notification, the main app execution is stopped but the high level function is still working. |
|
Hi, do we have any update on this issue? |
|
Not sure if this is relevant. In the react-native plugin, it mentions that the app would get mounted from the background handler. There is some headless check. https://rnfirebase.io/messaging/usage#background-application-state |
|
@darshankawar Any update on this issue? |
|
@raphire08 Can you please share a few details on how did you solve the main method execution? Your help will be much appreciated, thanks. |
|
@Lyokone Were you able to test it? Actually it is reproducible in the example app as well.
|
|
Hey @adar2378 |
|
@Lyokone Is there any way to detect if the it was triggered(calling main method) by background isolate, or a normal user is opening the app? |
|
This bug holds back the feature to show user action when app is terminated as the |
|
@adar2378 void main() {
// fireabase initialization
// firebase messaging on background call
runApp(const MyApp());
}
class MyApp extends StatelessWidget {
const MyApp({super.key});
@override
Widget build(BuildContext context) {
return MaterialApp(
title: 'Flutter Demo',
theme: ThemeData(
primarySwatch: Colors.blue,
),
home: const DummyScreen(),
);
}
}
class DummyScreen extends StatefulWidget {
const DummyScreen({super.key});
@override
State<DummyScreen> createState() => _DummyScreenState();
}
class _DummyScreenState extends State<DummyScreen> with WidgetsBindingObserver {
bool isLaunched = false;
@override
void initState() {
super.initState();
WidgetsBinding.instance.addObserver(this);
if (WidgetsBinding.instance.lifecycleState != null) {
if (WidgetsBinding.instance.lifecycleState == AppLifecycleState.resumed) {
openHomeScreen();
}
}
}
@override
void didChangeAppLifecycleState(AppLifecycleState state) {
super.didChangeAppLifecycleState(state);
if (state == AppLifecycleState.resumed) {
openHomeScreen();
}
}
@override
void dispose() {
super.dispose();
WidgetsBinding.instance.removeObserver(this);
}
Future<void> openHomeScreen() async {
if (!isLaunched) {
isLaunched = true;
await Future.delayed(const Duration(milliseconds: 100));
if (mounted) {
// navigator push
}
}
}
@override
Widget build(BuildContext context) {
return Container();
}
}
|
True, it is a problem to handle user action in terminated state for iOS |
Thanks, will check |
|
is there any solution ?? |
|
Oh my God, it's been 2 years and it's still not resolved? |
Unfortunately yes 😥 |
|
Many years have passed. Please tell me why it is not being fixed... |
|
did any one find a way to check whether the app open from background or normal open ? |
please check |
thanks for your reply , but its the same issue as this, but not answering my question ... i found : |
I'll check it out |
|
I think the firebase team should collaborate with Flutter team resolve this. It's one of the core features I think when it comes to messaging app and replying from notifications directly etc. |
|
Hello, any updates on this issue? the |
|
This issue still occurs in firebase_messaging: ^14.6.8. |
|
I paste the solution here. Hope it works on you guys also |
|
This issue still occurs in firebase_messaging: ^14.6.8. |
|
Bug report
Describe the bug
On iOS, registering a top-level function with
FirebaseMessaging.onBackgroundMessagedoes not guarantee that it will get invoked when a data-only push (without a notification payload) is received when the app is dead.Instead, the top-level
mainfunction is called without theRemoteMessageobject.Steps to reproduce
Steps to reproduce the behavior:
BackgroundMessageHandlerwithFirebaseMessaaging.onBackgroundMessagethat simply logs the incomingRemoteMessageto a file.ContentAvailablepush to this device.mainthat logs it's invocation to the same file.BackgroundMessageHandleris never called when the app is dead.After 24 hours if you check the log file, you will observe that as long as the app is alive the
BackgroundMessageHandlerwill be called, and otherwise themainfunction will be called.Expected behavior
BackgroundMessageHandlershould always be called.Additional context
On iOS, it is important to not do heavy operations when the app is in the background. Since the
mainfunction is now being invoked on background pushes, there is no way for application developers to understand if the app was started by the user or by a background push. If there is some other way to determine this, please let me know, we would be grateful.Flutter doctor
Run
flutter doctorand paste the output below:Click To Expand
Flutter dependencies
Run
flutter pub deps -- --style=compactand paste the output below:Click To Expand
The text was updated successfully, but these errors were encountered: