IssueTracker

An obsolete DISMISS message for the fragment is retained in the message queue. It's been queued by DialogFragment.onDestroyView() when dismissing the old dialog and gets reactivated after creating the new dialog.

A quick (and possibly dirty) workaround is to override onDestroyView() and clear the dismiss listener before calling super.onDestroyView():

@Override
public void onDestroyView() {
  if (getDialog() != null && getRetainInstance())
    getDialog().setOnDismissListener(null);
  super.onDestroyView();
}

The work around above will cause crash on Android OS 3.1.

It's working fine on Android 3.1 and 3.2 (emulator).
Try my sample project.

On my Xoom running 3.2, I get a pretty explicit exception:

java.lang.IllegalStateException: OnDismissListener is already taken by DialogFragment and can not be replaced.

If we go around to the back door and call getDialog().setDismissMessage(null) instead, though - no problems, and the workaround appears to work.

This solution worked in Galaxy tab 10 having Android 3.1.

[Comment deleted]

[Comment deleted]

[Comment deleted]

Why don't you submit a patch to gerrit so that the next version works
properly...

[Comment deleted]

It looks like I'm about to encounter this in my app.  The option I'm planning to choose is to fork the Compat API and apply the fix to the issue per Robert.  I'll take the forked copy of the Compat API on Github (which I used successfully for Maps support) and fork again with the proper fix.  If this is the only code-fix you make then there would be absolutely no refactoring when switching to an official release with the proper fix.  One side-effect of adopting this approach is you may have to wait for that official release, and have to face choices if an interim release has something else you want.  As long as the patches you're looking to consume are small-sized then those choices will likely be very reasonable, albeit annoying.  The only other burden with this approach is to comply with the Apache 2 license for the Compat API source.  Essentially this approach de-couples the solution from the OS/platform but takes on additional work to maintain a fork.

[Comment deleted]

This seems to apply to OS 3.2.1 without the compatibility library as well. Using the setDismissMessage hack worked for me. Sad face.

I'm able to repro this in 4.0.3 without the compatibility library as well. setOnDismissListener caused an error, but using setDismissMessage instead did the trick.

Making the dialog fragment non-retained was the workaround for me on Android 4.0.4.

[Comment deleted]

If the above workaround didn't work, try getDialog().setDismissMessage(null); instead.

From:
http://stackoverflow.com/questions/8235080/fragments-dialogfragment-and-screen-rotation

Although it is reported for compatibility package I have seen this in a core app also.

[Comment deleted]

the comment #2 (https://code.google.com/p/android/issues/detail?id=17423#c2) with the variation "setDismissMessage" did the trick for me. (supprt.v4, actionBarSherlock, target 17, running on android 4.4.2)

(In my onDismiss, I navigate back, ie: remove the targetFragment of the dialog from the UI)

BUT

if I rotate the screen 1x before dismissing the dialogFragment, a "glitch" is visible on my previous fragment just after the dismiss when it re-do the layout. it seem it do the layout a few time with different height.

this may be related to actionBarSherlock, as the difference seem to be the same as the actionbar height.

I can confirm that is NOT a compatibility library problem. I'm developing an app for API 19 and I can see this kind of problem with DialogFragment. The problem is present since 2011, do you know it's possible to have a fix (we are at the end of 2014!!!)?

has anyone has successfully created some workaround here ? or some fix ? thanks.

There is a workaround for this bug:

    @Override
    public void onDestroyView() {
        if(getDialog() != null && getRetainInstance()) {
            getDialog().setDismissMessage(null);
        }
        super.onDestroyView();
    }

@nicolasj yr code is working only one time, rotating device 3 or more times dialog is dismissing! Any ideas?

[Comment deleted]

android:configChanges="orientation|screenSize" in Manifest is solved! Hoooooraaayyyyy!!! :)

My use case is subtly different but almost certainly the same issue.

STEPS TO REPRODCE
1) Use the compatibility library.
2) Create a Fragment and call setRetainInstance(true) in onCreate(...).
3) Create a DialogFragment
4) Invoke the dialog using show(getChildFragmentManager(), tag) from within the Fragment in (2).
5) Change orientation.

Note that if you invoke the dialog using show(getFragmentManager(), tag) instead then rotation works OK. But you become more susceptible to IllegalStateException: Can not perform this action after onSaveInstanceState when showing the dialog.

Just a follow up (because it probably isn't clear from my previous post), the work around using:
  getDialog().setDismissMessage(null);

while fantastic, doesn't work for my use case because it is not the dialog that is being retained it is the root Fragment. Trying to set the dialog to also be retained throws:
IllegalStateException: Can't retain fragements that are nested in other fragments

I find this bug, DialogFragment dismissed on orientation change when setRetainInstance(true),  even when not using the compatibility library (as #21 pratimj...@gmail.com and #24 playappa...@gmail.com report).

That is, with my "Target SDK Version" set to "Api 21: Android 5.0 (Lollipop)"; using android.app.DialogFragment; and testing against the emulator.

For me the issue is fixed by #2 robert.r...@gmail.com's onDestroyView workaround.

android:configChanges="orientation|screenSize" is a good suggestion from  #29 akhmedov...@gmail.com. However, it appears to be a dangerous bandaid, in that it doesn't handle all configuration changes, as explained in the approved answer at http://stackoverflow.com/questions/7818717/why-not-use-always-androidconfigchanges-keyboardhiddenorientation

I wish to withdraw my previous claim that the DialogFragment is dismissed on orientation changes when using setRetainInstance(true), even when not using the compatibility library.

When *not* using the support library, that is when using android.app.DialogFragment, I've found a straightforward technique to prevent the dialog from being dismissed on screen orientation changes (and presumably other runtime configuration changes) and retain the state of the selected data (in my case selections of a checkboxed multi choice list in the content area of an AlertDialog).

The technique is simply to maintain an activity level variable of the DialogFragment. When doing so none of the following techniques are necessary (as tested against an emulator running Api 21: Android 5.0 (Lollipop)):

*  #2 robert.r...@gmail.com's  onDestroyView() workaround;
* setRetainInstance(true),
* Using default empty constructors for the fragment(s) (although I include them in my code because the official recommendation is to include them anyway).
* Using onSaveInstanceState() and a corresponding restore of a Bundle.
* Callbacks from the fragment to the activity, to explicitly save bespoke fragment data with the activity.

With this technique, an activity level variable of the fragment, runtime changes and state saving of the DialogFragment survive not only screen orientation changes but screen orientation changes in combination with:
* Going backwards and forwards through the back stack;
* Leaving the application completely and reentering;
* Even force closing all apps and restarting the example app (tested on a real device running 4.4.2).

So an example of this technique is ....

Note there are three main objects.
* DialogDemoActivity (which chiefly functions to house PlaceholderFragment; and maintain the variable to MyAlertDialogListFragment );
* PlaceholderFragment (the default fragment generated in Android Studio when using the wizard Right Click > New > Activity > Blank Activity With Fragment; This PlaceholderFragment essentially holds a button from which to launch MyAlertDialogListFragment); and
* MyAlertDialogListFragment (the example DialogFragment whose state we wish to maintain through screen orientation changes; this is the Fragment which needs to have an instance variable maintained at the Activity level).

// DialogDemoActivity.Java
public class DialogDemoActivity extends Activity {

    // Automatically generated by the Android Studio wizard.
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_dialog_demo);
        if (savedInstanceState == null) {
            getFragmentManager().beginTransaction().add(R.id.container,
                                                        new PlaceholderFragment())
                    .commit();
        }
    }
    ...

    // An activity level variable in order to keep the AlertDialogList alive between runtime
    // configuration changes (like rotating the screen), and also save state.
    static private MyAlertDialogListFragment mFireMissileDialogFragment;

    /**
     * A placeholder fragment containing a simple view.
     */
    public static class PlaceholderFragment extends Fragment implements View
            .OnClickListener {

        // "Every fragment must have an empty constructor, so it can be instantiated
        // when restoring its activity's state." http://developer.android
        // .com/reference/android/app/Fragment.html
        public PlaceholderFragment() {
        }

        // Called from code that handles button clicks
        public void createAndShowFireMissileDialogFragment() {
            // Only create if it doesn't already exist.
            if (mFireMissileDialogFragment == null) {
                mFireMissileDialogFragment = new MyAlertDialogListFragment();
            }

            // Android 3.0 (API 11) >= import android.app.Fragment
            // .getFragmentManager();
            // Android 3.0 (API 11) < import android.support.v4.app
            // .DialogFragment.getSupportFragmentManager()
            mFireMissileDialogFragment.show(getFragmentManager(), "FireMissilesTag");      
        }
...

// MyAlertDialogListFragment.Java
public class MyAlertDialogListFragment extends DialogFragment {

    final String[] mItems = {"ICBM", "Hellfire", "Propaganda"};
    private boolean[] mItemsCheckedStatus;

    // "Every fragment must have an empty constructor, so it can be instantiated
    // when restoring its activity's state." http://developer.android
    // .com/reference/android/app/Fragment.html
    public MyAlertDialogListFragment() {
    }
...

I'm not clear what's going on to make this technique work. Having an activity level variable of the fragment suggests that the fragment is kept alive in memory in virtue of the activity being kept alive in memory (and that state would be lost if the activity level variable goes out of memory).

However, runtime configuration changes are meant to *destroy* activities (and, as I understand it, remove the activity and dependent objects from memory). As explained at http://developer.android.com/guide/topics/resources/runtime-changes.html
"Some device configurations can change during runtime (such as screen orientation, keyboard availability, and language). When such a change occurs, Android restarts the running Activity (onDestroy() is called, followed by onCreate()).'

Indeed, as I mentioned, state is saved (the particular items selected on my Alert Dialog List are maintained) even through force closing all applications. So issues of how to make sense if it aside, the technique seems sufficiently robust.

I have *not* tested the technique when using the support library, which the original bug report is about. I'm posting this chiefly therefore to restore focus of this bug to its original scope: the support library. But this might also assist with others who want to create dialogs without the support library.

But most relevantly, others might be interested in testing this technique against the support library, after getting it working for the native library.

A correction to my immediately prior post (#33).

For Multichoice alert dialogs I find that *I do* have to use onSaveInstanceState() and a corresponding restore of a Bundle, to save state during runtime configuration changes (like screen rotation), in addition to the Activity level variable of the DialogFragment.

For example

/**
 * An Alert List Dialog
 */
public class FireMissilesAlertListDialogFragment extends DialogFragment {
    public String[] mItems = {"ICBM", "Hellfire", "Propaganda"};
    private boolean[] mItemsCheckedStatus;

    // "Every fragment must have an empty constructor, so it can be instantiated
    // when restoring its activity's state." http://developer.android
    // .com/reference/android/app/Fragment.html
    public FireMissilesAlertListDialogFragment() {
    }

    @Override  
    public Dialog onCreateDialog(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        AlertDialog.Builder builder = new AlertDialog.Builder(getActivity());
        // You must set the title.
        builder.setTitle("Fire Missiles Dialog");
        // Don't set a message.

        // Initialize
        if (mItemsCheckedStatus == null) {
            mItemsCheckedStatus = new boolean[mItems.length];
            for (int i = 0; i < mItems.length; i++) {
                mItemsCheckedStatus[0] = false;
            }
        }

        if (savedInstanceState != null) {
            mItemsCheckedStatus = savedInstanceState.getBooleanArray
                    ("mItemsCheckedStatus");
        }


...
    }

    /**
     * We need to save our class level variables to the outState bundle
     * so that they may be retrieved when the user:
     * 1. Selects some new values.
     * 2. Rotates the screen.
     * 3. And clicks the positive button without otherwise touching the dialog.
     */
    @Override
    public void onSaveInstanceState(Bundle outState) {
        outState.putBooleanArray("mItemsCheckedStatus", mItemsCheckedStatus);
        super.onSaveInstanceState(outState);
    }
}

However, if you are creating a custom alert dialog box (for example something like the Sign in Dialog box, using XML layout, as detailed at http://developer.android.com/guide/topics/ui/dialogs.html#CustomLayout) you don't need explicit state saving. That is, if your layout components have ids and thereby state saving of the components is preserved, for free, by the system.

For example, enter some values in user name and password, rotate the screen, click your positive button to retrieve the user name and password: everything is OK without explicitly having to save state.

I'm still able to reproduce this issue and the workaround is not working for me.

I'm still able to reproduce this issue with Android 6.0 on a Moto G and the compatibility library at 24.2.0. The workaround here worked for me - http://stackoverflow.com/a/15444485/1055475

In Support Library v25.0.0 none of the aforementioned workarounds are working.

P.S. Seems like it's really hard to resolve such a rocket science issue. Android team are struggling with it since 2011. Good luck, guys.  I've added a reminder to check the state of this thread in 2025.

Any update on this ticket? open since the last 6 years!

Will there be a fix for this or can we assume this bug is here to stay?

I ran into this issue without using setRetainInstance(true) by detaching and re-attaching the parent fragment. Tested in 26.0.0-beta2

        getFragmentManager()
                .beginTransaction()
                .detach(parentFragment)
                .attach(parentFragment)
                .commit();

https://github.com/evant/dialog-fragment-issue

Any update on this?

Would be nice to be able to remove hacky workarounds for this in Books.

You guys seriously haven't fixed this simple, glaring issue after 6 years?

When will this be fixed? Unbelievable, seriously..

I got a very similar issue when using a specific version of android-x components:
https://issuetracker.google.com/issues/120461547

I got a rather strange bug with this:

If I don't add these words, dialogfragment which i made would not be shown in some situation.

Hope to fix it.

Thank you for the feedback. We're closing this issue as Obsolete.
If it is still observed in the latest Android release, please open a new issue in https://goo.gl/TbMiIO along with a reference to this issue.