I'd like to know if there any a way to prevent the device display a notification when a FCM message with a notification arrives, in case the user has decided to mute notifications and only have them arrive silently (making them act as data only messages, but being notification messages). I imagine like, in the handler/callback call a method to prevent the device notification and do extra processing afterwards.
I know I can use data only messages, but that approach would be harder since I must use multiple topics or token lists and somewhat more backend logic to achieve that.
Thanks
If the message contains a notification property, it is automatically handled by the OS when the app is not active. There is nothing you can do to prevent that.
As you said: if the message only contains a data property, it is always passed to your code for handling, and you can decide what to do with it. So that's the way to go if you want full client-side control over whether a notification is displayed for a message.
Related
I set up a glitch service as described in the Meta doc to receive notifications of WhatsApp received messages via a webhook. However, messages notifications are not received at all, not even pressing the test button of the webhook. Please, note that it's not a general configuration problem, since other notifications (e.g., account_alerts) are properly received.
(I'm using the test phone number provided by Meta)
Any hints about this issue?
Turned out it was a bug: https://developers.facebook.com/support/bugs/856675538926230/
(Now it seems fixed)
Hello I am trying to create a simple push-notification system similar to this common use case:
1. The user gets a chest and can either watch an ad to skip the wait time or wait one hours for the chest to open. The app sends an upstream request which sets up a downstream push notification that shall be delivered in one hour to let the user know the chest is ready.
2a. The user then waits an hour, gets a push notification (outside of the app) to open their chest and they do!
or
2b. They wait 20 minutes then decide to watch the ad. The app sends an upstream request which cancels the pending push notification which would have otherwise been delivered in 40 minutes.
Okay awesome so that is the problem and I am having a hard time understanding how to do this. I have looked over the documentation for each of these programs but they seem designed for downstream push notifications. It just seems odd there is no built-in support for this use case. It seems like such a common use case.
I so far found 3 solutions that will integrate into my cross-platform Unity setup and provide services for free or super-cheap:
Amazon Simple Notification Service (SNS)
Google Firebase Cloud Messaging (FCM)
OneSignal
Amazon seems to group clients into "Topics" so I guess I would be setting up a one-device-topic and essentially. I can subscribe and unsubscribe from them but it doesn't seem to support a topic with a 60 minute delay.
2a. Create a topic: https://docs.aws.amazon.com/sns/latest/dg/sns-tutorial-create-topic.html (it would just include the current device)
2b. Subscribe to it
2c. Send a message to it https://docs.aws.amazon.com/sns/latest/dg/sns-tutorial-publish-message-with-attributes.html
So basically I can add attributes to my message but it would seem I need to implement the server-side code to read a delay attribute then somehow queue a message for delay. Maybe I am missing something?
For Firebase I pretty much see the same thing as Amazon. There are topics https://firebase.google.com/docs/cloud-messaging/android/topic-messaging and a means to send upstream messages https://firebase.google.com/docs/cloud-messaging/android/send-with-console but with the messages I don't see anyway here to get the time delay https://firebase.google.com/docs/cloud-messaging/unity/topic-messaging I see conditions towards the bottom of that article but I don't know if it is meant for this use case.
OneSignal has the easiest to scroll-through API. I'll refer to some strings that you can CTRL-F by using the format ("Create Notif") because everything is on this one page: https://documentation.onesignal.com/reference
So basically I can ("Send to Specific Devices") which I guess would be the sending device, then I can ("Schedule notification for future delivery.") using the send_after parameter. And finally, if need be, I can ("Cancel notification"). So this appears to be everything I need. I'm currently looking at this option and trying to figure out how to actually get this working.
So there is my progress over the last few hours researching each of these options. I am hoping you can help me better understand how I may be misunderstanding the above options as this seems to me a very common use-case. Perhaps I am just not googling the question correctly. Any help appreciated.
Whenever there's a likelihood that you'll need to cancel a significant percent of the notifications you send, you should use local notifications. That way you can easily schedule and cancel them locally without making any network requests. Also, this solution works for offline devices which is great for games (played on planes, etc...)
I know that push notifications are being sent from a backend server. Is it possible to send notification from client itself? My application goes like this: It acquires its position using Location services API. once it enters a specific circle, the trigger calls a callback function. What i want to do is to use the callback function to push a notification to the device. Is there any way to do this?
Thank you very much in advance!
If you just want a notification when the app is active in the background, you can use local notifications: https://github.com/katzer/cordova-plugin-local-notifications. The plug-in Javascript has to be modified somewhat to work with a Worklight app, but with some simple modifications it works great, and allows your app running in the background to raise a notification without going through the server side round trip involved when using push.
That said, I implemented an app that did exactly what you are looking for (in my case, I needed some server side processing to figure out what the text of the push message should be) The geo-fence callback called an adapter, providing it with event details and the device ID. The adapter determined what message to send, and used unicast push to send it back to the device.
You can invoke a procedure in the client side. I tried to invoke in the client side with httpAdapter and its working.
If the notification doesn't need to come from the server, you can also create a service that will run in the background and show a dialogbox once it enters the geofence.
I have implement Apple Push Notification in my application.
It's working fine when my iPhone is on.
Now, when I switch off my iPhone and fire notification from the server, it's successfully sent.
but, When I switch on my iPhone, I am not getting any notification.
So, what is the problem ?
Apple Push Notification service includes a default Quality of Service
(QoS) component that performs a store-and-forward function.
If APNs attempts to deliver a notification but the device is offline,
the notification is stored for a limited period of time, and delivered
to the device when it becomes available.
Only one recent notification for a particular application is stored.
If multiple notifications are sent while the device is offline, each
new notification causes the prior notification to be discarded. This
behavior of keeping only the newest notification is referred to as
coalescing notifications.
If the device remains offline for a long time, any notifications that
were being stored for it are discarded.
I need to pass messages between a WP8 app and a Windows Store app. It's sort of a "peer-to-peer" situation in that they will both send and respond to messages from each other, but it's also sort of a "client/server" situation in that the Windows Store app will have 1..N WP8 apps that it is conversing with.
After being beaten about the head and shoulders for my first ideas of trying to use either email or SkyDrive rather sneakily, I'm now considering these possible architectures:
1) Direct Push Notifications
(a) The WP8 app sends Push Notifications to the Windows Store app via a URI it is provided after this conversation takes place:
Windows Store app: "Will you send me updates?"
WP8 app: "Yes."
Windows Store app: "Okay, here's where to send them."
(b) Windows 8 responds to the arriving msgs.
2) Push-Pull using the Cloud
(a) WP8 sends data to the cloud (Azure?)
(b) Windows 8 app periodically polls for it
3) SSL (Using components from someone like /NSoftware (IP*Works))
The messages from WP8 are rather frequent (every 15 minutes, on average), but small/short (short enough to be a Tweet, in fact). The Windows 8 app deals with these msgs "behind the scenes." The user is not aware of them until he runs the associated app.
There weren't any question marks :) but here's my take:
Push notifications would certainly work, but given your "behind the scenes" comment, you may want to look specifically into "raw notifications", which do use the push notification mechanism but aren't associated with UI (like a tile, toast or badge). Pushed toast notifications, for instance, are dropped if the client if off-line.
The frequency of the messages makes me leery of the polling approach given impact on battery life (that said, not sure how a push notification with background task would compare). With the polling approach too you'd need to have some way on your "cloud service" to maintain messages (storage) and then feed back the right messages on each poll, etc. You'd also need to handle the scaling and availability aspects that WNS would do 'free.' Not rocket science, but more work. The push notification is kind of 'fire-and-forget'.
With sockets, you might have more control to the extent the sandboxed model exposes functionality you need. It seems like more moving parts though, and I'd likely go that route only if the other two approaches are otherwise unviable.