Adding a Fragment with add() method doesn't hide previous fragments

Question

I'm experiencing "unexpected behaviour" when using add() method to add a new fragment.

I want to add a new fragment on a FrameLayout, but when I do it the previous fragment stills visible.

• Is this the expected result when using add() method?

• It is because I am using a FrameLayout and add() method just place a fragment over the FrameLayout without affect the previous one?

Thx

Solution 1

Not a bug. Try replace(..). instead adding to the back stack if required.

EDIT I think that using replace or remove() add() will solve your problem but as you highlight in your related post there is a bug which manifests itself under your particular set of circumstances.

Solution 2

Other simple thing what you can do is to call

FragmentTransaction t = getFragmentManager.beginTransaction();
t.hide(<your_fragment>);
t.add(<container, <new_fragment>);
..do the rest here..
t.commit();

Let me know if this helps.

Comments

[Axel M. Garcia]

That's what I did, but then I found this problem: stackoverflow.com/questions/6229142/… (the new fragment added with replace() is not removed after a backstack operation)

[PJL]

OK that's weird. Could you post some code. I'm using the compatability library, which has the additional advantage of being able to debug the source and am doing the following to load fragment B from fragment A without problem: 'getActivity().getSupportedFragmentManager().beingTransactio‌​n.replace(R.id.detai‌​ls, fragB).setTransition(FragmentTransaction.TRANSIT_FRAGMENT_OP‌​EN).addToBackStack(n‌​ull).commit();'

[PJL]

Furthermore I'd suggest creating a simple application with the compatibility library to see if that works. If not then debug it to see what's going on. Basically a fragment has an intermediate activity associated with it which should get set to null when it is removed (i.e. by going back). On calling replace(), or add() it is the state of the intermediate activity which determines whether the fragment is seen as added or not.

[Axel M. Garcia]

As it is a different topic I have placed the code here: stackoverflow.com/questions/6250580/… As you can see I already tried with replace. I'm not using the compatibility library but can be a good moment to make the switch. I have a container Activity, do you mean this activity change his state during Fragment transitions? My container Activity is intended to handle a bunch of fragments and I don't want my Activity to be removed or affected by a back button press, although I decide it. Or what intermediate activity are you talking about? Thx

[PJL]

I'd suggest looking at FragmentStack.java for the stack example in API demos to see where it differs compared to your code link as it does exactly what you want, perhaps you shouldn't keep a reference to the fragment manager but use getFragmentManager() each time, I don't know. Regarding the intermediate activity, the underlying Fragment has an activity associated with it, when the fragment is removed it is set to null and is checked when you add it (see compatibility lib sources).

[Axel M. Garcia]

Thx for your interest PJL. I have checked against FragmentStack.java and I don't see anything special. He is just performing an add() at the beginning; replace() in the subsequent actions, and adding the transactions to backStack. Additionally he keeps a counter to display the number of fragments to the user. The only difference I see is that my fragments are not inner static classes of my container Activity... but that shouldn't affect. Anyway I will debug both executions to see what's going on internally on both programs.