I have a problem with the following scenario:
I Send a document from the Server to a mobile Device. I also send a notification about a new document in the inbox at the same time.
Problem is: Depending on the Device's Connection speed, that submission can take a while, so the notification comes in before the document is in the app's inbox.
So I want to send the Notification after the submission is completed.
Question: Is there a way for me to check if the MQTT data transfer is completed without having to have the client send a confirmation?
With MQTT, it is not possible for a publisher to know that all subscribers have received the message unless the subscribers also publish an acknowledgement back on another topic.
Related
My Android client app does not receive any Firebase push notifications targeting topics, however I immediately receive notifications sent to all app users or notifications sent to specific devices.
I didn't change anything in my code and I checked whether the client is correctly subscribed to topics.
For further details about my subscription logic:
In order to make it easy for my web service to send notifications to a specific user, each user is subscribed to a topic entitled with his user-id whenever he logs in from the client app.
Is this approach weak somehow? Should I otherwise register the device token to my database every time it's updated? And then send the notification to that specific token?
Should I otherwise register the device token to my database every time it's updated? And then send the notification to that specific token?
It is highly suggested that developers save the generated registration token for each device for later use. As mentioned in the docs:
After you've obtained the token, you can send it to your app server and store it using your preferred method.
In your case, it is preferable. It'll remove the added action of subscribing the device to a topic. Plus it can be useful to track the message status using Diagnostics tool should you need it in the future.
According to the Firebase Cloud Messaging documentation if the app server sets a field "delivery_receipt_requested" in the upstream message, it will receive a delivery confirmation when the app confirms receipt. However it works only if app server is connected with XMPP connection server. It will not work for HTTP connection server.
I'm very new to GCM/FCM and haven't setup my server yet. Hence am working with Firebase console to test my app for notification receipts.
So, following are my queries.
Will the field "delivery_receipt_requested" be sent to the app or the connection server itself will consume it.?
If the app receives this field in a notification will it need to act differently from the notification which do not contain this field.?
Any references to documentation or example implementation which makes use of this field is highly appreciated.
Thanks in advance.
Will the field "delivery_receipt_requested" be sent to the app or the connection server itself will consume it.?
The FCM client installed in Google Play services will handle this.
The application will not notice anything different.
If the app receives this field in a notification will it need to act differently from the notification which do not contain this field.?
The application doesn't need to take any action. indeed the app will not receive this field.
Longer explanation:
delivery_receipt is not exactly a confirmation that the app received the message, but it's a confirmation that the device received the message. To be clear it's still possible that the device crashed or run out of battery while the message is being passed to the app.
this feature is implemented outside of the application. so the application doesn't need to be aware that this message requires a delivery receipt
you can implement a more precise "application delivery receipt" by calling your backend in the method that receives the message.
(like an http call to: http://mywebsite.com/confirm-msg-processed-successfully.php?id=133)
My app have a connection with a php Server where the data is saved so the app its like a chat the user send a message and the other can see and awnser my doubt is if I stay constantly request the server to update the messages its gonna affect the performance and what is the better way to do this?
The best way to do this is using Push Notifications, you don't need to maintain an open connection but receive a message from your server that it's telling you there is a new message. The received message is too short so maybe you will not be able to send the message from the Push Notification but you can tell the app that a new message is ready in your server.
To do this in PHP you can refer to this link and link2.
Another chance is to use sockets, I give you a link about This.
You can make requests in your app to ask php server if the new messege is there. It will be working.
The second way is to implement in your server and app Google Cloud Messaging . It is "wired" into device and can push messege into device.
Turning off internet on mobile device directly causes problems in my chat application. Messages are not stored in openfire offline table as Openfire still shows me online on abrupt disconnection from the server. when a relogin attempt is made the messages that were sent in that period are lost.
I am working on a chat application,after login to openfire I am able to chat and other users can see me online but the problem is if one user losses the connection like WIFI off,In such situation Openfire is not showing my status as offline and it still shows Online which results in message packet loss.
Please provide me the solution I am unable to resolve it.
On a sidenote how whatsapp and other apps send messages. Do they use message storage strategy on server and acknowledgement or am I missing something here.
Both client and Server needs to acknowledge that messages were sent & delivered, say for instance you send a message to someone else, what you can do here is that you save this message on your server, from server this message will be sent to receiver and wait for an acknowledgement by the receiver that the message was delivered, once you get acknowledgement - delete the message from the server.
How whatsapp do it? I found this answer by Michael Donohue on Quora
Whatsapp works on store and forward, The WhatsApp client will store any message you send, and keep trying to send it to the WhatsApp servers. When a WhatsApp mobile app connects to the chat servers, the store-and-forward process occurs in both directions. The client sends any pending messages in it's mesage store to the server, while the server sends all the accumulated messages destined for that client to the client. This process is done on an acknowlegement basis. This means messages are sent repeatedly until the other side acknowledges receipt of the message. server drops messages once they are acknowledged - there is no long term storage. Whereas the client will update the UI to double-check status once the ack arrives, but will keep the message.
In android client using Smack framework, you must disable Stream Mananement just after creating XMPPTCPConnection and before run connection.login().
connection.setUseStreamManagement(false);
I had this problem and with this code was solved.
I am developing mobile client for emailing service. One of the key features is notifications about new messages in the mailbox. As recommended by GCM architecture guidelines we are using a "Pusher" that is responsible for sending messages to the Google servers once we received a new message. The issue is that testing process has reported about serious problems with push notification delivery to devices.
So the question: is there an approaches for monitoring average statistics about push notification delivery percentage, time etc? Or maybe somebody have experience in how to set up test environment for efficient monitoring of how much notifications are getting lost during the application work?
All the "tips&tricks" related to the improving Android GCM experience are welcome.
Google claims that the processing at their GCM server takes less than a millisecond. Link below for a great video on GCM from Google's developer. And it's believable coz I could get push notifications almost instantaneously using my company's server to my device now.
http://www.youtube.com/watch?v=YoaP6hcDctM
They don't guarantee delivery, but they try for a max of 4 weeks to deliver the message depending on the duration you set in the message you send to Google's GCM servers and if you wish to let Google keep the data for eventual delivery of message to the device in case the device was offline when the message was to be delivered.
However, there are certain conditions under which the GCM messages are not delivered.
Background data is unchecked under Account and Sync settings.
Prior to 4.0.4.(ICS), a Google account on the device is a pre-requisite for GCM. Maybe, Users are not logged into their Google account.
The only way to do so is to report back to your server with the timestamp of the received push.
You can either
Report back to the server once you receive the notification in your GCM service. To implement, you will have to add a push id for your push notifications and send the id along with the push data. The client will have to get the timestamp once it receive the message and send it back along with the notification id. A simple php script can be done (when you send a push notification, you set the time of the send-notification and once it receives the device's timestamp it sets the receive-notification. This boils down to two fields in your database (marked in bold). In this approach you will probably not so much care about errors since it is very probable that the device will have a connection when it receives the notification and as such its request to your server will go through.
Keep a list of notifications received in your app and their timestamps. And when the sync is done, send the this data in your sync operation. This is ultimately the same approach but your server's data won't be as realtime as the first approach. However, the extra request is not required from the client's side but saving the received notifications and their timestamps is.
All in all, you will have to keep track of the notifications sent using a notification-id and their sending time (send-notification) and their receive time (receive-notification). A simple query will help you analyze this data.
Google has added support so that you can receive delivery receipts from Cloud Connection Server (CCS):
You can use upstream messaging to get delivery receipts (sent from CCS to your 3rd party app server) when a device confirms that it received a message sent by CCS.
To enable this feature, the message your 3rd-party app server sends to CCS must include a field called "delivery_receipt_requested". When this field is set to true, CCS sends a delivery receipt when a device confirms that it received a particular message.
https://developer.android.com/google/gcm/ccs.html#receipts
Google does not make these statistics available to you. There are some statistics available on the android developer console. This only shows the number of messages and registrations.
You would have to implement your own data collection, which could be done fairly easily. You could record the time & id of each message sent and have your android client report back to your server with the time of message receipt. You could then store the data on your server and query as needed.
Since that time Google has provided developers with advanced monitoring tool.
The Gcm Diagnostic Tool is available in Google Play developer console. Additional information is here https://support.google.com/googleplay/android-developer/answer/2663268
So you can easily track the particular message status via registration token.