I have migrated my application to Android O in Android Studio 3
Running on an Android O emulator all my dialogFragments now fail with :-
java.lang.I
my app work well until upgrade target version to 27 then i face same issue when call setTargetFragment (Fragment fragment, int requestCode)
example:
chooseRegionFragment.setTargetFragment(ParentFragment.this, REQUEST_CODE_CHOOSE_REGION);
just change to:
chooseRegionFragment.setTargetFragment(getRootParentFragment(this), REQUEST_CODE_CHOOSE_REGION);
getRootParentFragment(this)
this method will find root parent of fragments for you
/**
* find root parent of fragment
*/
public static Fragment getRootParentFragment(Fragment fragment) {
Fragment parent = fragment.getParentFragment();
if(parent == null)
return fragment;
else
return getRootParentFragment(parent);
}
For me this was not only an issue on Android O but also on older versions. The oldest version I tested was API Level 16.
I was instantiating my fragments using this code:
MyFragment myFragment = MyFragment.newInstance();
myFragment.setTargetFragment(ParentFragment.this, 0);
myFragment.show(getActivity().getSupportFragmentManager(), null);
Where ParentFragment.this
is a custom class extending android.support.v4.app.Fragment
, MyFragment
also extends this class and is a child fragment of the ParentFragment
fragment (hence it's name).
I thought that I had to use a SupportFragmentManager (the getSupportFragmentManager()
method) because I am using a fragment of the support package so I tried to call getActivity().getSupportFragmentManager()
to get an activity reference that supported this method.
This does not seem to be the correct way though. I changed those calls to:
MyFragment myFragment = MyFragment.newInstance();
myFragment.setTargetFragment(ParentFragment.this, 0);
myFragment.show(getFragmentManager(), null);
so the fragment decides on it's own which FragmentManager to use and the error is gone now.
Hope this helps someone.
while working on an app, I encountered the same problem and I solved it by (in kotlin)
chooseRegionFragment.setTargetFragment(this@ParentFragment, REQUEST_CODE_CHOOSE_REGION)
chooseRegionFragment.show(this@ParentFragment.parentFragmentManager, TAG)
it translates to
chooseRegionFragment.setTargetFragment(ParentFragment.this, REQUEST_CODE_CHOOSE_REGION);
chooseRegionFragment.show(ParentFragment.this.getParentFragmentManager, TAG);
in java
Recently, my app experienced the same issue when I targeted it for Android O. As a solution, use:
myDialogFragment.show(SettingsFragment.this.getFragmentManager(), TAG);
instead of:
myDialogFragment.show(getFragmentManager(), TAG);
// or
myDialogFragment.show(getSupportFragmentManager(), TAG);
// or
myDialogFragment.show(getChildFragmentManager(), TAG);
I just faced the same issues in the project that I am currently working on when we moved to Android Studio 3 and upgraded the support library to version 26. All of a sudden, without changing the code, we got tons of this exception. In the end I found out the following:
Google added a new "sanity check" in the sources of the v4 Fragment Manager in January this year (not sure into what release that went) that refuses to add a fragment using a Fragment Manager, if it has a target fragment set and the target fragment cannot be found in the active fragments of the same Fragment Manager. The patch is described in detail here
Ealier versions seem to not have cared about that. Took me a few days to update all the areas in our code where fragments that were added using the Support Fragment Manager used the Child Fragment Manager for their subfragments with the parent fragment as target. Well, late penalty for writing bad code.
I had the same case as Markus Ressel but I was using getChildFragmentManager(). I replaced that with getFragmentManager() and it resolved the issue.
UPDATE: I've now been working with childFragmentManager and have some feedback.
When dealing with inner fragments that are hosted by a fragment (so a fragment within a fragment) use the childFragmentManager. This fragment manager differs from the activities getSupportFragmentManager. The two are not the same. It's a separation of concerns.
So I've made a rule that fragments hosting child fragments will always use the childFragmentManager and things not inside host fragments can use getSupportfragmentManager.