List of usage examples for android.view Window setCallback
public void setCallback(Callback callback)
From source file:android.support.v7.app.ActionBarActivityDelegateICS.java
@Override public void onCreate(Bundle savedInstanceState) { // Set framework uiOptions from the support metadata value if (UIOPTION_SPLIT_ACTION_BAR_WHEN_NARROW.equals(getUiOptionsFromMetadata())) { mActivity.getWindow().setUiOptions(ActivityInfo.UIOPTION_SPLIT_ACTION_BAR_WHEN_NARROW, ActivityInfo.UIOPTION_SPLIT_ACTION_BAR_WHEN_NARROW); }//from w w w .j av a2 s .c om super.onCreate(savedInstanceState); if (mHasActionBar) { // If action bar is requested by inheriting from the appcompat theme, // the system will not know about that. So explicitly request for an action bar. mActivity.requestWindowFeature(WindowCompat.FEATURE_ACTION_BAR); } if (mOverlayActionBar) { mActivity.requestWindowFeature(WindowCompat.FEATURE_ACTION_BAR_OVERLAY); } /* * This goofy move needs some explanation. * * The verifier on older platform versions has some interesting side effects if * a class defines a method that takes a parameter of a type that doesn't exist. * In this case, that type is android.view.ActionMode. Therefore, ActionBarActivity * cannot override the onActionModeStarted/Finished methods without causing nastiness * when it is loaded on older platform versions. * * Since these methods are actually part of the window callback and not intrinsic to * Activity itself, we can install a little shim with the window instead that knows * about the ActionMode class. Note that this means that any new methods added to * Window.Callback in the future won't get proxied without updating the support lib, * but we shouldn't be adding new methods to public interfaces that way anyway...right? ;) */ final Window w = mActivity.getWindow(); w.setCallback(createWindowCallbackWrapper(w.getCallback())); }