Show DialogFragment from onActivityResult

If you use Android support library, onResume method isn't the right place, where to play with fragments. You should do it in onResumeFragments method, see onResume method description: http://developer.android.com/reference/android/support/v4/app/FragmentActivity.html#onResume%28%29

So the correct code from my point of view should be:

private boolean mShowDialog = false;@Overrideprotected void onActivityResult(int requestCode, int resultCode, Intent data){  super.onActivityResult(requestCode, resultCode, data);  // remember that dialog should be shown  mShowDialog = true;}@Overrideprotected void onResumeFragments() {  super.onResumeFragments();  // play with fragments here  if (mShowDialog) {    mShowDialog = false;    // Show only if is necessary, otherwise FragmentManager will take care    if (getSupportFragmentManager().findFragmentByTag(PROG_DIALOG_TAG) == null) {      new ProgressFragment().show(getSupportFragmentManager(), PROG_DIALOG_TAG);    }  }}

EDIT:Not a bug, but more of a deficiency in the fragments framework. The better answer to this question is the one provided by @Arcao above.

---- Original post ----

Actually it's a known bug with the support package (edit: not actually a bug. see @alex-lockwood's comment). A posted work around in the comments of the bug report is to modify the source of the DialogFragment like so:

public int show(FragmentTransaction transaction, String tag) {    return show(transaction, tag, false);}public int show(FragmentTransaction transaction, String tag, boolean allowStateLoss) {    transaction.add(this, tag);    mRemoved = false;    mBackStackId = allowStateLoss ? transaction.commitAllowingStateLoss() : transaction.commit();    return mBackStackId;}

Note this is a giant hack. The way I actually did it was just make my own dialog fragment that I could register with from the original fragment. When that other dialog fragment did things (like be dismissed), it told any listeners that it was going away. I did it like this:

public static class PlayerPasswordFragment extends DialogFragment{ Player toJoin; EditText passwordEdit; Button okButton; PlayerListFragment playerListFragment = null; public void onCreate(Bundle icicle){   super.onCreate(icicle);   toJoin = Player.unbundle(getArguments());   Log.d(TAG, "Player id in PasswordFragment: " + toJoin.getId()); } public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle icicle){     View v = inflater.inflate(R.layout.player_password, container, false);     passwordEdit = (EditText)v.findViewById(R.id.player_password_edit);     okButton = (Button)v.findViewById(R.id.ok_button);     okButton.setOnClickListener(new View.OnClickListener(){       public void onClick(View v){         passwordEntered();       }     });     getDialog().setTitle(R.string.password_required);     return v; } public void passwordEntered(){   //TODO handle if they didn't type anything in   playerListFragment.joinPlayer(toJoin, passwordEdit.getText().toString());   dismiss(); } public void registerPasswordEnteredListener(PlayerListFragment playerListFragment){   this.playerListFragment = playerListFragment; } public void unregisterPasswordEnteredListener(){   this.playerListFragment = null; }}

So now I have a way to notify the PlayerListFragment when things happen. Note that its very important that you call unregisterPasswordEnteredListener appropriately (in the above case when ever the PlayerListFragment "goes away") otherwise this dialog fragment might try to call functions on the registered listener when that listener doesn't exist any more.

The comment left by @Natix is a quick one-liner that some people may have removed.

The simplest solution to this problem is to call super.onActivityResult() BEFORE running your own code. This works regardless if you're using the support library or not and maintains behavioural consistency in your Activity.

There is:

• No need to add faux delays using threads, handlers or sleeps.
• No need to commit allowing state loss or subclass to override show(). It is NOT a bug, it's a warning. Don't throw away state data. (Another one, bonus example)
• No need to keep track of dialog fragments in your activity (hello memory leaks!)
• And by God, no need to mess around with the activity lifecycle by calling onStart() manually.

The more I read into this the more insane hacks I've seen.

If you're still running into issues, then the one by Alex Lockwood is the one to check.

• No need to write any code for onSaveInstanceState() (Another one)