How to retrieve and handle the payload data from the app in background & foreground in iOS. I got the push notifications working, but I don't know how to extract the response.
notificationCallbackIOS: (message: any) => {
console.log("Message : " + JSON.stringify(message));
}
"nativescript-push-notifications": "^1.1.3"
This callback is not working. I am unable to extract the payload data like action, title.
You could try to use this plugin https://github.com/EddyVerbruggen/nativescript-local-notifications
it has a addOnMessageReceivedCallback event for listening for incoming notifications. I also used it on my app that i'm developing now. Even its for local notification, it also listens for remote notification you can call it on your app.component.ts.
Related
for project i used pusher to create realtime chat using laravel 9 . i can send message from front end to backend with api but can not received messages from backend
chat channel created but won't show up anything
for example when an event called backend completely received that but could not send anything or can not connect to channel
js :
Echo.channel('chat').listen('.MyMessage', (e) => {
console.log(e)
})
could anyone help me ?
I've almost successfully migrated an existing app from Parse.com to Buddy.com for sending and receiving push notifications.
Registering, acquiring the deviceToken, and subscribing to channels works. I can see the installation details in the data Browser and also sending push notifications directly from the Dashboard works. Notifications are received almost immediately in the app.
Now I have changed my server application (using the Parse PHP-SDK 1.2.1) to use the Buddy API endpoint and configured it to use the masterkey for authentication. Although sending a push notification via the API doesn't give an error and is even returning "result => 1", notifications are never received in the application. I can't find a server log like on the original Parse Dashboard at Buddy, so I can't verify if the messages I sent are really queued and picked up for delivery.
I'm a missing something essential?
Solved it! Seems that the Parse.com api accepted push data payload in JSON encoded format. But for the Buddy.com platform, data should be passed as plain array.
My payload as I pull it from our notification queue:
$data = '{"alert":"Test bericht"}';
Although returning result => true, this won't work:
ParsePush::send(array(
"channels" => ['user_1234'],
"data" => $data
), true);
This works as expected:
ParsePush::send(array(
"channels" => ['user_1234'],
"data" => json_decode($data, true)
), true);
I have successfully set up Google Pub/Sub to use Gmail API Watch feature as described here: https://developers.google.com/gmail/api/guides/push to watch INBOX label in my gmail account.
Once new message arrive I instantly get a push notification in valid format like:
{ message:
{ data: '.......',
attributes: {},
message_id: '1248700053943' },
subscription: '.....' }
After I base64decode data I get email and historyId. Then, as suggested, I request gmail.users.history.list API (via API console) with startHistoryId set to the historyId from the push notification. And then get just empty response without any details:
GET https://www.googleapis.com/gmail/v1/users/me/history?startHistoryId=4658879&key={YOUR_API_KEY}
200 OK
- Show headers
{
"historyId": "4658894"
}
So historyId from a notification does not seems valid.
Seems Gmail users.watch API is not working properly, and sends wrong historyId, or I'm just missing something?
Looks like I misunderstood how users.history.list works, and the flow should be something like described below:
Remember historyId from the response of users.watch request.
On push notification call users.history.list with previously remembered historyId as startHistoryId instead of new one from notification, and get list of recent changes.
Remember historyId from notification, and goto 2.
If we look on the response of any call to users.history.list, historyId is always present, it's a marker of latest history change. Push notification brings latest historyId, so if we request users.history.list with it (as in the question), we got empty array of history, and the server drops this empty "history" field from the response, that's why we get this:
{
"historyId": "4658894"
}
But not this:
{
"history": [ ],
"historyId": "4658894"
}
More details provided in sync guide: https://developers.google.com/gmail/api/guides/sync#partial
So we can't easily get details of the new message arrived to INBOX from push notification, and need to deal with history mining and synchronization to find it.
/*Get the URI that the Microsoft Push Notification Service returns to the Push Client when creating a notification channel.
Normally, a web service would listen for URIs coming from the web client and maintain a list of URIs to send
notifications out to. */
string subscriptionUri = TextBoxUri.Text.ToString();
Further information on how the pushclient would then sync the URI with a webservice lacks in the description given on MSDN.
So, does anyone know how to make my app send its URI to the MPNS using the push notification client of the Windows Phone, iso having to manually copy-paste them into my web application?
Greetz GP
See MSDN Windows Phone Code Samples at:
http://msdn.microsoft.com/en-us/library/ff431744(v=vs.92).aspx
The following code snippet from the 'sdkToastNotificationCS' example show a possible location to store the uri or send to your webservice:
void PushChannel_ChannelUriUpdated(object sender, NotificationChannelUriEventArgs e)
{
Dispatcher.BeginInvoke(() =>
{
// Display the new URI for testing purposes. Normally, the URI would be passed back to your web service at this point.
System.Diagnostics.Debug.WriteLine(e.ChannelUri.ToString());
MessageBox.Show(String.Format("Channel Uri is {0}",
e.ChannelUri.ToString()));
// Instead of showing the URI in a message box, POST to your web service
});
}
Execute an HTTP POST request to send the URI and an identifier for you push user. Receive this POST data on your web service and store the user/URI so you can push notifications to that user from your web service.
You just need an endpoint on your server that the app can send the PNS uri (and any other relevant information) to.
After successfully sent the URI to the web service from the push client, I send a toast notification from web service by using the URI, in web service I get the response as :
Push status 200,
NotificationStatus : Received,
DeviceConnectionStatus : Connected,
NotificationChannelStatus : Active.
But no message is received in the push client. The same scenario used to work fine earlier today. Can anyone tell me what is going wrong?
Is the message you are sending the same (ie. identical)? I seem to remember that some instances of a malformed message would get through the service OK, but then be suppressed on the device.
Do you have code to handle toast messages that arrive while your app is running? If you do, put a breakpoint in there and send a toast to the app while you're debugging and see what comes out. In this way you can make sure that the toast is making it to the device, and also see what the content is or what the problem might be.
channel.ShellToastNotificationReceived += channel_ShellToastNotificationReceived;
where channel is your channel object, and then
void channel_ShellToastNotificationReceived(object sender, NotificationEventArgs e)
{
Dispatcher.BeginInvoke(() => MessageBox.Show(e.Collection["wp:Text1"] + Environment.NewLine + e.Collection["wp:Text2"]));
}
or something similar to pop the message out to the display.
In web service, if a wrong setRequestProperty is set for example, setting wrong X-WindowsPhone-Target and wrong X-NotificationClass, then web service will receive notification received status, but the push client will not receive any message.
In my case I was sending a toast message with X-WindowsPhone-Target as token and X-NotificationClass as 1. After giving correct value it has started working fine.