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.
Only reschedule polling and setup pushing when necessary due to
particular setting changes. Makes the K-9 Mail UI much more
responsive to setting changes that do not affect polling and pushing.
The poll schedule is deliberately only rescheduled when the period is
decreased. An increase in period will still allow the next scheduled
check to happen as originally scheduled.
count, scoped for the Activity, the in-progress operation, the account
on which the operation is in progress, the folder for the operation,
when appropriate, and the progress of the operation, when it applies
to multiple items. For the MessageList, also use the determinate
progress bar to show progress for synchronization of the folder being
displayed.
Fixes Issue 924.
Also, a minor change that might help with Issue 913, by putting the
insertion of the pending command into a background thread.
