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
Related
Dropbox has more than 300M user.Dropbox desktop application need to keep connection alive with dropbox server for every updates.
But how does dropbox server keep connection alive with all its desktop user?
The dropbox client keeps a TCP connection constantly open to listen for server-side notifications. When it receives a notification, the client initiates an HTTPS conversation to see what changed and download it. When something changes on the client side, it also initiates an HTTPS conversation to update the files on the server.
Source: http://www-net.cs.umass.edu/imc2012/papers/p481.pdf
The Dropbox client keeps continuously opened a TCP
connection to a notification server (notifyX.dropbox.com),
used for receiving information about changes performed else-
where. In contrast to other traffic, notification connections
are not encrypted. Delayed HTTP responses are used to implement a push mechanism: a notification request is sent by the local client asking for eventual changes; the server response is received periodically about 60 seconds later in case of no change; after receiving it, the client immediately
sends a new request. Changes on the central storage are instead advertised as soon as they are performed.
While the decrypted headers give no indication of what servers Dropbox uses to keep so many open TCP connections, people report being able to keep over 600k (https://stackoverflow.com/a/9676852/15472) or even over 1M (http://blog.whatsapp.com/196/1-million-is-so-2011). With enough load-balancing, 300M users, of which only a fraction of which are connected simultaneously and actively share data within each other, certainly seems within reach.
I doubt that all 300M users are connected at the same time... And by the amount of storage they provide, they will have enough servers to handle the needed amount of connections, maybe 1% of their user count at a time.
If you like to investigate yourself, you could use tools like TCPView (part of Sysinternals Suite) to check which connections are opened by the application, or Wireshark to check the transferred data.
I assume that you mean 'update' of storage content; that could also happen on fixed intervals by opening a connection, getting the files list and closing the connection afterwards. In this case the connection would be used for a few seconds in an interval of e.g. 5 minutes. This would again reduce the number of needed simultaneous connections by factor ~100.
I have a database that uses #MailSend and .Send() methods on various forms for notifications. We had an issue where our mail server went down so email was unable to be sent out.
I'm under the assumption that running #MailSend and .Send() on forms will be processed locally by the person running the action which will not queue the mail if the mail server set on the client is not responding.
If my assumption is correct, is there a way to fix the issue of mail not queuing? One thought is having mail processed by an agent running on the server, but I'm not sure if this would be the best way. Is this the only way to workaround this issue?
Any thoughts are appreciated. Thanks.
Within the application the user can subscribe to notifications or unsubscribe. This events are handled by a Worklight adapter that register or delete in the database the users subscriptions.
But in case the app is uninstalled without unsubscribing, in the database will remain the user subscription.
How can this be handled?
Is there any way to notify Worklight of the application uninstall?
As explained in the Idan answer, the subscription will be removed by Worklight automatically after a not specific amount of time depending on the notification provider.
http://developer.android.com/google/gcm/adv.html#unreg
https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html Look for "General Provider Requirements" and "The Feedback Service"
For Apple how proceeds Worklight? Does it check each day the feedback service and then removes the corresponding notifications?
I have tested with Android and a trace appears in the WL Server console saying that the subscription has been removed "because the notification was rejected by the server (NotRegistered)".
This was after two hours since I uninstalled the application and I sent 23 notifications with the application uninstalled.
Is it possible to add a custom handler for this "event"?
Reading the documentation, in the WL.Server.createEventSource method, the "onDeviceUnsubscribe" property of the "options" parameters says:
"The name of the JavaScript function that is called when the device subscription is removed by a client request or by the cleanup task"
What is a cleanup task? My first thought was that this callback would be invoked in the use case we are discussing but I have tried it and when the notification is automatically removed this callback is not called.
Currently I'm sending SMS to my customers, when the customer installs the application I will send notifications instead of SMS but in case the customer uninstalls the application I need to know it for starting to send SMS again.
The Worklight Server cannot be notified (by you) that the application has been uninstalled - this is a user action that you do not have any control over.
That said, you do not need to worry about this, because this exact scenario is being handled for you.
This is the flow:
In case a push-enabled application has been uninstalled, and you are sending a notification... this notification arrives to the APNS/GCM/MPNS server, which then send the notification to the device, to be displayed in the app.
Because the app is no longer installed, the device OS will provide feedback to the APNS/GCM/MPNS server that the notification failed to display.
Eventually, what that will happen is that the APNS/GCM/MPNS server will notify the Worklight Server that the token is no longer valid and the subscription will be removed from the database.
Worklight cannot control when will the APNS/GCM/MPNS server notify the above, though. For more information, consult with the respective service documentation.
The additions to your edited question are not totally clear, but here goes:
APNS token invalidation - only Apple can tell you about it. It could take minutes, hours, days, weeks... there are all sort of scenarios, so no specific time frame can be guaranteed.
The cleanup task is likely a task done by Worklight Server to remove stale subscriptions. It runs every 1 hour and connects to APNS feedback service to retrieve a list of inactive devices. On receiving the list of devices, it removes the device subscriptions from the database.
onDeviceUnsubscribe - Once the device is unsubscribed onDeviceUnsubscribe will be triggered. The idea of this callback is to allow the developer to notify the enterprise backend system that the device is no longer able to receive push notifications so that the backend will no longer try to send them. This is where you could tell your backend system to send SMS instead. But, did you actually implement it (the callback)?
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 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