Feedback requested: decoupling notification channel creation

[MaikuB]

This plugin currently provides different ways to manage notification channels, which is a concept specific to Android 8+

1. include the details as part of every notification request on Android. This enables the notification channel to be created right before the notification is shown. When a notification channel is created, this is when it appears in an app's settings. Delaying the creation of notification channels by this approach would therefore delay when the channel shows up in settings and is why this approach was allowed
2. use APIs like createNotificationChannel. This allows the notification channel to be created ahead of time for scenarios that need it e.g. FCM

In trying to cater for having notification channel creation be delayed until the first notification as per approach 1, this required developers to include notification channel details as part of every notification request on Android. This leads to duplication. If the plugin changes to assume the channel is created beforehand, then I believe that delaying channel creation would no longer be possible. This would however, lead a cleaner API with the possibility of have the plugin initialisation API expanded so that initialisation could create the required notification channels and potentially the notification channel groups too.

Feedback is requested from the community on if they'd would be ok with this. Please use a thumbs up reaction on this post if you'd be ok with this and thumbs down if you're not. More detailed feedback can also be provided by replying to this thread

[rocboronat]

I would be open to removing the channel creation from the Flutter side and just doing it on the Android side. If we do that, all the channels will be created prior to using them, and on the Flutter side you just need to say which channel ID is the notification going to use. The bad part of it is that you should explain how to do it in the readme, and maybe iOS-only won't be comfortable with it.

[MaikuB]

@rocboronat could you elaborate more on what you mean? Are you referring to how the changes would require developers to write their own Java/Kotlin code for this? If so, this change wouldn't require this as I had mentioned in my original post that there's an API provided by the plugin to do and how the plugin can be expanded so that plugin initialisation can deal with channel creation too

[myselfuser1]

This will help https://www.youtube.com/watch?v=aQTvI8L-mZs

[rocboronat]

Hey, sorry I didn't say anything until now! Sorry @MaikuB 🙇

Yes, what you say is good too. Note that people will have to update the notification channel names and descriptions every time the app is open, in case they change the language of the device, and that's it.

[MaikuB]

Anyone able to assist with making the change then? My initial thoughts would be that the initialize method of the plugin can provide a way to specify a collection of notification channels that the app requires. As initialize should be called every time the app runs, this should cover what was mentioned by @rocboronat's last message to account for language changes etc

[rocboronat]

Sorry... I have negative free time now 😞

[saibotma]

From my point of view, this plugin should keep notification sending and channel creation separated. This caused a lot of confusion when I initially added this plugin to our application.

I have the following proposal: Channels must be created by hand using AndroidLocalNotificationsPlugin.createNotificationChannel, but should never be created automatically when calling FlutterLocalNotificationsPlugin.show. This way, the developer can either create all notification channels on app start or create a custom utility (extension) function FlutterLocalNotificationsPlugin.createChannelAndShow that creates the channel short before showing the notification, which would then still support delaying channel creation. This extension function could even be added to the plugin.

My initial thoughts would be that the initialize method of the plugin can provide a way to specify a collection of notification channels that the app requires.

I don't think that this is necessary, and the better solution is the one showed above, because of the before mentioned reasons and also, because channel names have to be updated by hand on language change anyway (https://stackoverflow.com/a/46670618/6172447).

To support legacy Android versions, without channel support, AndroidNotificationDetails should take an optional legacyConfig parameter of type AndroidNotificationLegacyConfig. AndroidNotificationLegacyConfig should contain all the config options that can be configured for a notification channel.

This is a very rough draft. I can create a PR for this if you want, though.

Cheers 🍻

[MaikuB]

I don't think that this is necessary, and the better solution is the one showed above, because of the before mentioned reasons and also, because channel names have to be updated by hand on language change anyway

The problem with trying to steer developers towards AndroidLocalNotificationsPlugin.createNotificationChannel is that it's on the Android implementation side of the plugin as it aligns with platform-specific APIs only being exposed via platform-specific implementations. FlutterLocalNotificationsPlugin is the cross-platform API that majority of developers would likely use for their apps. By having FlutterLocalNotificationsPlugin.initialize updated, the API for creating channels is more discoverable , and it could also support taking in a collection of channels that would allow apps to specify upfront the channels and channel groups required via the AndroidInitializationSettings class.

In case it was missed, FYI AndroidLocalNotificationsPlugin.createNotificationChannel already exists in the plugin that they could create a custom utility function if needed. Note however, that what you mention there is for the Dart side. It doesn't support if someone wanted to delay channel creation for a scheduled notification as those are shown in the future. Trying to properly decouple this channel creation means it's no longer possible delay channel creation for all scenarios. Personally, I believe this is fine since channels show up in Android settings so is separate to the app and daresay most users wouldn't go to look at the channels

To support legacy Android versions, without channel support, AndroidNotificationDetails should take an optional legacyConfig parameter of type AndroidNotificationLegacyConfig. AndroidNotificationLegacyConfig should contain all the config options that can be configured for a notification channel.

I don't fully understand what you're proposing here but this still sounds like it would still keep channel-specific information in AndroidNotificationDetails when the purpose of the decoupling proposed here would actually remove that information. Exception here would be the handful of properties like playSound that on Android 8+ is tied to a channels but on older Android versions is part of the notification itself. I'd prefer those stay where they are with an update to the docs as structurally they still align to the Android notification API structure as opposed to being properties in a nested class. It would allow an Android develop to more easily transition to APIs from this plugin as a result. The notion of legacy config would therefore end up adding a new concept a dev needs to track and can add more confusion around what is and isn't legacy as IMO it's rather vague when the Android notification APIs evolve over time and newer Android versions being released