Implement server polling

[ZeroCoolZ]

Hi!

I know some people asked for some IMAP/Push feature and that you may be working on that.

But in the meantime, a feature that auto-refresh status every 10 or 15 minutes would be great! I would guess it's an easy feature to code but I don't know...

Thanks!

[octo]

Reassigning to 2.0, since it will be an option there (for those who don't want their BB talking to the server 24/7). Not simple or possible on 1.x.

[octo]

This feature, when combined with IMAP IDLE, should make it possible to leave LogicMail running continuously in the background. It will take some research, and may function differently for IMAP and POP, but it needs to get done.

The biggest protocol difference is that with IMAP we can maintain open server connections for far longer. That is for two reasons: First, POP essentially locks the mailbox when you're connected. That means no one else can use it, and new messages do not magically appear. Second, IMAP has the IDLE feature which could allow indefinite connections in rare cases of continuous network coverage.

[octo]

(In #253) The short-term workaround for this is to close and re-open the message or folder list screen that the error appeared on top of. This should re-try the failed operation. For a developer ramble about the real fix, feel free to read on...

Both IMAP and POP are susceptible to this issue, in different ways. With IMAP, the IDLE-checking behavior will cause the IOException (with "Bad socket id") to appear immediately. With POP, it won't appear until the user deliberately does something that requires I/O.

The fix for this issue could be quite involved, and will definitely be required before #79 can be implemented for 2.0.

The first step of working this issue will be inside the state machine that handles the network connections (AbstractMailConnectionHandler). It needs to specifically identify IOException errors that are due to runtime connection failures. It then needs to intelligently decide whether to retry (without flushing the request queue) or fail. It then needs to pass up additional information in the request failure notification, indicating what just happened.

The second step involves reviewing and modifying at least some of the request-handler code inside the object model, such that connection-failure errors are not always fatal to a complex request (such as a folder or message refresh).

[octorian]

In [859]:

Timeout-based disconnect and polling for locked mail stores (POP) (refs #79)

[octorian]

In [863]:

Added distinction between background-polling and user-triggered operations for status/error notifications, and made connection failures trigger the polling thread (refs #79)

[octorian]

In [964]:

Added experimental WiFi connection handover support (refs #79)

[octo]

May still make fixes and improvements, but the basic feature is sufficiently implemented to close this ticket.