I've noticed that if I get out of coverage, the push e-mail via IMAP IDLE won't notify about the e- mail that has arrived in the "off-data" time. More, if the time of the scheduled check is passed and no check was possible because there was no data coverage, the check gets skipped until the next one. As I love the push feature and the one-check-per-hour (for being sure it has collected all the e- mails), it would be nice if the K9 could re-schedule the failed checks after reconnection. Or, if the push feature is enabled, any time it gets out of coverage and then re-get data connection.

Other users have specifically asked to not have the missed full checks rescheduled to run just after data coverage is reenabled. This is because on EDGE networks, data connectivity is lost during every phone call. Doing a full check after each phone call causes usability issues. I supposed this could become a configurable behavior.

The push system is supposed to immediately pick up any mail that arrived while data connectivity was unavailable. I've tested it, by setting Airplane mode, sending a message to myself, then unsetting Airplane mode. In those cases, it works for me, and picks up the email immediately. However, this isn't exactly the same as the case you mention. I'll look to see if there is any way to make this more reliable.

Yes, a configurable behavior would be the best option, I guess.

Disabling the radio connectivity and re-enabling it (even after some minutes) makes the push system to get all the e-mails arrived in the meanwhile. I can see, by my courier imap's logs, that the k9 reconnects and immediately finds the new messages. I've noticed that this doesn't happen when the data coverage gets lost. I don't know why as it should be exactly the same scenario, but I've experienced it many times in the last days.

I'm ready for any test and will keep a close eye on this behavior in the next days.

Thank you!

I suspect the difference is that switching the Airplane mode off and on is done through UI activity that keeps the phone awake long enough for the push system to fully initialize. Perhaps the connectivity change event doesn't keep the phone awake long enough. This should be solvable through the use of another WakeLock.

Dan, I guess it may be right. What I've also noticed is that the Android devices are lazy, when in standby, to change connection type. If I'm under wifi coverage at home and I go out, it often happens that the phone doesn't connect via mobile radio for many minutes. If I awake it, using the menu key, it connects in some seconds. Same behavior in the opposite situation. Differently from BlackBerries, that always try hard to keep at least one connection, the Android seems to think that the data connection is not that important (maybe to save some battery). So it may be related.

I have found one point in the code that should be easy to change which will help. I'll pursue it more this weekend. Do you make your own builds of K-9? If so, I can give you a patch later to try. Or I can find a metal box to put my phone in...

Also, the whole way we handle WakeLocks when getting alarm and connectivity events needs to be reworked. I don't know if I can do it safely for this next release or not.

I usually use the ones provided by this site (the last beta, at the moment) since I've bought my first Android device just 4 days ago :) But I don't think I'll have problems building the app, so feel free to send the patch and I will try to build it. It's also a good exercise as I'm trying to become familiar with Android development.

It's a one line patch, I'll attach it to this issue. I may have crude solution to the broader issue, as well.

Great. I'll be waiting and will try :)

Index: src/com/android/email/mail/store/ImapStore.java

--- src/com/android/email/mail/store/ImapStore.java (revision 883) +++ src/com/android/email/mail/store/ImapStore.java (working copy) @@ -1872,7 +1872,7 @@

     public void start() throws MessagingException

{

• receiver.pushInProgress(); Runnable runner = new Runnable() { public void run()

r888 has more extensive changes to fix problems with Push mail fetching email after connectivity is restored.

The original request in this issue also contained an enhancement request for optionally causing an immediate folder sync when connectivity is restored. I'm leaving this issue open as an enhancement request for that feature.

Ok. So going to compile r888 and see how it behaves. Thank you.

I just logged a similar problem, issue 827. I use wisyncplus to deliberately toggle off APN internet connection to save power. If I am working on my desktop computer, I can pick up my email there and it makes sense to turn off my internet connection on my phone. If I forget to turn my connection back on immediately, I can miss emails because it doesn't pick new mail that was received when the connection was off.

I also reported a problem with false new mail notifications after reconnect, issue 828.

This issue was closed by revision r1061.