fix slow 2-pane transitions; fix 2-pane animations in portrait

The instant visibility changes on layout after mode changes were
preventing the animations from running. Defer any cases when moving to
invisible state until after the transition is complete.

Move FAB reveal earlier when going CV->TL on 2-pane portrait by
triggering list-visibility-changed manually when entering TL mode. TL-
>CV hides the FAB after transition complete as usual.

Position and animate 2-pane elements after normal layout, since some
size calculations depend on having performed a layout already. Fixes
some FAB-related race conditions I started seeing with the animations
working again. b/17514925 tracks the fact that FAB shouldn't need to
move about in this way in the first place (since it's pretty much always
tethered to TL).

Also short-circuit an infinite loop that triggered continuous relayouts
when an Ad is present. This change reverts to the older logic of only
positioning/animating panels on known layout change events, which also
has the side effect of smoothing out the animation.

Bug: 17477114
Bug: 16818991
Change-Id: Ice1f6b896b9d7dc434debb3c2cf15aec87551ebc
diff --git a/src/com/android/mail/ui/AbstractActivityController.java b/src/com/android/mail/ui/AbstractActivityController.java
index f9d6305..431b06c 100644
--- a/src/com/android/mail/ui/AbstractActivityController.java
+++ b/src/com/android/mail/ui/AbstractActivityController.java
@@ -1162,6 +1162,8 @@
 
     @Override
     public void onConversationListVisibilityChanged(boolean visible) {
+        mFloatingComposeButton.setVisibility(visible ? View.VISIBLE : View.GONE);
+
         informCursorVisiblity(visible);
         commitAutoAdvanceOperation();
 
@@ -2208,23 +2210,12 @@
     protected abstract void resetActionBarIcon();
 
     /**
-     * When should the compose button be visible
-     */
-    protected boolean isComposeVisible(int mode) {
-        return mode == ViewMode.CONVERSATION_LIST;
-    }
-
-    /**
      * {@inheritDoc} Subclasses must override this to listen to mode changes
      * from the ViewMode. Subclasses <b>must</b> call the parent's
      * onViewModeChanged since the parent will handle common state changes.
      */
     @Override
     public void onViewModeChanged(int newMode) {
-        // The floating action compose button is only visible in the conversation/search lists
-        final int composeVisible = isComposeVisible(newMode) ? View.VISIBLE : View.GONE;
-        mFloatingComposeButton.setVisibility(composeVisible);
-
         // When we step away from the conversation mode, we don't have a current conversation
         // anymore. Let's blank it out so clients calling getCurrentConversation are not misled.
         if (!ViewMode.isConversationMode(newMode)) {