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
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
- 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
They're variants of getView() that will *not* crash even if the view
doesn't exist.
I didn't add them before as they would be exactly same as findViewbyId(),
but now that we make use of generics they'll be handy.
Change-Id: Ib649e591a987183064c7e98afe0e2414d9e62280
Added two new functions:
- UiUtilities.getView()
is a fail-fast version of findViewById(). Crashes when there's no view
- setVisibilitySafe()
same as View.setVisibility, but doesn't crash even if a view doesn't exist
Let's try to avoid the use of findViewById(), and instead use getView(), *right
after* the layout is inflated, so that we'll always fail-fast if a layout
doesn't have a required view. (Rather than getting a NPE only when the view
is really accessed, which can be in a code path which is rarely executed--e.g.
only when there's a protocol error.)
Let's only use findViewById() only when we're sure no all the variants of a
layout have the view in question and leave a comment to make it clear it's on
purpose.
(UiUtilities has been moved from com.android.email to
com.android.email.activity)
Change-Id: I36e0bab65a989f5d34cf636f13e1eaee084547af
Mindy Pereira