should be used.
From now on, UiUtilities.useTwoPane() should be used to see which UI
should be used.
You can pass the DEBUG_PANE_MODE extra when launching Welcome
to force which UI mode to use. (See the comment inside Welcome.)
Change-Id: Iefa3737e4979eb55f7986a9033ff9c6266d32f52
- Now we "uninstall" a fragment in Fragment.onDestroyView.
i.e. a fragment transaction is actually executed.
- Maintain our own "about to be removed" fragment list to avoid
double removal of a fragment.
Change-Id: I61328e0a09a7af00cbb0e6ba10a2d39c11b5c3dc
Previously, we were deciding whether to show the spinner if the returned cursor
had more than 1 element. However, the cursor would _always_ have more than one
element because it contains a header in addition to the account information.
We now save away the number of accounts and the size of the recent list into the
cursor so we can use those counts to determine if the spinner should be shown.
Both of these counts are necessary as we want to show the spinner even if there
is only a single account as long as it has at least one recent mailbox.
Change-Id: If428c496a548a25f6b5cd7301ddb5c0d6876750c
The ability to change mailboxes using the spinner is currently only implemented
for the two-pane UI. one-pane implementation will come in a future CL.
Change-Id: If72e9d9d607508553c918f5523e748e8a481ff84
This will make the message list a lot snappier.
We were using two different loaders for the message list; one is to load
the meta information and the other to load the actual message list.
Unify them using the CursorWithExtras pattern.
Change-Id: I02957bbca1b1fb74ca6eca14ad2535dfdbf03a5a
we need to return 5, post filtered, results. previously, we were returning
5, pre filtered, results. Also add a test to catch this condition.
Change-Id: Id25f4bf79081c42a2012e0e51b36142120c83b20
- Now that fragment useage is simplified (e.g. no new fragment
creation for nested mailbox navigation), most of the fragment
operation code for 2-pane is reuseable for 1-pane as well,
so moeved it to the base class.
- Temporarily added "Show all folders" as a menu option on 1-pane.
- Added "opener account id/mailbox id" to the message view fragment.
They are not used by the fragment itself, but they're used
by the UI controller for the back navigation. (And now the UI
controller doesn't maintain the current IDs by itself; rather
it gets them from the currently-active fragment.)
- Use async fragment transaction on 1-pane too, now that it always
gets the current state from the active fragment.
- Changed the timing when we install fragments from onAttachFragment
to fragments' onActivityCreated. So now all installed fragments are
created.
TODO Now that all installed fragments are guaranteed to be created,
remove all special trealment for the fragment argument accessor.
(They were meant be safe to call before onCreate, but it's not
necessary any more.)
Change-Id: I0ed100c3f0b460835b164c0dc908ea483a4e46ee
Upon hitting reply all, all email addresses except that of the source message sender
go in the CC: field. Previously they all went in the TO: field. Updated 3 tests
in MessageComposeTests.java (testReplyAllAddresses1(), testReplyAllAddresses2(), and
testReplyAllAddresses3()) to reflect this new behavior.
Bug: 4534058
Change-Id: I852daebdd8843a45f685eecc67f757c87925bb6c
The last touched time will track the last time a message within that mailbox
was read. This will be used for the recent list.
Change-Id: I97a5fda52fd09b416fc3278a11a87b807da05c9c
the spannable string builder assumes the given char sequence is non-null.
we now ensure that's always the case.
Change-Id: I12e7081e5348d797feab6ad17452b73a52feaf13
The mailbox list for widget configuration should only include two mailboxes --
1. an account's full inbox (both read & unread) and 2. an account's unread
inbox (similar to #1, but, only contains unread messages)
This also applies for the combined account view.
Change-Id: I5640fd8572d385703db04ca613f5b1f35f3952da
- Moved MailboxFinder logic to UIControllerBase so it can be reused for 1-pane.
- Make sure MailboxFinder runs only while the activity is resumed.
(we don't want to get callbacks when it's not, because we can't perform
fragment transactions.)
- Make sure MailboxFinder is restarted if the activity gets re-created
while it's still running.
Bug 4522010
Change-Id: I4486ecfa44dd700d28c424bc5eb7104d3043cf7d
- The drawable for the active drop target background was static, and
shared between items. But StateListDrawable has inernal state and
shouldn't be shared.
- Also make sure not to set the same background more than once.
For some reason, they will cause visal glitches when we switch to synchronous
fragment transaction.
Change-Id: I10fede2ad4e595f74d61768907b5b70fd5d4da21
