[FCM] [Request] Support for handling "category" field in push notifications on Android (matching iOS behavior)
On iOS, the "category" key in push notifications is well supported in Kastri, allowing developers to define behaviors based on specific notification categories. However, on Android, there is currently no equivalent way to access or process this property.
When using Firebase Cloud Messaging with Delphi applications, it is common to include "category" inside the "data" block of the push message. Being able to capture and handle this category directly on Android would be very useful to maintain functional parity with iOS.
However, on Android, there is currently no equivalent way to access or process this property
That's because there is no such thing as categories on Android. The closest equivalent are channels, where messages can have a different sound, vibration and importance level depending on which channel they are assigned.
I do have a plan however, to enhance channel support in the current implementation
Thank you for the clarification regarding the use of "category" on Android and how it differs from iOS. I understand that Android doesn't natively support "category" in the same way, and that notification channels are the closest equivalent at the system level for configuring sound, importance, and vibration.
However, my main goal is not to control the system behavior of notifications, but rather to trigger a specific action inside the app when the user taps a push notification, based on a value such as "category" sent in the data block of the message.
It would be very helpful if Kastri could provide a built-in way to handle this kind of interaction—for example, by exposing an event when a notification is tapped, with access to the received data, or by offering a helper to route behavior based on fields like "category".
This would allow us to replicate similar logic to what already exists on iOS with UNNotificationCategory, even if it's not a native concept on Android.
Thanks again for the great work and for considering future improvements both in channel support and in the handling of notification tap events.