I need to get gmail or other emails like yahoo/hotmail (new email)notifications from the server without polling. Since am building it on a cross platform mobile app polling or persistent connection is not a ideal way of doing it. What is the best way of doing it.
idk if it is a pc platform you are talking about,but in general you could open a server on the client that will be open to receive a message if there is a new mail. then on receiving this message you can download the new mail or whatever
Related
I am trying to build an application that will receive pushed email from an IMAP server (such as Gmail). I don't want to be constantly fetching the inbox, but instead receive pushed emails. How may I accomplish this and which direction do I need to take?
IMAP IDLE - server updates to the client in real time
You may use IMAP with IDLE command.
It will keep single IMAP session open and notify you about new messages.
Gmail servers support IDLE
There seems to be a Visual Studio extension supporting IDLE
you need to refresh within some interval to check for new emails.
Some sample code in C# here http://www.codeproject.com/Articles/24535/Email-Client-Application-by-Implementing-Our-Own-S
Friend, I am working with a chat application. In my chat application I am using GCM for push notification. GCM is working fine with my application. But not all time I am not able to get GCM message. Sometime I receive GCM message and sometime don't. Why so? I searched for GCM message failure but did not find the right one.
Anyone, can please help me?
When you post a message to the Google GCM server (at https://android.googleapis.com/gcm/send), you need to pass three values: registration_id, collapse_key, and data.message. The collapse_key is likely your issue here.
Make sure that you pass a unique collapse_key for each message that needs to be reliably delivered. If you use the same collapse_key for each message, then GCM might drop multiple messages that are sent at around the same time.
You can find more information here: http://developer.android.com/google/gcm/adv.html.
Since you don't give much information about your situation and don't share code snippet it is hard to analyze the problem.But, as it is described in the documentation, GCM makes no guarantees about delivery or the order of messages.
If you are using your mobile internet through any firewall like "Cyberoam" or something like that then it restricts ports for the GCM push notification .Try to implement it using Direct internet connection without any firewall. This Solved Probelem for me. I hope it will help you too.
GCM requires port number 5228, 5229, and 5230 to be open. GCM typically uses 5228, but it sometimes uses 5229 and 5230 that might be restricted by the firewall.
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.
I'm working on a messaging app (something like WhatsApp) and I have a dilemma about implementing it's main functionality - sending message from client1 to client2.
The thing is I'm using a centralized server design, where clients uses NSURLConnection to send messages to the server, the server doesn't keep and manage open sockets and can't send a message for one of the clients, so clients have a timer and query the server every 2 seconds to see if a new message is waiting for them.
The problem with this approach is that querying the server every 2 second seem to kill the battery very fast, so I thought maybe instead of client querying the server, to use APNS so when client1 send a message to the server, the server will send a push notification to client2, then client2 will fetch the data from the server.
Will this approach work with a massive messaging app requiring massive push notification uses?
Yes. I would say this approach is okay and will perform well.
You could also create a socket connection when your application is running in front. But the APNS-way (your preferred way) will also work when the user has quit your app.
APNS can handle huge load. There where only very few delays as far as i noticed.
The PUSH-System on iOS is just a HTTP Connection to apple which keeps the response-channel open for some hours (like loading a webpage for some hours).
It will use around +10% of your battery.
So best would be to not create another keep-alive HTTP/Socket connection and to re-use apples channel (APNS) to save the endusers battery.
In your app you will receive the Push-Notification and you can parse the JSON-Data and then pull/sync with your own server.
You should also take in mind what to do, when your app is not running in foreground (then you might display the received message as APNS messages as WhatsApp does).
I have develop a silverlight 3 chat application in which one user chat with multiple users on a same time.
In my application a chat window is a
silverlight control and a user can
open more than 10 chat windows on same
time in a single browse window.means
every chat window make connection with
wcf.
I have allready increase connection limits of wcf using throttlingservice behavior. It works for multile clinets means multiple browses open on same time on different machines and its more than 10. its ok. but if when one user chat with more than 10 users on same time then on 11th connection its break.
please help me and provide me solution for this problem.
Thanks
I think there is something wrong with your client implementation. Do your clients keep the connection to your server open for too long? Ideally you should only have very compact and short request/reply messages between the client and server such that each connection is only short-lived.
A user cannot send messages from each client simultaneously, I suspect. So you should hardly ever have to open more than one connection between client and server simultaneously.
Do you get the exception if all the other channels are closed? There may be a limit to the number of active connections. You may have to dole out connections between windows when there are more than ten open windows to ensure that you don't attempt to open that 11th connection.