We’d love to do this, but we’ve only had a few people ask for this. We’re going to keep our eye on this one for future review. I may actually try to do this on my own as an experiment. Stay tuned.
There's also this tutorial: https://fireship.io/lessons/flutter-push-notifications-fcm-guide/
Frankly, this will be very important. The push notification solutions in Flutter are pretty weak at the moment, with no background support and so on. We've moved from Xamarin Forms to Flutter for performance reasons and the groundswell of support is pretty astonishing.
There is a recent OSS package that is supposed to help with this: https://github.com/nextbss/flutter-push-notification
Not sure if it's a keeper, I haven't tried to work with it yet.
In my case I had this whole thing working in XF. If the app was in the foreground, it caught the notification and decided what to do. If it wasn't running, then the background application could launch it or just drop something into the notification center.
It seemed to work pretty well. My understanding of the Flutter messaging is that it *all* runs through FCM, even on iOS devices.
I much prefer ANH and the direct to device approach, but there's very little documentation on how to do it properly for Flutter.
If you need help with this, I can try to work with it. TIA
FWIW - I am in the middle of this right now.
We want to provide get installations by tags, and I’d love to understand more about your scenarios around delete installations by tags and get/delete by push channel if you don’t mind sending me an email at firstname.lastname@example.org. Thanks!
This is currently not on our roadmap. You can retrieve this value by making a call through the Graph API. If this is needed for your scenarios, please continue voting and we will review at a later date.
If you're set up to use email for the login AND you access that the first email in the EMAILS claim that comes back is probably their login name, then you can extract it on the client side.
And that's silly.
To do it right, there needs to be an actual claim that contains the login name. This would work for all scenarios.
I had to make a workaround for this - I access the graph during login. It works, but it adds an extra 500ms to each login and I have to do it server side if I want a solution that can choose either user name or email.
I know it's not planned, but it should be.