As the title suggest, is it a good idea to perform FragmentTransaction inside a fragment?
The way I view this is that, FragmentTransaction requires a containerView id and the Fragment to inflate when calling FragmentTransaction.replace(). The containerView where to get the ID usually resides in the activity layout. So it seems like a good idea to do FragmentTransaction inside the activity rather than in the Fragment.
But I got confused when using SharedElementTransition for fragments. Now it requires a list of Views which will be the sharedElements. These views reside in the Fragment. Now it seems logical to do the FragmentTransaction inside the Fragment itself.
Can anyone guide me on how to compensate for both scenarios?
There's nothing wrong on doing FragmentTransaction inside a fragment as long as it is not redundant, like for example:
"Container" Fragment
"Child Fragment" that holds view pager
View pager has fragments
Here, you can remove the child fragment and hold the view pager on container fragment instead.
For FragmentTransaction inside a fragment, you can actually swap the fragment itself by calling getActivity().getSupportFragmentManager(). Here, transaction is happening on Activity not on the fragment. But if you intended to use FragmentTransaction to swap the child of the parent fragment, you can use getChildFragmentManager() on the fragment.
Also, child fragments is actually supported by android.
Related
I have a parent fragment containing TabLayout and ViewPager.
The TabLayout has 3 tabs (fragments) managed by FragmentStatePagerAdapter.
After the user clicks on a button on the 3 fragment, I would like to replace it with different fragment, without reloading the parent fragment.
I tried to remove the fragment and add the new one and call notifyDataSetChanged() and the fragment is indeed replaced, but the TabLayout custom view headers are gone...
Any idea how can I do it right?
Thanks.
You can have the 3rd Fragment working as a holder for two child Fragments which you can switch based on your app's logic (clicking the button you mention).
The key for this alternative is that the 3rd Fragment in the ViewPager will be the parent of the two Fragments that will be switching.
The two child Fragments will communicate with the parent Fragment for the parent to take care of doing the switching.
For the switching the parent will use a ChildFragmentManager instead of the FragmentManager used for Fragments that are managed by Activities.
I have a FrameLayout container in which I use the replace method to put a fragment when an item is selected from the navigation drawer.
getSupportFragmentManager().beginTransaction().replace(R.id.container, fragment, fragment.getFragmentTag()).commit();
I have a fragment which has a ViewPager within it. I have 3 fragments which are displayed in a tab layout with the ViewPager. When I select another item from the navigation drawer the fragment with the ViewPager is replaced but the fragments within are not detached. The system calls only the fragment with the ViewPager onDetach/onDestroy etc. methods but not the methods of the fragments it contains.
I am using FragmentPagerAdapter and I tried with the FragmentStatePager adapter. Nothing changes. I am using the default setOffscreenPageLimit(1);
How can I get my ViewPager fragments methods onDetach/onDestroy called?
Thanks!
Are you using the FragmentManager or the child Fragment Manager? If you create a Fragment inside another Fragment and you want the inner Fragment to behave like the outer, you should get the child fragment manager from the outer fragment and use it to create the inner fragments. See this.
I have a Fragment which contains a ListView say FragmentA, when I add another Fragment which contains another ListView say FragmentB:
getFragmentManager().beginTransaction()
.add(R.id.fragment_container, FragmentB)
.commit()
I noticed that getView() of ListView in FragmentA is still getting called even though the top fragment is now FragmentB, any reason why and how do I prevent this behavior?
You're stacking fragments on top of each other.
Instead of add use replace to replace any existing fragments in that container.
I have a FragmentActivity that contains a FrameLayout. I use the following code to add Fragments to the Fragment Activity.
FragmentManager fm = getSupportFragmentManager();
FragmentTransaction ft = fm.beginTransaction();
ft.add(R.id.fragment_content, fragment, fargmentTag);
ft.addToBackStack(null);
ft.commit();
Now R.id.fragment_content is FrameLayout. This adds a Fragment onto the view. But the underlying view still remains visible. Meaning the one lying view is seen through the new fragment ? What am i doing wrong.
Kind Regards
for the next fragment use ft.replace(); so the previous one will be repalced.
Either ft.remove() the old fragment, or use ft.replace() instead of ft.add().
ft.replace() should work fine, otherwise you have to update your question for a better understanding.
Using ft.replace will replace any previously added fragment with this fragment but if the activity has some view added to its layout rather than a fragment ,then the fragment added through add or replace will show its content over it rather than replacing it as it is not a fragment.
either add another layout within your main layout and assign it some id and then add the fragment to that container.
Hope it helps.
I am learning fragments but I am failing to understand the significance behind why fragments requires a Container.
The way I understand Fragments work is as follows :
FragmentActivity setContentview refers to a xml file which
defines where fragments would be located.
FragmentActivity creates instance of the fragments
Then assigns fragment to container.
FragmentManager then displays them.
The actual Fragment class then inflates a layout, and it is this layout which
contains all of the applications UI components.
(please correct me if I miss something here because I am only learning at the moment).
So why is the purpose of the Container why do we even need since in all the examples I have seen it is just a blank relative layout xml document.
Can different fragments share the same Container (since its just a RelativeLayout xml file)?
So in the example provided by google http://developer.android.com/training/basics/fragments/creating.html
They have a ListFragment and when item is selected through the use of the CallBack interface we eventually get back to this line of code :
// Replace whatever is in the fragment_container view with this fragment,
// and add the transaction to the back stack so the user can navigate back
transaction.replace(R.id.fragment_container, newFragment);
My other question is:
1) Why does this line of code not replace the ListFragment (left side Fragment) with the article fragment. Since when it was initialised we see:
getSupportFragmentManager().beginTransaction()
.add(R.id.fragment_container, firstFragment).commit();
Instead ... the ListFragment remains on the left and the right Fragment is updated.
But the container fragment_container belongs to firstFragment this is the ListFragment.
And this is not the one that gets updated.
Do you see why I have the question ? This is not explained in the tutorial.
Here: http://marakana.com/s/post/1250/android_fragments_tutorial
And here: http://developer.android.com/guide/components/fragments.html
Read this and all will be clear:)
Fragment is a portion of Activity and can exist only inside an Activity. So you need a special type of activity that can handle fragment - it's FragmentActivity.
FragmentActivity without Fragments is almost like a normal Activity. But it has a FragmentManager to manage (add,remove,replace) fragments. When you want to add a Fragment to a FragmetnActivity you should specify where it should be placed (because fragment does not need to be fullscreen, just like GooglePlay-there are multiple small fragments). So this is why you need a container.
Can different fragments share the same Container (since its just a RelativeLayout xml file)?
Yes they can, you can replace one fragment with another within the same container.