Fixed
Status Update
No update yet.
Comments
lp...@google.com
il...@google.com
There's two independent issues here:
1) onDismiss() for configuration changes is called after onDestroy(). This was already being tracked in the (unfortunately not public)
2) getTargetFragment() incorrectly returns null in onDestroy() since the target Fragment is already destroyed and there's no ordering guarantee around destruction (only around creation).
#1 is what causes getFragmentManager() to fail in onDismiss() - and it fails with both Fragments 1.0.0 and 1.1.0 alphas - this was a change back in Fragments 27.1.0. A workaround for this is to instead use onStop() and check getDialog().isShowing() there - if the dialog is not showing when the Fragment was stopped, then it was dismissed.
#2 is what changed between Fragment 1.0.0 and 1.1.0 and causes getTargetFragment() to return null in both onDestroy() and onDismiss() (since onDismiss() is after onDestroy() due to #1). This is the issue we'll be tackling in this bug - getTargetFragment() should *always* return the Fragment set with setTargetFragment().
1) onDismiss() for configuration changes is called after onDestroy(). This was already being tracked in the (unfortunately not public)
2) getTargetFragment() incorrectly returns null in onDestroy() since the target Fragment is already destroyed and there's no ordering guarantee around destruction (only around creation).
#1 is what causes getFragmentManager() to fail in onDismiss() - and it fails with both Fragments 1.0.0 and 1.1.0 alphas - this was a change back in Fragments 27.1.0. A workaround for this is to instead use onStop() and check getDialog().isShowing() there - if the dialog is not showing when the Fragment was stopped, then it was dismissed.
#2 is what changed between Fragment 1.0.0 and 1.1.0 and causes getTargetFragment() to return null in both onDestroy() and onDismiss() (since onDismiss() is after onDestroy() due to #1). This is the issue we'll be tackling in this bug - getTargetFragment() should *always* return the Fragment set with setTargetFragment().
Description
Version used: 1.1.0-alpha01, 1.1.0-alpha02, 1.1.0-alpha03
Working in: 1.0.0
When a DialogFragment is dismissed by configuration change (i.e rotation), it seems to no longer have access to FragmentManager, and hence its target Fragment.
Attached sample project. To reproduce, rotate the device and it should crash with a null pointer exception as fragment manager is null. Change Fragment dependency to 1.0.0 in build.gradle and then it works fine.