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.
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.
In our multitenant environment, I would like to setup an alert notification(e.g. email) when our user's code has an exception.
I was thinking of using the stackdriver error reporting api to send an error notification. Something like
from google.cloud import error_reporting
client = error_reporting.Client()
try:
raise NameError
except Exception:
client.report_exception()
How can I set this up (using a python api)
create an alert for a tenant id/service id to send notifications to. I could input user's contact email in this step.
Report an exception for a tenant id/service id using something like client.report_exception() and notify the alert mechanism
Other solutions:
This post suggests that I use logging and log errors, create a filter and create an alert policy. That would be an option but I feel it may be expensive as that would mean for each of the services of our users, it will be running the log search query every few seconds/minutes? I was wondering if there was a push approach (vs the logging pull approach) or have I misunderstood that the logging notification is actually a push approach?
If I'm on the wrong path, please feel free to suggest better ways.
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.
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.
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!