| 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
|