Open mfrey43 opened 3 weeks ago
I think the best place for this would be in https://github.com/urbanairship/capacitor-airship/blob/main/src/types.ts#L95 to expose a permissionStatus: granted|denied|not_determined
But to do that we will have to do some work on the native SDK to make it possible to expose that, so it will take a few weeks. Exposing a method to either enable notifications or navigate to system settings would be an easier lift
Just an update on this, we have the changes needed on the iOS SDK pending a release hopefully this week. Once that is out ill be able to work in the notification permission to the status object and make it possible to provide options to enableUserNotifications
to link to the system settings if already disabled by the user
I have some working code for Android, just need to wire up iOS next. I should be able to get this out on Monday if I don't run into any issues.
Going to have enableUserNotifications({ fallback: "settings" })
which will:
Found some issues with testing this:
denied
status is a bug.enableUserNotifications
that I am unable to make the same without another SDK update. On Android, enableUserNotifications()
will prompt and if granted, enable notifications on Airship. If denied it wont enable on Airship, so if the user goes into settings then comes back it won't be enabled on Airship still. iOS works properly here. Due to the above, I am going to try to get another SDK release out ASAP but this plugin feature is delayed til then.
Preliminary Info
What Airship dependencies are you using?
"@ua/capacitor-airship": "2.0.1",
What are the versions of any relevant development tools you are using?
Android Emulator Properties avd.ini.displayname Pixel 8 API 34 AvdId Pixel_8_API_34
targetSdkVersion = 34 firebaseMessagingVersion = '23.3.1'
Report
What unexpected behavior are you seeing?
The setUserNotificationsEnabled method only prompts the user once and has no effect after. That means if the user manually disables notifications in the native app settings, there is no way to enable it again from within the app. This is the expected behaviour on iOS and Android and I as the developer should handle it manually. The information I'm missing from this plugin is if the user can still receive a prompt or not.
What is the expected behavior?
The getNotificationStatus should not just return a boolean if notifications are allowed at the system level but also if the user can still receive a system prompt to enable them. For comparison, the official capacitor push plugin can return this info as 'granted', 'prompt' or 'denied'. This is what I am using currently. If the status is 'denied' I forward the user to the app settings where they can manually enable them. It would be great if I could solely rely on this plugin instead because having them in parallel makes the installation more complicated.
What are the steps to reproduce the unexpected behavior?
Same on Android & iOS
Do you have logging for the issue?
No