History log of /packages/apps/Email/src/com/android/email/activity/UiUtilities.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
d6decef1d2a8d14aa8a65229bc784e6fdbb31864 01-May-2012 Mindy Pereira <mindyp@google.com> Make search interaction match gmail.

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
/packages/apps/Email/src/com/android/email/activity/UiUtilities.java
347ae23b6932fe994b03909bf90854888c438517 07-Jun-2011 Makoto Onuki <omakoto@google.com> New method to see whether 1-pane or 2-pane UI...

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
/packages/apps/Email/src/com/android/email/activity/UiUtilities.java
ab40c988216b32ed145c0cad45c25e9cf2509c85 06-Jun-2011 Makoto Onuki <omakoto@google.com> More work on fragment install/uninstall.

- 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
/packages/apps/Email/src/com/android/email/activity/UiUtilities.java
3d9b8e76f0a396370a5c0be99a34bf7c24bd20dd 03-Jun-2011 Makoto Onuki <omakoto@google.com> Implement 1-pane navigation.

- 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
/packages/apps/Email/src/com/android/email/activity/UiUtilities.java
c0491ed1952633103732ae90bb26cf533304bcc3 09-May-2011 Makoto Onuki <omakoto@google.com> Add UiUtilities.getViewOrNull()

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
/packages/apps/Email/src/com/android/email/activity/UiUtilities.java
256652050c8c047d1879621805f028454e83b677 29-Apr-2011 Ben Komalo <benkomalo@google.com> Genericize UiUtilities.getView

Change-Id: I7142d4a57170e3074dc896149bf95ed6d2677bdd
/packages/apps/Email/src/com/android/email/activity/UiUtilities.java
2fbb3db5d86210d03175ce77ff08c989a96c5864 28-Mar-2011 Makoto Onuki <omakoto@google.com> Don't use findViewById (part 1 -- account setup)

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
/packages/apps/Email/src/com/android/email/activity/UiUtilities.java