Matrix Client Push Notification implementation question - push-notification

We're building a matrix client and trying to enable push notifications. I've already got our client's push gateway set up with some modifications to create a notification body for FCM (our client doesn't support silent data-only notifications yet). Push notifications are working, but the content within them is limited.
The problem is that, we want to include information about the particular event, but that information doesn't seem to always be sent from Synapse to our push gateway.
For instance, we want to add the sender of the message to the notification body sent to FCM.
As outlined here in the Push Gateway spec, the synapse server will communicate with the push gateway via this POST endpoint. In the notification body, there may be the field "sender_display_name", but that field isn't showing up in the notification body being sent to Sygnal, even when our users have a display name set.
Modifying synapse doesn't seem like the way to go, as users of the client may be on different homeservers.
Is there something we need to change in our client to ensure that particular fields like "sender_display_name" are always within the notification body that gets passed along?
When I send the example request notification body to our push gateway endpoint, the "sender_display_name" is indeed present in the actual push notification on my phone. This indicates to me that our setup is working, but for some reason, not all the information we would want from our client is coming through synapse to the push gateway.

Related

Firebase custom notifications with FlutterFire

Thanks to Firebase and FlutterFire, it's easy to send regular notifications from the servers to the users' devices. Those notifications include a title, a body, and an image url. But what about creating a no-that-simple notification, like Telegram's or WhatsApp's?
The simple question is to avoid sending a Notification from the server, and instead set the data field to the push message. But according to the FlutterFire documentation:
Data only messages are considered low priority by devices when your application is in the background or terminated, and will be ignored
So, it sounds like if we want to have a reliable delivery system, we should add a Notification to our push messages. But that notification is so simple. And, again, according to the documentation:
If your message is a notification one (includes a notification property), the Firebase SDKs will intercept this and display a visible notification to your users (assuming you have requested permission & the user has notifications enabled)
So: If I want a reliable system, I have to send Notifications, but I do it, I can't tell FlutterFire to use my custom notifications.
So the question is: how to show custom notifications with FlutterFire?
What I want to achieve is something like this:
I'm going to try setting the priority of the push notification.
You can however explicitly increase the priority by sending additional properties on the FCM payload:
On Android, set the priority field to high.
On Apple (iOS & macOS), set the content-available field to true.
On the server side code, it looks like:
message.setAndroidConfig(AndroidConfig.builder().setPriority(AndroidConfig.Priority.HIGH).build());
message.setApnsConfig(ApnsConfig.builder().setAps(Aps.builder().setContentAvailable(true).build()).build());

How to Test FCM Data Push Notifications Delivery?

I have an Azure Web Service which is using an Azure Notification Hub to push data notifications using FCM via Firebase to a Xamarin Android App. Initially the app is getting a token which is posted to the web service. The web service then sends it with the data to the notification hub which is sending it to Firebase. The response back from the hub is indicating a successful transfer it seems from the notification properties and the ReqID property. But the notification is not reaching the app. Is there a way to see individual notifications' status on the Firebase site? Currently I don't see anything under the "Cloud" report for Data.
[
Thanks for asking question! One of the notification failure point could be when sending it from FCM to user device. To confirm this, you may try getting a delivery receipt from FCM.
You may refer to this article Receive delivery receipts. It says for Android and Chrome client apps, you can get delivery receipts which can be sent from FCM to your app server. To enable this feature, the message your app server sends to FCM must include the field delivery_receipt_requested. When this field is set to true, FCM sends a delivery receipt when a device confirms that it received a particular message. Also check for firewall on the user's network.

How can i push message while client not visit my site?

I use serviceWorker to push client desktop notification. Clients receive message if they visit my site, how can Clients not visit can still receive the message(like onesignal.com)?
Clients/Users don't have to be on your site to receive notification.
But your client/user has to accept the notification request in your site at first, so you save the subscription object in your database and later you use that user subscription data to send notification to your client/user at any time using library like Web Push API.
If you need anything in particular, please be specific.

Understanding Push notifications for Windows Phone 8.1

I'm trying to understand what I will need to build on my server for Push notifications to work successfully.
My thoughts were:
The phone sends the notify URL to my server
The server stores the information in a Database
A separate process or PHP script will query the database and open continuous looping process for each device. (Each socket will be querying a 3rd party API)
When there is a change detected in the API for that device a push notification will be sent to the device's notify url.
Is this the right method on what needs to be done. Isn't this going to eat up server resources or is it the expected outcome of Push a push notifications server?
I've produced a simple diagram on all this below:
First of all, let's separate the process in the main stages needed for PUSH.
Device subscription.
Send the PUSH
Process the notification on device.
Subscription
For the subscription, your device (more specifically, your App) must call the PUSH api,for enabling PUSH notifications. This call to the push API will give you a URL that uniquely identify the device where your application is installed and running. You should store this URL on your database, the same way you store a user's email, or a user's phone number. No special black magic here. You only use it when you need to send a communication to a user.
Send the PUSH
For the push stuff, the same approach as for email, or SMS messaging here: "One does not simply make an infinite loop and send a message if any change is detected". What you have to do is, just send the PUSH message when your application needs to. So you have the user to which you want to send a message, instead of opening a SMTP connection to send ane mail, just build the PUSH XML Message and call the URL associated with that user. Some things to consider here are:
Network reliability (you need to retry if you can't connect to the server).
Response error code-handling (you don't need to retry if the server tells you that the phone has uninstalled your application, for example).
Scalability. You don't want to send a PUSH message from your PHP code, because you don't know how long it will take for the task to be completed. You have to make this thing asynchronously. So just queue up all the push messages, you can create a separate process (windows service, nodeJS service, cron job, daemon, etc.) to send the PUSH, handle retries and errors and clean the queue.
Process the notification on Device
So now that you are this far, you need to handle the notification on the phone. It depends on the type of PUSH notification that you are sending:
Tile. You will update the image, text and counter of the application tile, if the user has put your application to the start screen. On client side you need nothing to so, as all these parameters are part of your PUSH request.
Toast. This one requires a title, text (limited to some 35 characters more or less) and a relative URL inside of your APP. Your application will be launched (like when you click on a Toast notification from Twitter, for example) using the URI that you specify in the payload. So a bit of data can be already injected here. You may/or may not make a request to your server for new data. It is up to you.
Raw. This one is pretty much silent. Is not seen by the user if your APP is not running. As you might guess, this kind of PUSH is useful to live update your running APP, instead of continuously polling your server, wasting user battery and bandwidth and wasting your server resources. You can send anything (raw bytes or strings) up to the max size of the payload allowed my Microsoft.
If yo have any more questions, don't hesitate to ask.
Bottom line: separate the PUSH sending, make it async, don't you ever forget that...
Your PHP script that continually pings the database for changes...THAT is what will eat up your system resources. Push notifications go hand in hand with Event Driven Programming. This means that ideally, your code shouldn't continuously ping your DB. Rather, when something happens (ie, an "event"), THEN your code does something...like contact your phone via push notification.
Your steps for push notifications are more or less correct, but are incomplete. Step 4: the server contacts the client via the notify url (which you have). Step 5 is that the client then contacts the server to actually pull down the information it needs. That is: The new information is not provided to the client via the notify url. Once the client has its new information, then the program continues as normal (populates a list, downloads skynet, etc.)
Your third step is very wasteful and not practical if your app is installed on more than a few devices.
Instead, each device should be subscribed to types of server updates it cares about. Your server's DB will have a mapping from each type of update you support to the list of notification channel URLs of devices that care about this update type.
When your server detects an update of type X, it would send a notification to all devices subscribed to that type of update.

APNS Push Requests are successfully sent but passes are not updating

I have an app set up to generate passbook passes. The successfully install on the device and I can do manual (pull-down) updates.
Next I began to implement APNS. I'm using the enhanced request method to connect to the production environment, sending in an empty payload (as required) and it returns no error codes when I request a push notification, but my pass never updates and I see no requests hitting my server. I'm using my own device to test until I can get see an update for myself. No pass updates are received.
I then implemented the Feedback service in the hope that it might tell me something. I noticed this. If I pass in the push token, I receive a response which indicates that the device is not receiving notifications (even though the pass is set for automatic updates). The pass is not updated.
I'd appreciate any info into why the the push notifications do not seem to be arriving.
Thanks.
-Erich
One gotcha to check is that you are not using the sandbox APNS server. All Passbook push requests should be sent to the live APNS server.
Try enabling the additional logging option from the PassKit section of the Developer Settings on your device then connecting your device to Xcode and monitoring the console as you send the push. If the push is received, then you should be able to see your device requesting the serials to be updated from your webservice and you should also see your server's response.
Assuming you send a serial and that it matches the serial installed on your device, you should then see the device requesting the updated .pkpass bundle.
If no push is received, try toggling automatic updates on and off while monitoring the device console. It could be that the device is not receiving a valid registration (201) response or that you are using a stale token - you'll be able to see these via the console.

Resources