Added RefreshManager, which is responsible for getting refresh requests
from UI and keeping track of what is being refreshed.
Conceptually it's a part of Controller, but extracted for easier testing.
- Now sendPendingMessagesForAllAccounts() is owned by RefreshManager
rather than Controller.
- Also updateMailboxRefreshTime/mailboxRequiresRefresh have been moved
in from the Email class.
- Now MessagingException implements a method to return an error message
for the UI.
The refresh button on 2-pane doesn't work as intended yet, because the
spec is a bit too complicated (as described in the TODO in
MessageListXLFragmentManager.onRefhres()).
This change touches many file mostly because it cleans up a lot
of code duplication.
Change-Id: I058ab745ccff10f6e574f6ec4569c84ac4a3e10e
- Controller.Result is now a class rather than an interface,
so subclasses don't have to implement empty methods.
- Replaced Threads with AsyncTasks, which is more light weighted
because it uses pooled threads.
- Removed the Result argument from Controller's methods.
These argumetns weren't used, except in serviceCheckMail.
Regarding serviceCheckMail, the new code behave differenly from the old code.
If there's already listeners registered when it's colled, they wouldn't get
called in the old code, but they will in the new code.
But I think this difference is okay because that's how it works for
POP/IMAP accounts.
Change-Id: I37a857ce7c089c1a411cb7f1fcfcb72c9f5fd2a6
AccountFolderList, MessageCompose and MailboxList.
Also,
- ControllerResultUiThreadWrapper now takes a Handler instead of an Activity.
So that it can be used from a Service as well.
- ControllerResultUiThreadWrapper.getWrappee() to get the wrapped object.
We'll eventually need this.
- I'll work on MessageList too, but the might be relatively
large, so I'll do that in a separate CL
Change-Id: I281d88d5af1834248ec3f7463f0df3f5635149be
Part 1: MessageView
- It's an attempt to get rid of Handlers from Activities, and
reduce the amount of code that runs run a BG thread in them.
- Introduced ResultUiThreadWrapper, which wraps another Controller.Result
and make callbacks get called on the UI thread.
- It'll make the logic in ControllerResults cleaner and more straightforward.
- ResultUiThreadWrapper isn't too memory efficient because it allocates a
Runnable even if the wrappee's target method is empty.
However these callbacks don't get called often, and optimizing it would
make code more complicated, so I don't think it's worth optimizing.
- Now we can assume all the methods in activities except
AsyncTask.doInBackground runs on the UI thread, with some special exceptions
like MediaScannerNotifier.
In my previous abandoned change, I named methods that can run on BG threads
'*OnUiThread', but now there's no need to do that.
This also means we can minimize the use of synchronizations.
Change-Id: Ia6d9d2a266ebf5a4b23d712e9eaea3272adbd2a6
