Currently the WL.Server.notifyAllDevices(userSubscription, options) is used
to send notification to all a user’s devices.
Is there any callback from WL.Server.notifyAllDevices to indicate the status of this API call?
There is no callback.
The reason is that after Worklight dispatches the notifications to the various mediators (APN, MPN, GCM) they then send the notifications to the devices. However, These very same mediators do not guarantee that the notifications will arrive to their destination, as such, Worklight cannot either.
What WL.Server.notifyAllDevices does in fact is place the notifications in an internal queue, and they are then sent to the mediators. In Worklight 6.0 there is a new return value but it is not a callback per se for what you wanted (but again, there can't be such a callback...).
Related
I've been working in bulk web push notifications, migrating from OneSignal to Firebase. I've created a single FCM topic to which all users are subscribed immediately on startup.
At first messages arrive on the browser and the notification is shown correctly, but randomly after a few hours and in some devices, notifications cease to show. I've been recording every push message received using DevTools, and noticed that the messages are being received but the push event not dispatched in those cases.
In which cases something like this may happen? It's worth noting that the service worker has been healthly with no errors whatsoever.
Thanks
I'm having the following problem with UWP push notifications.
Scenario:
Foreground registers a background task for push notifications but also wants to be notified of incoming pushes so it gets a channel, updates the server with the channel then hooks onto events on that channel.
Push notification comes in
Background task launches and does it's work. It also checks to see if the channel URI has changed, if it has, it updates the server with the new uri.
Result:
Foreground app no longer receives incoming pushes on the channel because the background task updated the server with a different channel uri from what the foreground app was listening on.
What is the proper way for the foreground app to continue listening for push notifications after the uri potentially changed?
Updated problem for clarification:
Step 1 Foreground app code:
var channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();
channel.PushNotificationReceived += OnPushNotificationReceived;
//<update server with channel.Uri
Step 2 Background task launches and also checks for a new channel uri:
var channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();
//update server with channel uri
Problem
If channel uri changes in Step 2 then the even handler in Step 1 never gets invoked again.
because the background task updated the server with a different channel uri from what the foreground app was listening on.
No. Your understanding was incorrect. Let's first check the steps on how to send a push notification:
Your app requests a push notification channel from the Universal Windows Platform.
Windows asks WNS to create a notification channel. This channel is returned to the calling device in the form of a Uniform Resource Identifier (URI).
The notification channel URI is returned by Windows to your app.
Your app sends the URI to your own cloud service. You then store the URI on your own cloud service so that you can access the URI when you send notifications.
When your cloud service has an update to send, it notifies WNS using the channel URI. This is done by issuing an HTTP POST request, including the notification payload, over Secure Sockets Layer (SSL). This step requires authentication.
WNS receives the request and routes the notification to the appropriate device.
Then, if you understand these steps, you will find that the key point of sending a notification to the appropriate device is you need to request a notification channel. This channel URI is unique for every device no matter whether the channel URI is updated. So, even if your UWP app's background task has updated the channel URI on your cloud service, it will not affect the device to receive the notification. As long as you could make sure that the channel URI is the latest when you use this channel URI to send notification, then your device will always receive the notification(Except for some special cases, e.g, the device is powered off or device is in battery saver etc).
Please read Windows Push Notification Services (WNS) overview for more detailed information.
What is the proper way for the foreground app to continue listening for push notifications after the uri potentially changed?
What you said was not correct. There is no relationship between the "listening for push notifications" and "the uri potentially changed".
If you want to do some operations when the devices receive notifications, you could use the Notification listener to perform specific actions when notifications are received.
I am using Google Channel to do Push notification from server. It's working fine, but when I open the debugger windows, I can see lot of polling request that are going to the server.
Is that the way push notification works? If yes, then what is the use of it?
var token ="<%token%>";// This will creaete unique identifier(some id created by google api + ur key)
channel = new goog.appengine.Channel(token);
socket = channel.open();
socket.onopen = function() {
$('#messages').append('<p>Connected!</p>');
};
Thanks.
GCM doesn't do that. Gonna refer to the official docs on it's flow.
Lifecycle Flow
Send and receive downstream messages.
Send a message. The app server sends messages to the client app:
The app server sends a message to GCM connection servers.
The GCM connection server enqueues and stores the message if the device is offline.
When the device is online, the GCM connection server sends the message to the device.
On the device, the client app receives the message according to the platform-specific implementation. See your platform-specific documentation for details.
Receive a message. A client app receives a message from a GCM connection server.
Also announced in the recent I/O 2016, GCM's successor is now Firebase Cloud Messaging, which not only has the Push Notification Service, but also has other features (one example is Analytics) for free.
So overall, using GCM (or FCM) is a simpler method than polling. It handles the queuing of the messages you sent, and some others.
Part of my answer here. Also includes an idea why Polling is not ideal when sending push notifications.
I am using mobilefirst push notification service in my application. I am using rest api to send the message to GCM.
GCM receives and send it back to the mobile device too but in the device I am able to see the push message in the log, but not in alert which is the event source I have registered in my client device.
You have received a notification intended for Push.ALL tag. This is a broadcast notification and will not appear within the callback you registered with your Eventsource subscription.
You should use the onMessage callback API, as described in KnowledgeCenter and GettingStarted.
We are currently using Worklight 6.2 for our project. We are able to successfully send broadcast notifications. However, the basic reporting in the worklight console under the Push Notifications tab does not show any data regarding the broadcast notifications that have been sent. It appears that the reporting is only for notifications where device(s) will subscribe to an event source. Is that correct? Since there is no event source for broadcast notifications, is there no way to get the basic reporting ( # of messages sent, platform, number of subscribed users ) etc. in the worklight console for broadcast notifications?
If additional reporting is needed, is the only way to get it from the notification_proc table (we will not be using BIRT)? and create a custom page for the user or is there any out of the box provision to show more in the worklight console itself
For tag-based notifications (this includes broadcast notifications), there is currently no visual indicator in either Worklight Console (via the Push Notifications tab), or Worklight Operational Analytics Platform.
This information is currently not stored in the database, but this may change in a future release.
Feel free to submit a feature request so that the product managers could take it into account for future releases: https://developer.ibm.com/mobilefirstplatform/help/