Obsolete
Status Update
Comments
ra...@google.com <ra...@google.com> #2
I see same issue and have been debugging it.
NOTE: It DOES NOT happen if not using support package, but use android level 14/15 library. I believe Honeycomb works well too.
My current workaround is to provide my own DialogFragment.show() method, like below:
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: It DOES NOT happen if not using support package, but use android level 14/15 library. I believe Honeycomb works well too.
My current workaround is to provide my own DialogFragment.show() method, like below:
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;
}
ia...@gmail.com <ia...@gmail.com> #3
[Comment deleted]
ra...@google.com <ra...@google.com> #4
But Google pls fix this issue, as the expected behaviors must be consistent with ICS DialogFragment + FragmentManager and support package DialogFragment + FragmentManager.
It happens with both Support Package v4 r6 and v13 r6.
It happens with both Support Package v4 r6 and v13 r6.
ia...@gmail.com <ia...@gmail.com> #5
I have this problem too.
As a workaround I use a boolean in the onActivityResult to mark the desired dialog and show the dialog in the onResume.
As a workaround I use a boolean in the onActivityResult to mark the desired dialog and show the dialog in the onResume.
ia...@gmail.com <ia...@gmail.com> #7
This is definitely not a bug. There are times when onActivityResult() can be called before the Activity has restored its saved state... committing fragment transactions in these situations will simply not be remembered as a result (see this blog post: http://www.androiddesignpatterns.com/2013/08/fragment-transaction-commit-state-loss.html ).
Try moving your commits into "onPostResume()" instead as described here:http://stackoverflow.com/questions/16265733/failure-delivering-result-onactivityforresult/18345899#18345899
Try moving your commits into "onPostResume()" instead as described here:
ra...@google.com <ra...@google.com> #8
Adding a "super.onActivityResult(requestCode, resultCode, data)" call at the beginning of the method seems to fix the problem. I'm surprised than almost nobody came up with such a simple solution.
ia...@gmail.com <ia...@gmail.com> #9
Dear alockw...@google.com,
Let's say we have an application where we need to select a picture from gallery, and then when we come back to onActivityResult(), we need to show a DialogFragment asking the user if he really wants to send the file.
How do you propose we can implement this with the current API?
Thank you,
Sabin
Let's say we have an application where we need to select a picture from gallery, and then when we come back to onActivityResult(), we need to show a DialogFragment asking the user if he really wants to send the file.
How do you propose we can implement this with the current API?
Thank you,
Sabin
ra...@google.com <ra...@google.com> #10
Please also consider how to deal with "Avoid performing transactions inside asynchronous callback methods." problem which is stated in http://www.androiddesignpatterns.com/2013/08/fragment-transaction-commit-state-loss.html#more
dismissAllowingStateLoss() is the least resort for dismiss() dialog in onPostExecute(), but there is no solution for DialogFragment#show() in onPreExecute() callback.
dismissAllowingStateLoss() is the least resort for dismiss() dialog in onPostExecute(), but there is no solution for DialogFragment#show() in onPreExecute() callback.
Description
on one UI Motorola device