Does Firebase Cloud Messaging provide any way for a user to retrieve old messages? From the documentation, it looks like messages are thrown away once the client receives them.
I ask because I'm looking to build an IM functionality in my app, and a user needs to be able to see past messages when he closes the app and then opens it again.
Update from the comments here:
Unfortunately this just got worse as of 20 Nov 2017 when FCM Diagnostics was removed from Google Play Console. "I understand that FCM Diagnostics was critical to you in troubleshooting FCM messages but unfortunately this has been deprecated. Rest assured that we are working on something better that should allow a lot more insight into what went wrong during message delivery, but we can’t share any timelines. I’ll share your concern internally and continue to work to get this new feature out.
FCM's main purpose is for Push Notifications. So to answer directly, No. FCM doesn't keep track of the message you send for you. There is a diagnostics and statistics tool you can use, but I don't think this is the one you're looking for.
IMHO, it's the developer's responsibility to keep track of the details they need. In your scenario, you would be needing a database to store the message details themselves, wherein you can make use of Firebase Realtime Database. There's actually a sample Codelab about creating a simple chat app using Firebase here.
Related
Update: Google Bug Report Description
(as suggested by google dev advocate in comments on answer 1, filed a bug report; updating the content here since it more succinctly and precisely describes the problem)
I do not need or want to show any notifications to my user. And many users are not willing to give notifications permission because they assume they will start seeing notifications.
But I wish to push data to my web page from the server. The web page is active and in the foreground. This is the classic use case that Web Sockets were designed for.
I understand that I could write my own web socket server and somehow try to scale it, or go to some other third-party for an outsourced scalable web socket push solution.
But, isn't this is a very common "sub-use-case" of the messaging that Firebase Messaging is targeted towards? Therefore shouldn't Google support this use case? I can't see any fundamental technical show-stoppers, but since Google is so smart, please do enlighten me if I am missing something on why this cannot or should not be done.
Original StackOverflow Question Text:
I don't need background notifications or service workers. All I want is to send data to the web page when it is currently loaded and in the foreground.
Websockets do not need any permission but they need a websocket server and maintenance. It is difficult or expensive to scale it.
Firebase solves the problem fundamentally but I don't see why it must require a user to give notifications permission even though I only want to push data when the page is loaded; not in the background.
The problem is that Firebase Messaging is only using 1 method to deliver notifications. That is the Push API specification spec, and that specification (wrongly and unfortunately) does not allow a service worker to receive messages without the user allowing an unrelated permission to show notifications.
The fix would be for the Firebase Messaging team to provide a different way to deliver messages to active web pages -- long polling, or websockets.
But it would be extra work for them, and may be not enough people are requesting it.
It's to protect the user's preferences about what your app is allowed to do. The way push messaging works on browsers is by using a service worker. Even though you say you don't need a service worker, you are actually making using of it when using Firebase Cloud Messaging in your app.
Given that, the prompt is necessary because the browser doesn't know what you intend to do with that push message. If the user doesn't trust your app, they should have the right to limit what it can actually do, especially when they're not using your app. Mobile operating systems (iOS, Android) are the same way.
I am make chat feature with Flutter and Firestore backend.
Every message is new document in Firestore collection with UID and text field. Chat is 1:1 and random so no know who user will talk to before enter chat. DocID in chat collection are all auto-id.
I have read can use topics to manage send notification. This should be easier than use individual device fcm token.
Anyone know how to implement use topic for this random 1:1 chat app?
You can definitely use a separate topic for each 1:1 conversation, for example with the naming scheme I described here: Best way to manage Chat channels in Firebase. But there are some things to consider which, as Doug already pointed out in his comment, leads most developers to not solely use FCM for their chat apps.
For example: FCM topics are not secured. This means that anyone who finds out the topic ID can subscribe to it, and thus overhear the 1:1 conversation. And while you can generate topics that are hard to guess, you should not rely on not knowing the topic ID as a security mechanism.
Another reason to consider alternatives is that FCM messages are transient: once they are delivered there is no longer any trace of them. With your current Firestore implementation you can query the database to get all messages to show, while with a pure FCM implementation you will have to build your own database (if that is required for your app).
For these reasons most chat apps I know of use a combination of FCM (for push notifications) and an online database (for persistence) as their backend services.
I found Frank's comment really interesting about the "sorted userID composed key". I would probably use that as the chat key in the database (realtime/firestore), however, for the notifications I think I would still use a topic for each user - this way I would be able to avoid notifying the user who posted the message. If that wouldn't be an issue, then just go for just one topic per chatroom.
Also mentioning Frank, I would probably use extra keys in all topic names to make them really difficult to guess. (but add that later so you don't get distracted with non core stuff)
In this answer you have an example of how to post the notifications with a onCreate trigger to a topic (from a functions backend).
In the flutter code, you can use subscribeToTopic from the firebase_messaging plugin to start listening to a topic.
Note: if your app will support user log-off [probably it will :)], then you'll also have to delete the token in the device to avoid receiving notifications from the last logged user.
Update: Google Bug Report Description
(as suggested by google dev advocate in comments on answer 1, filed a bug report; updating the content here since it more succinctly and precisely describes the problem)
I do not need or want to show any notifications to my user. And many users are not willing to give notifications permission because they assume they will start seeing notifications.
But I wish to push data to my web page from the server. The web page is active and in the foreground. This is the classic use case that Web Sockets were designed for.
I understand that I could write my own web socket server and somehow try to scale it, or go to some other third-party for an outsourced scalable web socket push solution.
But, isn't this is a very common "sub-use-case" of the messaging that Firebase Messaging is targeted towards? Therefore shouldn't Google support this use case? I can't see any fundamental technical show-stoppers, but since Google is so smart, please do enlighten me if I am missing something on why this cannot or should not be done.
Original StackOverflow Question Text:
I don't need background notifications or service workers. All I want is to send data to the web page when it is currently loaded and in the foreground.
Websockets do not need any permission but they need a websocket server and maintenance. It is difficult or expensive to scale it.
Firebase solves the problem fundamentally but I don't see why it must require a user to give notifications permission even though I only want to push data when the page is loaded; not in the background.
The problem is that Firebase Messaging is only using 1 method to deliver notifications. That is the Push API specification spec, and that specification (wrongly and unfortunately) does not allow a service worker to receive messages without the user allowing an unrelated permission to show notifications.
The fix would be for the Firebase Messaging team to provide a different way to deliver messages to active web pages -- long polling, or websockets.
But it would be extra work for them, and may be not enough people are requesting it.
It's to protect the user's preferences about what your app is allowed to do. The way push messaging works on browsers is by using a service worker. Even though you say you don't need a service worker, you are actually making using of it when using Firebase Cloud Messaging in your app.
Given that, the prompt is necessary because the browser doesn't know what you intend to do with that push message. If the user doesn't trust your app, they should have the right to limit what it can actually do, especially when they're not using your app. Mobile operating systems (iOS, Android) are the same way.
I've been looking around for a while now, but haven't been able to find a way to send out notifications about Firebase crashes. I have found/enabled email notifications for these crashes, but I was hoping for an API that I could use to integrate them into Slack or something a bit more actionable than email. Is there any way to do this?
firebaser here
You will automatically get emails upon certain type of crash reports: new crash types and regressions. For example if a type of crash that you had fixed reoccurs, the system will send you an email to alert you to this regression.
But there is no API (yet) for getting called when a crash is registered on the server. It sounds like a good feature though, so I'd recommend that you file a feature request.
The best you can do right now is to trigger such an action from the client that reports the crash.
I know that Firebase has recently added support for Push Notifications and while this is a great thing, I only seem to be able to send push notifications manually via the Notifications Panel.
What I'd like to do is to send push notifications within a user scope...Let me explain that. Each User in my App has an account and then each user can join a group. Within this group the user can perform tasks and has a list of chores to do. Now when certain tasks are due for example I want to remind the user of doing it with a push notification. For 1-10 I might be able to pull this off manually, but is there a way to dynamically based on the data in the Database send out Push Notifications?
I know that certain Push Notifications can be created using the Analytics tool such as "Hey you have not visited for 3 days, please come back whatever"... but I'd like to register push notifications such as "I just created a task, this task needs to be done within 3 days. Remind me in 3 days if the task is still not done".
Is this possible with Firebase or do I need to have my own server connecting to Firebase and handling those events?
-xCoder
You need to implement FCM in your client and in a server. Let me put this straight:
First, you need that your client, or app, to register into FCM and get a FCM token that will be used to identify that device uniquely.
Then, store that token wherever you like. It can be into firebase database or other server you may like. I recommend you to store it into firebase if you are using it as a database for your users; that's my case.
Also, you need to implement a http or xmpp server in order to send FCM messages to your registered devices containing the data you are interested in. For example, you can implement a Google App Engine endpoint (can be done with Android Studio and Java) that is quite simple or a NodeJS module, depending on your preferred language.
If you are using Firebase as database you can connect from your server with the appropriate SDK and get the FCM tokens you want from your users, and then send the message to those with data. Don't forget to secure your serve.
The way you implement your server algorithm to send FCM messages depends on your app purposes.
Hope it is clear enough for you. Also you can find all the documentation with a short video that explains the general structure here: https://firebase.google.com/docs/cloud-messaging
You can use cloud functions to trigger on any create, update or delete operation in your database and in the trigger event, you can choose to send in FCM push notifications to the devices of your choice.
Here is the documentation regarding the use and structure of a cloud function: https://firebase.google.com/docs/firestore/extend-with-functions
Hope this helps!