I followed the instructions in the Rocket.chat documentation:
Removed the check mark from the gateway
added GCM keys from firebase
rebooted the server
Pushs seem to come, but the listener "pushnotificationreceived" is triggered only if I open the application immediately after the push should come or I am in the application during the push, if I have minimized the application and send myself a message, then there is no push.
If I throw the push myself through the firebase API, then the push works out as needed.
There is a suspicion that this is due to the fact that Rocket.chat sends push data in the data key, not notification (https://github.com/RocketChat/Rocket.Chat/blob/develop/app/push/server/gcm.js).
I also have an error in the Rocket logs.Chat:
"For devices running Android 8.0 or later, you need to specify the android_channel_id identifier. See https://github.com/raix/push/issues/341 for more information", but even with this error, push writes that it was sent successfully.
Please, checkout this post:
https://forums.rocket.chat/t/apple-push-notification-service-update-from-legacy-binary-protocol/12425/4
Also, consider asking dev questions at:
https://open.rocket.chat/channel/dev
Related
I am coding a vue.js app using web pushes with Firebase Cloud Messaging and I wondered if it was possible to send a web push to a user and in case the user was offline, to somehow store it for later display when the user opens the app again. Is there a principled approach to this problem, i.e. managing web pushes when the end user is offline?
The reason I am asking this is that, so far, all the web push notifications I've committed to FCM server with tokens of offline clients (i.e. desktop browsers) went into oblivion. To be sure, FCM didn't try pushing the notification again when the clients went back online.
For this reason I am considering coding a self-made dispatcher to manage web push for offline clients, but I need to make sure my efforts are worth it.
updated: I am now able to display notifications sent to an offline client after coming back online using appropriate time_to_live values. However, only the latest notification is displayed. How is there any specific reason why?
FCM's default behavior is exactly like that. From the docs:
If the device is not connected to FCM, the message is stored until a connection is established (again respecting the collapse key rules). When a connection is established, FCM delivers all pending messages to the device.
I've been trying to use AWS SNS service to send notifications to Apple Sandbox environment . I think I setup everything ok and my dev iPhone can get notification without trouble.
But when I start to send notifications to others who install the test app , I keep seeing error message state that
Platform token associated with the endpoint is not valid
With a messageId :147975e0-8a09-5223-8537-256320ab3733
From what I understand , if one device can success, others can success too.
Could anyone tell me how to debug this probelm.
Thanks.
I believe that the apps that the other people are installing were not built with a dev cert (probably built with an adhoc or production provisioning profile), so you probably should use the production certificate.
You could try adding another application on SNS using the production certificate (or the same one, but not using Sandbox, depending on how you generated it), if it works, that this is it.
Also make sure you are using the correct bundle id associated with the certificate.
No I started use push notification in my project (it worked sometime ago), but can't make it work. I downloade sample-messages project and changed my account and application settings. But messaged don't delivered to receiver. Registration of device is ok. I see my subscribtion. No errors from response when sending notification. What I only got is the json description from logs, when i click my message from queue (but it's in status "sent") Can't get it work. Please, help.
{"notification":{"registration_ids":["APA91bEsqEY2OcaQpgU6Nmk6P7P0fSEdnGuXHSOnUwMJ3ZCAuZC0hGiE_7DX-TlvuAnivJ3Bt4nSM7eEN3AR2Qg2jjCGC8RRT7GbDJgpuy25plCohb23CpD5hLaHo7l-TZvgZhpXjCM0"],"delay_while_idle":false,"data":{"message":"fgjkkkkllkleddxccvvvcxfffffjhghvfg I was ","collapse_key":"event5711312"},"time_to_live":86400},"log":[{"device_token":null,"created_at":"2016-02-23T18:21:42Z","delivered_at":null,"failed_at":"2016-02-23T18:21:47Z","error_code":401,"error_description":"Unable to deliver notification 11778569, received error 401 (Unauthorized, check your App auth_key.)"}]}
I redid all the configuration steps in the link:http://quickblox.com/developers/SimpleSample-messages_users-android#Setup_GCM
Now it is back to work!
Attention to some details:
The API key you have to use in Google cloud console is of the SERVER type
Use the same package name on Android manifest and Google cloud console
Use your application ID from developer console to get GCM token on your Android application
don't forget to copy the google-services.json (generated when you enabled Google services for your app) to app/ directory on your project (the same directory of your src/)
We have an iOS app which is able to receive push notification through the Apigee SDK.
The push notifications are sent by using the Apigee admin console.
Within the console, we configured both dev and prod environments. The prod environment is used for the app published in the App Store. In both cases, the push notifications are well received by our iPhone devices.
However, my question is about the status displayed in the Message History section of the Apigee console.
In the case of the dev notifier, the console display the message : Finished (with errors) with by example, a total sent of 660 for a total errors of 1318.
I don't well understand these figures and I don't know where they are documented.
Is the total sent figure for the number of devices to which the push is sent? However, we don't have as many devices with the dev app version installed
The devices we have with the dev app version installed have well received the push as expected so why are there as many errors?
The detail of the error message is: "INVALID_TOKEN: Failed sending notification."
Thanks very much for your help
We have a bug where statistics get calculated inaccurately if you have errors from the Apns service since they come back asynchronously.
Invalid Token usually means the device is not registered with the apple push notifications service anymore.
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.