[flutter_local_notifications] Add getActiveNotificationMessagingStyle

[emersion]

This allows fetching an active notification's StyleInformation.
A typical use-case is appending a new Message to a MessagingStyle
when receiving a push message.

---

ATM this is pretty incomplete and only covers my exact use-case. Would you be interested in such a feature?

[MaikuB]

As this is about returning style information, unless it can be made more generic so it applies to all the other styles then I'd say it'd be something you'll need to keep in your fork. From what I also saw, it seems like the other notification styles don't support this either. For this to be included in the plugin, I would think this should be done via a new Android-specific API call within the Android-specific implementation of the plugin https://pub.dev/documentation/flutter_local_notifications/latest/flutter_local_notifications/AndroidFlutterLocalNotificationsPlugin-class.html

This would mirror how there's a separate API call to get the messaging style information though I know this in case it's slightly less efficient as the Android API to do so requires passing a notification object but from the Dart API, it accepts a notification id and/or tag that will results in an Android API to get the active notification and then do another Android API call to extract the messaging style information. Whilst less efficient, I would think should be ok as retrieving the messaging style information would then be something consumers of the plugin opt into as opposed to be being forcefully done for each active notification. Also avoids potentially bloating the Dart class for the active notification with various platform-specific properties. Thoughts on this?

[emersion]

As this is about returning style information, unless it can be made more generic so it applies to all the other styles then I'd say it'd be something you'll need to keep in your fork

This approach is already generic, ActiveNotification.styleInformation is not a MessagingStyleInformation, it's a StyleInformation.

From what I also saw, it seems like the other notification styles don't support this either

Right, that's a TODO. Not sure I'll find time to type up all of the glue code for all style TBH.

avoids potentially bloating the Dart class for the active notification with various platform-specific properties

ActiveNotification is already bloated: things like channelId and tag are Android-specific. In the first place getActiveNotifications only works on Android (and needs to be called on the AndroidFlutterLocalNotificationsPlugin). So I don't think it's a big issue.

[MaikuB]

This approach is already generic, ActiveNotification.styleInformation is not a MessagingStyleInformation, it's a StyleInformation.

I was referring to doing the wiring up so it works for all the other styles. I know this was a draft so could have been why you didn't get to it yet. Sounds like you have also misunderstanding given the following response too

Right, that's a TODO. Not sure I'll find time to type up all of the glue code for all style TBH.

What I was saying is that from what I saw in the native APIs is that it looks like you wouldn't even be able to do the "glue code" for all styles as it looks like it's not possible to do a similar thing for every other style. In other words, this only works for messaging style so I would say it's another reason why it makes more sense that returning such info is done via another API call

ActiveNotification is already bloated: things like channelId and tag are Android-specific. In the first place getActiveNotifications only works on Android (and needs to be called on the AndroidFlutterLocalNotificationsPlugin). So I don't think it's a big issue.

I know what you mean though however had to weigh up if it was worth separating those into its own class given the number of platform-specific info being returned. The other difference is those two properties you mentioned are more core information in helping to identify a notification though, at least with tag

[emersion]

Hm indeed, Android is missing the APIs to introspect other styles.

[emersion]

I've updated the PR, was this what you had in mind?

[MaikuB]

Yep it is though I noticed a todo comment on returning the icon. Was that so you could check if this is what I had in mind before going further? Another thing to add is an optional tag parameter to the Dart method as a notification can be uniquely identified via id only or using a combination of id and tag

[emersion]

Yep it is though I noticed a todo comment on returning the icon. Was that so you could check if this is what I had in mind before going further?

I'm not sure how we can handle icons. Android only supports fetching URI icon data (and maybe resource icon data, not sure). Other icon types can't be fetched.

Would you be fine adding support for URI icons and documenting that other icon types can't be fetched?

Another thing to add is an optional tag parameter to the Dart method as a notification can be uniquely identified via id only or using a combination of id and tag

Good point, fixed.

[MaikuB]

Would you be fine adding support for URI icons and documenting that other icon types can't be fetched?

Yep this is all based on what is supported by the native APIs so there's not much choice there and even though using the APIs directly would run into similar problems. With resource icon data. It looks a resource id can be returned, in which case this can be converted to a Uri similar to what's in the example app at

flutter_local_notifications/flutter_local_notifications/example/android/app/src/main/kotlin/com/dexterous/flutter_local_notifications_example/MainActivity.kt

Line 26 in 83c975b

private fun resourceToUriString(context: Context, resId: Int): String? {

. Note the code there is in Kotlin but should be able to do the same thing via Java too

[emersion]

All right, I've applied the changes.

[MaikuB]

Thanks for making more changes on this. I noticed this actually isn't working whilst testing so left comments around areas that I believe are the cause of the problem. With this in mind, I'd propose updating the example app with another a scenario using the messaging style that calls this new API. This example would just use the supported icon types (drawable and content uri) and helps facilitate testing in addition to showing how it could be used

[emersion]

Fixed the bugs, and added an example.

[MaikuB]

Thanks so much!