summaryrefslogtreecommitdiff
path: root/core/java/com
diff options
context:
space:
mode:
authorAdam Powell <adamp@google.com>2014-02-03 10:16:49 -0800
committerAdam Powell <adamp@google.com>2014-04-15 10:30:25 -0700
commit50d7bfd8224f9da170dac668888bcf0831373051 (patch)
tree7416f75033dc914e5cbf7ff2a63b857c42eba098 /core/java/com
parent66e99c46546bf34fb8806dbefdbd71df1d41c814 (diff)
DO NOT MERGE Refactoring of fitSystemWindows to applyWindowInsets for views
Applying insets is now handled by: * WindowInsets class - Encapsulate system insets and local decor insets into a single object, written specifically so that new inset categories may be added later. Apps cannot construct their own WindowInsets, only clone with optional modifications. This is to prevent losing data in the event of new insets added in the future. * onApplyWindowInsets - Actually perform the application of insets. * OnApplyWindowInsetsListener - Allow an app to use a separate Listener object to apply insets to a View. This allows for things like support lib integration in custom views written for older versions where the verifier would otherwise complain about the use of the new WindowInsets class as a method parameter. It also allows for applying insets in a custom way without writing a custom view. * dispatchApplyWindowInsets - Dispatch the call to self and children in turn, if applicable. An OnApplyWindowInsetsListener will override the behavior of the view's default onApplyWindowInsets method; a listener wishing to call down to the 'superclass' implementation as part of its own operation should call view.onApplyWindowInsets. App code should generally not override this method and instead override onApplyWindowInsets or provide a listener. Compatibility support with the existing fitSystemWindows method has been provided in both directions: for code that previously called fitSystemWindows on arbitrary views and also for code that overrode the fitSystemWindows method in custom views. A view that supports the newer onApplyWindowInsets mechanism should not mix that behavior with other calls to fitSystemWindows or vice versa. Support lib-style code should take care to consistently use one mechanism or the other at runtime. Change-Id: Ie88b96e0382beb5d3c3f6cd013f7043acbc0a105
Diffstat (limited to 'core/java/com')
-rw-r--r--core/java/com/android/internal/widget/ActionBarOverlayLayout.java20
1 files changed, 11 insertions, 9 deletions
diff --git a/core/java/com/android/internal/widget/ActionBarOverlayLayout.java b/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
index 5469b635b5ae..c957b673ff59 100644
--- a/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
+++ b/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
@@ -20,6 +20,7 @@ import android.graphics.Canvas;
import android.graphics.drawable.Drawable;
import android.os.Build;
import android.view.ViewGroup;
+import android.view.WindowInsets;
import com.android.internal.app.ActionBarImpl;
import android.content.Context;
@@ -96,7 +97,7 @@ public class ActionBarOverlayLayout extends ViewGroup {
if (mLastSystemUiVisibility != 0) {
int newVis = mLastSystemUiVisibility;
onWindowSystemUiVisibilityChanged(newVis);
- requestFitSystemWindows();
+ requestApplyInsets();
}
}
}
@@ -152,7 +153,7 @@ public class ActionBarOverlayLayout extends ViewGroup {
}
if ((diff&SYSTEM_UI_FLAG_LAYOUT_STABLE) != 0) {
if (mActionBar != null) {
- requestFitSystemWindows();
+ requestApplyInsets();
}
}
}
@@ -190,19 +191,20 @@ public class ActionBarOverlayLayout extends ViewGroup {
}
@Override
- protected boolean fitSystemWindows(Rect insets) {
+ public WindowInsets onApplyWindowInsets(WindowInsets insets) {
pullChildren();
final int vis = getWindowSystemUiVisibility();
final boolean stable = (vis & SYSTEM_UI_FLAG_LAYOUT_STABLE) != 0;
+ final Rect systemInsets = insets.getSystemWindowInsets();
// The top and bottom action bars are always within the content area.
- boolean changed = applyInsets(mActionBarTop, insets, true, true, false, true);
+ boolean changed = applyInsets(mActionBarTop, systemInsets, true, true, false, true);
if (mActionBarBottom != null) {
- changed |= applyInsets(mActionBarBottom, insets, true, false, true, true);
+ changed |= applyInsets(mActionBarBottom, systemInsets, true, false, true, true);
}
- mBaseInnerInsets.set(insets);
+ mBaseInnerInsets.set(systemInsets);
computeFitSystemWindows(mBaseInnerInsets, mBaseContentInsets);
if (!mLastBaseContentInsets.equals(mBaseContentInsets)) {
changed = true;
@@ -215,9 +217,9 @@ public class ActionBarOverlayLayout extends ViewGroup {
// We don't do any more at this point. To correctly compute the content/inner
// insets in all cases, we need to know the measured size of the various action
- // bar elements. fitSystemWindows() happens before the measure pass, so we can't
+ // bar elements. onApplyWindowInsets() happens before the measure pass, so we can't
// do that here. Instead we will take this up in onMeasure().
- return true;
+ return WindowInsets.EMPTY;
}
@Override
@@ -321,7 +323,7 @@ public class ActionBarOverlayLayout extends ViewGroup {
// the app's fitSystemWindows(). We do this before measuring the content
// view to keep the same semantics as the normal fitSystemWindows() call.
mLastInnerInsets.set(mInnerInsets);
- super.fitSystemWindows(mInnerInsets);
+ mContent.dispatchApplyWindowInsets(new WindowInsets(mInnerInsets));
}
measureChildWithMargins(mContent, widthMeasureSpec, 0, heightMeasureSpec, 0);