Since MailService uses the auto shutdown mode of CoreService we can't
use CoreService.execute() with a startId parameter that is null. So this
change should also fix the problem some users reported where the pushers
weren't set up correctly.
See issue 2777
This revision respects the intention of r3011 that when K-9 Mail is
set for pushing only no message is displayed, as that condition is a
normal state. However, it provides valuable feedback in other cases
that synchronization is off-line, as was done in r1433.
Although the case when the user has intentionally set no account for
polling or pushing can be considered "normal" and therefore unworthy
of a message, it turns out to be a significant burden to detect that
situation when the network is offline, since we normally do not even
try to figure out the account configurations in that case. Therefore,
without making substantial, otherwise unwarranted, changes to
MailService.java, "Syncing off" would be displayed sometimes to such a
user, and sometimes not. Since it is presumably a rare case, and
there is minimal harm to display the "Syncing off" message, the
message will be consistently displayed when no account is set for
polling or pushing.
Note to translators:
"Syncing off" is different than "Polling off". The new phrase "Syncing
off" means that K-9 Mail is not performing any synchronization with
any mail server. The prior non-English phrases for "Polling off" are
currently in-place as translations for "Syncing off", as it seems that
the meanings are close enough that it would be better to show the
obsolete translations that to fallback to the English "Syncing off".
However, better translations of "Syncing off" would be welcome.
* mail-on-sd: (40 commits)
Added more comments to explain how the locking mecanism works for LocalStore
Fixed wrong method being called during experimental provider initialization (since provider isn't enabled, that didn't harm)
Add more comments about how the various StorageProviders work and how they're enabled
find src/com/fsck/ -name \*.java|xargs astyle --style=ansi --mode=java --indent-switches --indent=spaces=4 --convert-tabs
French localization for storage related settings
Remove unused SD card strings (replaced with storage indirection)
Merge mail-on-sd branch from trunk
Reset mail service on storage mount (even if no account uses the storage, to be improved)
find src/com/fsck/ -name \*.java|xargs astyle --style=ansi --mode=java --indent-switches --indent=spaces=4 --convert-tabs
Migraion -> Migration
move the Storage location preference into preferences rather than the wizard.
Made LocalStore log less verbose Added @Override compile checks
Added ACTION_SHUTDOWN broadcast receiver to properly initiate shutdown sequence (not yet implemented) and cancel any scheduled Intent
Be more consistent about which SQLiteDatabase variable is used (from instance variable to argument variable) to make code more refactoring-friendly (class is already big, code extraction should be easier if not referencing the instance variable).
Added transaction timing logging
Factorised storage lock/transaction handling code for regular operations.
Use DB transactions to batch modifications (makes code more robust / could improve performances)
Merge mail-on-sd branch from trunk
Update issue 888 Added DB close on unmount / DB open on mount
Update issue 888 Back to account list when underlying storage not available/unmounting in MessageView / MessageList
...
Extracted notification related settings in separate class (see Issue 2268)
Update issue 371
Status: Fixed
Added ability to disable LED notification for new messages
- Created "controller" and "mail.filter" package
- Moved a lot of classes to new/other packages
- Removed unused classes: NoSuchProviderException, MessageDateComparator
Simplify WakeLocks use by pushing.
Correct fault in IMAP IDLE WakeLock usage. The ThreadLocal in
MessagingControllerPushReceiver meant that the WakeLock acquired when
the DONE was sent was not being released when entering back into IDLE
state.
Consolidate the account notification so that all Activities use the
methods in MessagingController.
Utilize cketti's AutoSyncHelper in order to provide a way to make K-9
Mail obey the global Auto-sync setting. K-9 Mail doesn't obey the
Auto-sync setting by default because K-9 Mail isn't listed as one of
the listed applications.
Fixes Issue 772
Fixes Issue 852
Issue 300: Handle incoming IMAP tokens in a case-insensitive manner
Issue 772: Add Yahoo workaround
Issue 852: Add configurable IMAP IDLE refresh frequency in Incoming
server settings
Also:
Add configuration option for whether push system executes a poll on
each connect.
Move the configuration for the maximum number of push folders to the
Incoming server Settings.
Look for + as acknowledgement that we're in IDLE mode, not "idling"
string.
Also, to help with battery life:
1) Give up trying to IDLE after 10 failures.
2) Increase retry delays
of the last successful periodic mail and computes the next start time
as an offset from that successful finish. The ramifications of this
new method is that changing polling interval on an account does not
force delaying all accounts to poll next in the future by the new
interval. Instead, K-9 Mail now adjusts the next poll time based on
what the next poll time should be based on the last poll finish and
the new interval.
Example 1: In the old way, if the old polling interval was 1 hour, and
the next poll was 50 minutes away (10 minutes have passed), and you
changed the interval to 15 minutes, the poll would happen 15 minutes
from now. In the new way, the next poll will happen only 5 minutes
from now, which is 15 minutes since the last poll.
Example 2: In the old way, if the old polling interval was 1 hour, and
the next poll was 10 minutes away (50 minutes have passed), and you
changed the interval to 30 minutes, the poll would happen 30 minutes
from now. The next poll would then happen actually 80 minutes after
the previous poll completed. In the new way, it'll actually happen
immediately, because the time for the next poll, based on the new
schedule, has already passed.
Similar scenarios happen when a loss of network connectivity
occurs. In the old way, polling would resume using the restoration of
connectivity as the starting point. Each time network connectivity
was lost and restored, the next poll would be further delayed. *If
connectivity was lost and restored frequently, a poll might never
happen!* In the new way, the next poll is rescheduled based on the
time of the last successful poll, so will be rescheduled just like it
was before the loss of connectivity. If the time has already been
passed, the poll will happen immediately.
