I was running through FCM documentation and
- I would like to understand about what would happen when the subscribers come online after a longer offline period.
- Will FCM store all the push notifications received during the offline period
- Will FCM deliver all the messages once the subscribers have come online
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. If the device never gets connected again (for instance, if it was factory reset), the message eventually times out and is discarded from FCM storage. The default timeout is four weeks, unless the time_to_live flag is set.
Lifetime of a message
Related
As stated here, a BLE GATT client can "subscribe" to a specific characteristic in a GATT server to be notified each time a change occurs within this characteristic.
Actually I'm wondering, does the notifying characteristic keep alive the connexion between the client and the server during all the time of the "subscription" ? In other words, after having subscribed to the notifying characteristic, will the client and server remain connected until the client forces the deconnexion ?
Subscription of notifications is not related to whether a client or server should keep a connection or disconnect. There is nothing in the specification that says so at least.
However an application can of course create custom rules such as the link should be disconnected if there are no subscriptions for some amount of time. The Windows BLE stack even does this per default.
Does Firebase cloud messaging detect when a device comes back online and sends any pending notifications that could not reach the device while it was offline (without network / turned off?
Going through the FCM documentation, you could see (emphasis mine):
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. If the device never gets connected again (for instance, if it was factory reset), the message eventually times out and is discarded from FCM storage. The default timeout is four weeks, unless the time_to_live flag is set.
So in a way, it does detect it.
I am looking to implement rabbitmq on google compute engine to handle messages on my android and ios messaging app. I have heard that rabbitmq can be quite power hungry, so i am wondering what the best solution to combat this is?
Do i use a different protocol like MQTT or so i use something like GCM to handle the connection to and from the apps and let rabbitmq just handle queuing the messages?
You would never want make a direct connection from mobile device to your RabbitMQ server, especially if the app on the device is a consumer. RabbitMQ consumers have to poll RabbitMQ continuously to check if there are messages pending for them. You would want a web-server to handle actual HTTP POST/GET of messages from devices. The webserver will do two things:
Save the message to DB (along with the source and intended destination info)
queue APN/GCM push messages to a RabbitMQ (the broker here) exchange
you will need to build a daemon to monitor RabbitMQ for these push messages that have been queued. The daemon's sole task would be to connect or maintain a connection to Apple's or Google's push messaging services and notify your apps that they have a message pending. If a device is notified of a pending message, it contacts the webserver to consume the message
My web app communicates to my mobile app via ActiveMQ durable topics via MQTT (Paho). To deliver messages to the mobile device a separate topic is created for every mobile user. All messages from mobile devices are directed to a single topic.
This configuration seem to work fine, but every once a while something strange happens, the messages are not delivered to a device. Here is what's happening.
The user specific topic for messages sent to the device is dynamically created and looks fine in the console.
The messages sent to the topic seem to be enqueued fine - the count in the console is incremented
The client seems to be active - at least the console shows that the topic has an active subscriber
No messages are delivered to the client - The dequeued counter is stuck at 0
while the topic for this particular user is not working, other topics for other users work fine - messages are delivered as expected
Deleting topic for the user from the console and having it recreated does not work. The topic disappears from the console and reappears after it is recreated with the same counters it had before deleting. The message delivery still does not work
Restarting the broker fixes the problem
Any thoughts?
Live tiles are able to receive push notifications without the associated metro app needing to be running.
However I believe that the app must have run at least once in order for the app to acquire a notification channel and subscribe to a notification server, passing the channel to the server.
My question is -
What happens if the server cuts off the client? If the user turns off their computer I presume the server would start receiving delivery failure errors. The server might then cut off the client.
But what happens when the user turns their computer back on? Is the tile now disconnected until the user starts the app again and it resubscribes with the server for notifications?
Or is there a way for the tile to resubscribe automatically on start up without the app having to run?
The push notifications are not sent directly to the client; they're sent via the Windows Notification service in the cloud. This means your service will be able to just send them. The WNS service will do the right thing with notifications when the machine comes out of sleep / reconnects to the network.
http://msdn.microsoft.com/en-us/library/windows/apps/hh913756.aspx has a overview of the service side of notifications.
It's important to note that the tile channel expires after 30 days, and will need to be (programmatically) renewed. The guidance is that you should renew when the app runs to make sure it doesn't expire.
The only thing I can't seem to locate in the documentation is how many push notifications are queued on the client - I suspect that for a given tag notification, only one is kept.
Maybe another way to think about this is with the bad notification -- e.g a "new items" count. If you push this number while the device is disconnect from the network (off, driven over etc), then your service will succeed in sending the notification, and when that machine reconnects, it will seamlessly see the badge update.
You should handle that in your code that when your clients from the server went offline then you should remove them and disconnect them, the client side will only receive the cached values in the live tiles.
If they went back on, then you should also handle it in your server side to push the new notification data.
Just a quick tip: If you are using WCF as your service, you might want to check the Announcement Service Class there you can handle your clients online/offline scenarios.