Closed AnastasiiaSob closed 4 months ago
Its not that the app is in the background, its that the activity that hosts the flutter context is no longer resumed
and is paused
while another activity is on top. When that activity goes away the flutter activity will go from paused
to resumed
again. I recommend just using a flag to do the call once, or a timestamp to debounce it.
@rlepinski Thank you for your answer!
The described behaviour occurs only if the user chooses “don’t allow push notifications”. If the user allows it, it works fine.
Unfortunately, we need to ask the user every time the app is resumed about their push notifications status and forward it to the backend, so we can’t reduce the number of calls. Also using a timestamp to debounce causes the same problem, but later (according to the timestamp).
However, if I remove the part with Airship.push.enablePushNotifications()
the code doesn’t run in circles, and works fine. But then I am unable to access the user’s decision. I also used final isUserEnabled = await Airship.push.isUserNotificationsEnabled;
to get the choice of the user from a prompt and it works correctly first.
But if the user changes their decision in the settings, Airship can’t recognise it and stays by the first made decision.
On iOS it works fine, so I assume the problem is in the Android code implementation? Is there a right way to implement the functionality for Android at all or do I need some special code, different from iOS? Unfortunately, I didn't find any information on it in the official Airship documentation.
You can use https://github.com/urbanairship/airship-flutter/blob/main/lib/src/airship_push.dart#L42 this will return an object with the various enable flags that you can inspect.
enablePushNotifications
is the call that starts an activity on top of flutter to try to enable notifications. On Android, there is no way to know if you can prompt or not so you have to just try. Its an unfortunate API. You can prompt up to 2 times on most devices. After that there is no reason to prompt again. I would suggest only trying to enable once on start, after that make a place in the app to try again later. If thats not good solution, I think you can detached
state to check if the app is actually in the bg instead of just paused. Maybe have a flag that only resets on bg to dedupe foreground prompts?
Airship will pick up the change if they change the setting in the app settings. We check the current status every app foreground.
Hello, This issue has been inactive for a while now so I'm closing it. Feel free to reopen if you still have an issue.
❗For how-to inquiries involving Airship functionality or use cases, please contact (support)[https://support.airship.com/].
Preliminary Info
What Airship dependencies are you using?
airship_flutter: ^7.3.1
What are the versions of any relevant development tools you are using?
Flutter 3.16.5 Dart 3.2.3 firebase_analytics: ^10.4.1 firebase_core: ^2.13.0
Report
What unexpected behavior are you seeing?
The push notification status is inconsistent with the status in settings on Android. The code also running in circles, and is unusable, it "reloads" every second. So the code below is running infinetly. (After debugging I see that the app will be set in background but in fact it is always in foreground). The problem occurs only on Android, on iOS the same code works fine.
What is the expected behavior?
I am able to send a prompt to user if they would like to receive push notifications or not, and then access their choice in code and use it in it.
What are the steps to reproduce the unexpected behavior?
The combination of the request for user choice for push notification when the user set the app in foreground:
if (state == AppLifecycleState.resumed) { Airship.push.setUserNotificationsEnabled(true); Airship.push.enableUserNotifications().then((status) => { getChannelId().then((channelId) => { pushAllowed = status!, .... ), }), }); }
Do you have logging for the issue?
No. On iOS this code works just perfect. The problem comes only on Android.