Any one have idea when i am sending the messages using the wifi network they are sent but i was not able to receive the same. Means wifi network will send the message but same network will not able to receive the message, on other side if i change my network to mobile data then its working fine.
Always check internet connection availability before running the application for push notification.
GCM works by keeping a long-lived socket open to Google's push notification server. The socket is kept open by sending "heartbeat" messages between the phone and server.
The network state may change and this socket will be broken (because the IP address of the device changes, from 3g to wifi, for example). If the message comes in before the socket is re-established, then the device will not immediately get the message.
The re-connection only happens when the phone notices the socket is broken, which only happens when it tries to send a heartbeat message.
You may check the network available like this:
private boolean isNetworkAvailable() {
ConnectivityManager connectivityManager
= (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
NetworkInfo activeNetworkInfo = connectivityManager.getActiveNetworkInfo();
return activeNetworkInfo != null;
}
Here's where I get my answer: Google Cloud Messaging - messages sometimes not received until network state changed
Related
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 facing a weird problem with connecting Rabbitmq from UI. I use 'xhr-polling' only due to some reason to connect rabbitmq queue from UI and it works fine for quite sometime when user lands on page but it disconnects with rabbitmq at some point without any error.
I have put in some logic to reconnect, once it is disconnected and as per the log it seems it connects but when I look at the RabbitMQ there is no client connected to it. However browser console (connected to server RabbitMQ/3.6.10) and keeps sending calling xhr_send?t=[random-key] and xhr?=[random-key] gets response 204 or 200 (As per developer tool).
When I refresh the whole page, it connects back again fine and see rabbitmq client queue as well something like (connected to server RabbitMQ/3.6.10).
Technology stacks are : Sockjs + Stompjs + RabbitMQ with Stomp plugin
So in summary reconnect logic shows it is connected but as per rabbitmq there is no subscribed client. Normally I see something like this stomp-subscription-rIUXo4Yvmilga2w3g5Lu6g as queue name when connected.
I want to have multiple XMPP servers listening on upstream GCM messages for load balancing and fault tolerance. If I connect two servers to the same sender ID, would google automatically split the messages between them?
It's stated in Implementing an XMPP Connection Server that, periodically, CCS needs to close down a connection to perform load balancing to control messages.
Before it closes the connection, CCS sends a CONNECTION_DRAINING message to indicate that the connection is being drained and will be closed soon. "Draining" refers to shutting off the flow of messages coming into a connection, but allowing whatever is already in the pipeline to continue. When you receive a CONNECTION_DRAINING message, you should immediately begin sending messages to another CCS connection, opening a new connection if necessary. You should, however, keep the original connection open and continue receiving messages that may come over the connection (and ACKing them)—CCS handles initiating a connection close when it is ready.
I might be wrong but what I understand is that splitting of messages is not done since there's only one active connection. Sending of messages to another server starts as soon as CCS sends message that connection will be closed.
First, I tested the communication of 2 XBee (series 2) in AT mode and all worked correctly.
Then I changed the Coordinator to API mode and ran the below script while the router was in AT mode. I was successful and received the routers message. However, I can't get the router to be in API mode and send messages to the coordinator. I'm not sure if i can just do simple send command or if I need to specify the address or if the fames have to be formatted.
Each xbee is connected to a PC. I'm using python 3.4.
Coordinator in API mode to receive messages:
Continuously read the serial port and process IO data received from a remote XBee.
from xbee import XBee,ZigBee
import serial
ser = serial.Serial('/dev/...', 9600)
xbee = ZigBee(ser)
while True:
try:
response = xbee.wait_read_frame()
print(response)
except KeyboardInterrupt:
break
ser.close()
Has someone else done this or know of a site that could help me explain how the router in API works? All I want to do is to send messages from the router to the coordinator.
API mode works the same whether the device is configured as coordinator, router or end device. If your router is always sending data to the coordinator, there's no need to run it in API mode -- just keep it in AT mode with DH and DL set to 0. It will automatically send frames to the coordinator containing all data that comes in on the serial port.
If you need to use API mode on the router for some reason, just use the python-xbee library you're already using on the coordinator.
To communicate in API mode, you must send frame.
A frame is compose by a header and a footer.
There is some library to help you communicate in API
http://ftp1.digi.com/support/utilities/digi_apiframes2.htm
this web site show you how to communicate in API
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.