shows results list in portrait on tablet.
shows split in landscape on portrait.
Since email currently has no concept of saving the currently
selected message on orientation changes, there are some issues changing orientation
and restoring to the correct search state.
fixes coming in the next cl.
Change-Id: Ib0b98c4018c2ae0fabc2c78dfce4d3a197837d4f
On two pane tablet in portrait mode, the message list items may not
be wide enough to be considered "WIDE_MODE", however, when they are shown
in the message list mode, they should ALWAYS use message list mode backgrounds.
Fixes b/5641014 email portrait: missing the vertical divider between folders and messages
Change-Id: Ied05386f1ab62c48b1824647c95a6f72baabc859
- Message list is collapsed by default in 7 inch and 10 inch portrait. It can cause confusion when searching.
- We should uncollapse the list in this case.
Bug: 5587501
Change-Id: I2a272e28e1cad7895049c4aa4ee1d8d2918efba9
We always switched to combined view when we tapped "Starred" in a
mailbox list. This was confusing since tapping to show the mailbox list
will take you to the mailbox list for the combined view, even if there's
only one account on the device! Other confusing things happened like
showing coloured account chips, even if there's only one account.
This fixes it so that we pass the account ID when building the
selection. Lots of wiring to make it happen, but very little change
overall.
Bug: 5388326
Change-Id: I1fe52f211cceca0c1b26581e200f3c7adcd0734a
This is a kludge - the real solution is to use the proper action modes
in the framework. That's too large to do this late.
Bug: 5232787
Change-Id: I76b68b250c384bdabf51e8831f833afd65c0c73b
- since listContext can be null, this code was not safe.
we also filter out the search mailbox too, so it's no longer needed.
- don't ask to highlight a mailbox if doing a search
- remove a call in MailboxListFragment that was unconditionally telling
callbacks that something was selected when we started loading - this was
technically lying and if the item isn't in the list that was selected,
nothing should be called (as in the case of search). This was just an
optimization anyways and that callback is invoked later when the mailbox
list load completes.
Bug: 5037629
Change-Id: Id31c6795af9e64fa8682b67de9ab90540ee660df
- Use PreferenceActivity, in the old style, meaning without PreferenceFragment.
- If setting Inbox, change the account settings instead of mailbox settings.
- Use the DialogWhenLarge theme, meaning it's a full-screen avitity on the
phone and a dialog on the tablet.
- Also fixed the bug that we the menu items that are made invisible by
UIControllerBase may be made re-visible by the 1-pane controller.
TODO The menu item shouldn't be shown for non-syncable mailboxes.
Change-Id: I02b2faf6f593e1e2eb370217c27801aa58ca7e6c
It was accidentally happening because search doesn't show the mailbox
list, but explicit > implicit.
Change-Id: Ifb8354dbb366f4c8328bef31d4e251166ae6876a
- shows the title of the message in the action bar (visuals not final -
need to extend the width and hide the account name)
- ensures that tapping up/back from a message view from a search result
list doesn't exit search
- ensures that tapping "app up" from a collapsible tablet view doesn't
exist the search unless the left pane is uncollapsed
Change-Id: I2b21a430d12148cf72237060c05312c7a23e2b3b
There are needed for the back navigation when a message
is opened from a deep link, but now that we always have a list context
they're not necessary.
Change-Id: Iba2d0b2f31f4539f6e872970b514574347e248c5
- Moved MessageOrderManager code from 2-pabe to the base class.
- Most of the code is shared between 1-pane and 2-pane.
- Also fixed the bug where we re-created MessageOrderManager every time
the user taps newer/older, which was the reson the newer/older button
temporarily got disabled when you tapped them.
Before this CL we stopped MOM in uninstallMessageViewFragment, but now that
we don't reuse fragments this means we stops MOM when we remove the current
message view, and re-created a new one when a new message view is created.
Now we stop MOM when the right pane gets hidden (2pane) or when showing
the mailbox/message list (1pane).
- Also removed a now unused callback onMessageShown() from MessageViewFragment.
We used to update MOM on this event, but now we do this in
installMessageViweFramgment().
Bug 4575586
Change-Id: Idc4aba184f318e0c086afc29dcbe42364e2b51b3
- update hint based on the mailbox being searched
- ensure that we use the original searched mailbox as the mailbox to
search for subsequent search (i.e. a search while we're viewing search
results) and not the search mailbox
Change-Id: Ic8663272173ce386dcd13fdf0369e918fb895be8
Renamed onPostExecute to onSuccess and made sure it won't called
if a task is cancelled in time.
Also removed isCancelled(). To implement it right we should make sure
that onPostExecute() isn't finished when setting mCancelled, but it's a bit
of a pain to implement right, and we don't really have to use it.
Change-Id: I3a0baf504506ffc4952a5553f7098a8415842fa3
- Don't use the action bar spinner.
Instead use a custom view to show the current account.
(It's not a spinner; now we show the dropdown list by ourselves,
which gives us more detailed control.)
- Also show the current mailbox name/unread count with the account name.
- Removed the mailbox info loader in ABC.
Instead, now the AccountSelectorAdapter loader loads the current
account/mailbox name, and the unread count as extras.
- Now ABC.Callback.onMailboxSelected passed an account ID as well
as a mailbox ID.
- There's new code paths that can cause the "fragment transaction in
onLoadFinished" exception. We need to fix this properly, but
for now we just use commitAllowingStateLoss().
Bug 4948352
Change-Id: I73bb8b7530f8328ca1c86382ac0a54086ad061d7
Before this CL, we had this crazy plumbing from MailboxListFragment
to ActionBarController to update the current mailbox name/message count.
This wouldn't work on 1-pane, so now ABC just gets the current mailbox id
from UIC and loads the name/count with its own loader.
Also...
- Fixed bug 4904450 and bug 4460470: Now we consistently use FolderProperties
to get proler display names and message counts.
- Renamed some confusing names in AccountSelectorAdapter
Change-Id: Ic7bea6da6d2859006fb8f9263024c7d5e62b1e7f
- actually fires off a new instance of our Activity for search, instead
of killing the old one
- exiting search mode from a search result now works and pops the
activity stack
- doing a new search clears the input box as expected
- the search term is actually shown at the top in the results list
Change-Id: Ia6b92042e26a2e44b8cb45fe1d5b3bfb40cfd6da
I'm changing it so that inbox finding happens at an earlier stage so
that the UIController.open() methods can be simpler. Specifically: I
want them to just always accept a mailbox, and not have to deal with an
intermediate state where it's still looking for a mailbox.
Change-Id: I1c5be783859a3bee7e46007e778de13eb1685cbe
This moves the logic for performing the search closer to where it will
actually happen (i.e. on Intent resolution). A lot of this is still
temporary code. I will follow up with some larger changes to extend the
UIController API so it doesn't have to do hacks internally.
Change-Id: I1eb84d26ee3dcbfa0b68dbd37dcb0a6180452962
- Instead of the search dialog, show the search widget on the action bar.
- Launches a new activity for search, but still uses the temporary search code
- Search still works only on two-pane.
Change-Id: I1d36ad3416c7dff9579cf37e40e49e31c9d99219
- Allow going back from the message view to the message list with restoring
all the state on the message list. (batch selection and scroll position)
- Also make "back" work for the message list <-> mailbox list navigation,
but only 1 level at most.
(Only the system back key works for this; the action bar home icon will
not.)
- As discussed offline, it uses our custum "back stack" (which can hold
at most 1 fragment) using the new fragment APIs, attach and detach.
- Removed commitFragmentTransaction() from the base class, as now there's
nothing really in common between the two UI controllers in terms of how
they use the fragment transaction.
Change-Id: Id626ce99beb1f4dceb999dc04bf7d3e5d57a8198
- 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
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
- 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
- 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
Now we reuse the same instance of the fragment for nested mailbox
navigation. (Don't use fragment transaction)
"CursorWithExtras" now only has the child count, so I removed the
bundle version and added a concrete class to MailboxFragmentAdapter.
With this CL the nested mailbox navigation on 1-pane should work, but
not back navigation. (Back press event isn't connected to the
fragment yet.)
Change-Id: I2c23651d9c8edb5fe062c68bbb9b462c8949ded4
Do all the clean-up stuff in onDestroyView() rather than onDestroy(),
so that no callbacks (such as the controller callbacks and
AsyncTask.onPostExecute()s) will work when it doesn't have views.
Change-Id: Ic4aa771d28209ee7b56ac4d228488768ae998dd8
All shortcuts now have a mailbox associated with them. When launching
the app via shortcut, we want to show the messages within that mailbox, but,
we do not want to navigate into the mailbox; unless the mailbox has children.
Since we don't want to put too much informatin into the shortcut, we must
perform these checks at runtime. So, if ever we try to load a mailbox that
doesn't contain children, we load it's parent instead.
Change-Id: Idb5dbc7cd740b270a0068811abe685f963ca2c0b
- Renamed some methods in MessageViewFragmentBase.Callback
- Removed unnecessary argument from a callback.
- Removed obsolete comment.
Change-Id: Ia5af222971bfe6b943c98208b539946f14f16aa8
Mindy Pereira