Related
Since support version 25.1.0 and the most recent 25.1.1 I got strange behaviour with fragment replacing/adding.
There have been issues reported for 25.1.0 Android - fragmentTransaction.replace() not works on support library 25.1.0
But now in 25.1.1 i got similar issues. To reproduce the behaviour i created sample app which you can find at https://github.com/holoduke/fragmenttest
It is basically one Activity with a fragment container. A couple of fragments are available which will be dynamically replace each other by pressing a button. We start with adding FragmentA from the mainActivity itself.
FragmentManager fm = getSupportFragmentManager();
FragmentTransaction ft = fm.beginTransaction();
Fragment f = new FragmentA();
fm.popBackStackImmediate(null, FragmentManager.POP_BACK_STACK_INCLUSIVE);
f.setRetainInstance(false);
ft.replace(R.id.fragmenttarget, f);
ft.addToBackStack(null);
ft.commit();
All good Works fine. in both 25.0.1, 25.1.0 and 25.1.1
Now in fragmentA there are 3 buttons which will all replace the current fragment with either fragmentA, fragmentB or fragmentC
the code for adding fragment B and C is almost the same as fragment A except we have not defined:
fm.popBackStackImmediate(null, FragmentManager.POP_BACK_STACK_INCLUSIVE);
when fragment B or C is added the following code is executed:
FragmentManager fm = getSupportFragmentManager();
FragmentTransaction ft = fm.beginTransaction();
Fragment f = new FragmentB();
f.setRetainInstance(false);
ft.replace(R.id.fragmenttarget, f);
ft.addToBackStack(null);
ft.commit();
Still all good in both 25.0.1, 25.1.0 and 25.1.1.
If you add fragmentB and C a couple of times the fm.getBackStackEntryCount() is increasing. Thats good.
Now the weird part.
We want to add FragmentA with popStackImmediate (to clear history)
Here the behaviour of both 3 support versions are going mad.
Lets say that you execute the following bavhiour in all 3 versions:
start app
replace with fragment B
replace with fragment C
replace with fragment B
replace with fragment C
replace with fragment A
in 25.0.1 everything works out fine. the backstack is cleared and onCreateView and ActivityCreated is called in FragmentA.
in 25.1.0 somehow after replacing with FragmentA the onCreateView and ActivityCreated are called 2 times. Not good.
in 25.1.1 its even worse. after replacing with fragmentA, for all views in the backstack the onCreateView and ActivityCreated are called. Now Thats funny right :)
Just try out my sample app and look in the logcat. change the support version in app.gradle file to see the differences.
I would be glad if someone is able recognise this issue as well, so we can find a way to overcome or even solve this issue.
Well, I faced with the same problem and found a solution by comparing 25.0.1 -> 25.1.1 FragmentManager.class. Try to use setAllowOptimization method of FragmentTransaction.
I lost some hours today because my code was not working any more.
The code to reload the view of a fragment was not working anymore after updating to the new version of Support Library 25.1.0:
This is my code :
FragmentManager manager = getActivity().getSupportFragmentManager();
FragmentTransaction fragmentTransaction = manager.beginTransaction();
fragmentTransaction.detach(fragment);
fragmentTransaction.attach(fragment);
fragmentTransaction.commit();
I have tried to debug putting some breakpoints on
public void onPause()
public void onStop()
public void onAttach(Context context)
public void onDetach()
public void onDestroyView()
public void onDestroy()
but the application is not entering into any of that function and nothing happened on the screen.
If I call detach alone, without attach, the application enter in onPause and onStop and the view leave the screen.
Faced a similar issue after updating androidx.navigation from 2.3.1 to 2.3.2.
parentFragmentManager.beginTransaction().detach(this).attach(this).commit()
has stopped reload the view of a fragment.
Everything that I found here did not help, but I noticed that separately the detach and attach operations are being performed successfully, I decided to spread their execution to different FragmentTransaction entities:
parentFragmentManager.beginTransaction().detach(this).commit ()
parentFragmentManager.beginTransaction().attach(this).commit ()
and it worked.
Hope this saves someone some time.
I've found myself facing the same issue, and found no answer online. Finally I've found out that some optimizations were added to Fragment Transactions in Revision 25.1.1 of the Support Library. (see https://developer.android.com/topic/libraries/support-library/revisions.html#25-1-1). Disabling those for your transaction will make it work as expected:
FragmentTransaction transaction = getSupportFragmentManager().beginTransaction();
transaction.setAllowOptimization(false);
transaction.detach(fragment).attach(fragment).commitAllowingStateLoss();
Update
setAllowOptimization is deprecated. Use setReorderingAllowed instead.
#Viad actually answered the question. To add a little bit to it, this happens in android versions 26 and above where reordering is allowed by default. Reordering comes into play when two fragment operations are requested at the same done, for example adding fragment 1 and then replacing it with fragment 2, which causes only the latter (replacing fragment 2) to happen.
So when reordering is allowed by default, when restarting the fragment using detach(fragment).attach(fragment) the first one is ignored and only second one is executed. As the fragment is already attached, attach(fragment) does not do anything. This is why none of the lifecycle methods of the fragment is called.
The resolution to the problem would be to setReorderingAllowed(false) to deactivate reordering. So the solution would be:
FragmentTransaction transaction = mActivity.getFragmentManager()
.beginTransaction();
if (Build.VERSION.SDK_INT >= 26) {
transaction.setReorderingAllowed(false);
}
transaction.detach(fragment).attach
(fragment).commit();
Here is a slight modification I made to use getSupportFragmentManager:
FragmentTransaction t = getActivity().getSupportFragmentManager().beginTransaction();
t.setAllowOptimization(false);
t.detach(this).attach(this).commitAllowingStateLoss();
To achieve the fragment's refresh with Androidx is a bit different.
As per Android Developers documentation here
As a FragmentTransaction is treated as a single atomic set of
operations, calls to both detach and attach on the same fragment
instance in the same transaction effectively cancel each other out,
thus avoiding the destruction and immediate recreation of the
fragment's UI. Use separate transactions, separated by
executePendingOperations() if using commit(), if you want to detach
and then immediately re-attach a fragment.
Therefore the code must be like this :
fun FragmentActivity.relaunchFragment(fragmentId: Int) {
val currentFragment = supportFragmentManager.findFragmentById(fragmentId)
val detachTransaction = supportFragmentManager.beginTransaction()
val attachTransaction = supportFragmentManager.beginTransaction()
currentFragment?.let {
detachTransaction.detach(it)
attachTransaction.attach(it)
detachTransaction.commit()
attachTransaction.commit()
}
}
I've been working for several months in an app. The version uploaded to the playstore works fine. Recently, doing some improvements, the whole app has started to work in a very strange way.
If you swith between fragments, after a while it does not inflate properly the fragments, putting always the content of the first one. So, if you switch the fragment, the action bar changes but the content is always the same (and you cannot interact with it).
Here is a quick video of the error https://streamable.com/9exa
I am going crazy as there is no log or trace whatsoever.
I am using the usual way of swithing fragments and the most intriguing part is that at the beginning everything works ok:
Fragment fragment = getSelectedFragment(index); // returns the desired fragment
FragmentManager fragmentManager = getFragmentManager();
//Pop backstack
for(int i = 0; i < fragmentManager.getBackStackEntryCount(); ++i) {
fragmentManager.popBackStack();
}
fragmentManager.beginTransaction()
.replace(R.id.container, fragment)
.addToBackStack(null)
.commit();
Do anyone has any kind of idea what could be happening here? Thanks!
edit: I also have tried to clear the backstack in case it was the problem, but it doesn't change anything
solved: As I explain in my answer, I have discovered that is a problem related to a SwipeRefreshLayout. More information about this problem can be found at When switch fragment with SwipeRefreshLayout during refreshing, fragment freezes but actually still work
Ok, I found out the problem.
It seems that a SwipeRefreshLayout was the one causing all the problems. One of my fragments was using it, and after switching fragments a couple of times it gets stuck.
Removing it, or disabling it setEnabled(false) solves all the problems.
I hope it will help to anyone that is having the same problem!
Another thread in SO that refers to the same problem: When switch fragment with SwipeRefreshLayout during refreshing, fragment freezes but actually still work
What fragments are you using?
I had some strange behaviour using framework fragments, and i switched to V4 and everything worked fine
Please check this link: FragmentManager popBackStack doesn't remove fragment
I am using the following code in my activity for switching between fragments and it is working fine. My app's minSdkVersion is 15.
private void setFragment(Fragment fragment) {
FragmentManager fragmentManager = getSupportFragmentManager();
FragmentTransaction fragmentTransaction =
fragmentManager.beginTransaction();
fragmentTransaction.replace(R.id.container, fragment);
fragmentTransaction.commit();
}
I am facing a problem of overlapping fragments when i switch between tabs and attach fragments to a tab view
below is my code please help
public class FragmentManage extends Fragment implements ActionBar.TabListener {
private Fragment mFragment;
#Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
View v = inflater.inflate(R.layout.fragment_manage, container, false);
OnClickListener clickListener = new OnClickListener() {
public void onClick(View v) {
FragmentTransaction ft = getFragmentManager().beginTransaction();
switch(v.getId()) {
case R.id.imageBtnCategory:
if (mFragment == null){
mFragment = new FragmentCategory();
}
ft.replace(android.R.id.content, mFragment);
break;
case R.id.imageBtnManageKey:
if (mFragment == null){
mFragment = new FragmentKeys();
}
ft.replace(android.R.id.content, mFragment);
break;
case R.id.imageBtnChangePswd:
if (mFragment == null){
mFragment = new FragmentChangePwd();
}
ft.replace(android.R.id.content, mFragment);
break;
}
ft.commit();
}
};
ImageButton imageBtnCategory = (ImageButton) v.findViewById(R.id.imageBtnCategory);
ImageButton imageBtnManageKey = (ImageButton) v.findViewById(R.id.imageBtnManageKey);
ImageButton imageBtnChangePswd = (ImageButton) v.findViewById(R.id.imageBtnChangePswd);
imageBtnCategory.setOnClickListener(clickListener);
imageBtnManageKey.setOnClickListener(clickListener);
imageBtnChangePswd.setOnClickListener(clickListener);
return v;
}
public void onTabSelected(Tab tab, FragmentTransaction ft) {
mFragment = new FragmentManage();
ft.add(android.R.id.content, mFragment);
ft.attach(mFragment);
}
public void onTabUnselected(Tab tab, FragmentTransaction ft) {
ft.remove(mFragment);
}
public void onTabReselected(Tab tab, FragmentTransaction ft) {
}
}
Just set a background color to your <fragment /> in XML file.
Solves the issue.
Well Setting up fragment background color is not a solution because fragment will be still in the activity stack which may consume memory.
Solution would be remove all views from your framelayout before adding any new fragment.
private void changeFragment(Fragment fr){
FrameLayout fl = (FrameLayout) findViewById(R.id.mainframe);
fl.removeAllViews();
FragmentTransaction transaction1 = getSupportFragmentManager().beginTransaction();
transaction1.add(R.id.mainframe, fr);
transaction1.commit();
}
I may be very late to answer this question.
Note:
This answer may not be related to the above question, But hope it will help for some.
Sometimes, Fragment overlap issue occurs when we try to use the different type of fragments( i.e using support fragment's in few fragments and normal fragments in someother fragment )
Recently i faced the same problem in Navigation drawer.
By mistake, i used "import android.support.v4.app.Fragment;" in one fragment, And used "import android.app.Fragment;" in few other fragment.
Hope this will help for somebody..
fragment manager maintains the stack of all the previous fragments that are replaced sometimes the back stack fragments overlaps with the fragment we replaced, for me
fragmentManager.popBackStack();
works, we can do this in a loop too to pop all the fragments in the stack hope it helps, Thanks. Happy Coding :)
This is how I fixed it ..
Setting the background would remove the overlapping effect from the screen only if the layout is matched to fill screen
New fragments replaced on button clicks were not getting replaced on tab_selected or tab change action
following code fixed it for me
public void onTabUnselected(Tab tab, FragmentTransaction ft) {
// This is required since button click replaces fragment whose link is lost hence overlapping isuee was occuring
ft.replace(android.R.id.content, mFragment);
// On Tab Change remove old fragment views
ft.remove(mFragment);
}
Did you check your XML and see if the main layout is Frame Layout? If not then, use the Frame Layout instead. This will resolve overlapping issue. That's the only way to fix. I tried the "accepted" answer while searching for a solution for this problem and it didn't work.
Another problem can be related to using android.R.id.content as a container. I've just created FrameLayout and use id from there.
I also faced fragment overlapping issue.Here is how I solved it -
1) We need to add the first fragment with addToBackStack, so that it is retained in the stack -
FirstFragment firstFragment = new FirstFragment();
getFragmentManager().beginTransaction().add(R.id.fragment_container, firstFragment).addToBackStack("first frag").commit();
2) While adding the second fragment, replace the first fragment rather then adding it.Since the first fragment was already added in the stack, so it will be present when you press back from second fragment -
SecondFragment secondFragment= new SecondFragment();
getFragmentManager().beginTransaction().replace(R.id.fragment_container, secondFragment).addToBackStack("second frag").commit();
3) Here is how back press can be handled, below code should be present in the parent Activity -
public void onBackPressed(){
if(getFragmentManager().getBackStackEntryCount() <= 1){
super.onBackPressed();
} else {
getFragmentManager().popBackStack();
}
}
private void changeFragment(Fragment fr){
FrameLayout fl = (FrameLayout) findViewById(R.id.mainframe);
fl.removeAllViews();
FragmentTransaction transaction1 =getSupportFragmentManager().beginTransaction();
transaction1.add(R.id.mainframe, fr);
transaction1.commit();}
when you have a overlap fragment, maybe your background of your fragment is transparent, you need put a android:background="#color/white"' inside your fragment propeties
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="#color/white"
and white you need put inside of the colors.xml
#FFFFFF in the rest folder.
I have sometimes the same problem, but my problem is not related to different fragment managers (getSupportFragmentManager(), getFragmentManager()). I think there is still another problem. In my case, when I open the navigation drawer, I always delete old fragments on every menu option, for example:
Fragment calendarFragment = context.getSupportFragmentManager().findFragmentByTag(FragmentTag.CALENDAR.name());
if (calendarFragment != null)
{
context.getSupportFragmentManager().beginTransaction().remove(calendarFragment).commit();
}
It's not possible to get into a sub menu without the navigation drawer, so the fragments are basically always removed. In some cases, after I remove and add a fragment again inside an Activity it suddenly overlaps with another (previous) fragment?! But why does the fragment manager suddenly finds previous fragments?
That can either mean that the fragment manager is buggy and it does not remove old fragments, or that something other is broken.
My thought is, that it's somehow the fault of Android Studio or any other adb development tool which is used by it. Why I think that is, because Android Studio sometimes seem to loose the instance of the running app. Probably this problem is somehow related to the same issue: Android Studio not deploying changes to app. I didn't figure out yet when this happens. What I know is that it can't be a programming issue, because it's not reproducible after I relaunched the app by Android Studio. I guess there are somehow any background processes hanging which causes multiple instances of Activities, Fragments, fragment managers and so on. Furthermore it's not just this bug. I saw a lot of strange behaviours in past which are similar to this one. (For example the behaviours suddenly disappeared when the app was not started by IDE).
It all has to do with the engineering behind the replace and the addToBackStack methods.
The replace method will actually do two things. Hide the existing fragment (let's say A) and add a new one (let's say B) in the container.
Adding that transaction to the back stack will do the opposite.
Remove B and add A.
So, the solution to your problem is
1. use addToBackStack method.
2. make sure that the reverse replacement of fragments is the correct order
The second suggestion is really important, because it is pretty often that at some point the current fragment is not removed and another one is added, which causes the two fragments showing at the same time.
Making the background color white solved it for me too. I think this is a bug or and implementation issue in the Android fragmentment manager. I was implementing my replace and popBackStack() correctly.
When I had a problem like this it appeared that I was adding one fragment with childFragmentManager and another with parent's fragmentManager, so check that you use same type of fragment manager.
I don't think implementing a white background is a safe solution although it may be convenient. Basically the problem occurs because fragment manager is confused about which fragment to pop.
backstack looks like this and thinks your on frag 4 1->2, 2->3, 3->4
but your actually on frag 6 for some reason so popbackstack goes
remove(4) add(3) <- now you have 3(new) and 6(left behind) blended together
To better control my navigation I keep track of my current/previous fragments and replace them like this. This allows my app to control fragment navigation.
if ( !(currentFragment instanceof Settings)) {
FragmentManager fragmentManager = getFragmentManager();
FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();
fragmentTransaction.replace(R.id.fragment_container, settings);
fragmentTransaction.addToBackStack(null);
previousFrag = currentFragment;
currentFragment = settings;
fragmentTransaction.commit();
}
Secondly, I believe the fragmentmanager.replace() method is a better alternative. Not sure if that is available to OP at the time.
Third, to handle the androids native back press you need to be able to scroll back indefinitely. Many people recommend not adding the first fragment to back stack by not using this line.
fragmentTransaction.addToBackStack(null);
However if that's the case you must check if its the first time the app has loaded. If its not and you exclude this line then your app will have these issues whenever you navigate through this fragment. I prefer to leave it in place and do the following instead.
Not sure if this is considered a good solution but it works very well.
1- get backstack count
2- remove all existing frags
3- keep track of you fragment objects
4- if its the last frag in the stack the user wishes to exit and since we added the main activity to the back stack we need to double pop
#Override
public void onBackPressed() {
int num = getFragmentManager().getBackStackEntryCount();
fl.removeAllViews();
super.onBackPressed();
if (currentFragment != previousFrag) {
currentFragment = previousFrag;
}else{
currentFragment = null;
}
if (num == 1){
super.onBackPressed();
}
I found simple and clean solution. For me problem was in execution fragment transaction in every call of onCreate() of my Activity.
Now I perform transaction only if savedInstanceState == null
#Override
protected void onCreate(#Nullable Bundle savedInstanceState) {
if (savedInstanceState == null) {
// replace fragment
}
}
Instead of using fragment as the container for the fragments, use FragmentContainerView. That solved the issue for me
I am facing a problem of overlapping fragments when i switch between tabs and attach fragments to a tab view
below is my code please help
public class FragmentManage extends Fragment implements ActionBar.TabListener {
private Fragment mFragment;
#Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
View v = inflater.inflate(R.layout.fragment_manage, container, false);
OnClickListener clickListener = new OnClickListener() {
public void onClick(View v) {
FragmentTransaction ft = getFragmentManager().beginTransaction();
switch(v.getId()) {
case R.id.imageBtnCategory:
if (mFragment == null){
mFragment = new FragmentCategory();
}
ft.replace(android.R.id.content, mFragment);
break;
case R.id.imageBtnManageKey:
if (mFragment == null){
mFragment = new FragmentKeys();
}
ft.replace(android.R.id.content, mFragment);
break;
case R.id.imageBtnChangePswd:
if (mFragment == null){
mFragment = new FragmentChangePwd();
}
ft.replace(android.R.id.content, mFragment);
break;
}
ft.commit();
}
};
ImageButton imageBtnCategory = (ImageButton) v.findViewById(R.id.imageBtnCategory);
ImageButton imageBtnManageKey = (ImageButton) v.findViewById(R.id.imageBtnManageKey);
ImageButton imageBtnChangePswd = (ImageButton) v.findViewById(R.id.imageBtnChangePswd);
imageBtnCategory.setOnClickListener(clickListener);
imageBtnManageKey.setOnClickListener(clickListener);
imageBtnChangePswd.setOnClickListener(clickListener);
return v;
}
public void onTabSelected(Tab tab, FragmentTransaction ft) {
mFragment = new FragmentManage();
ft.add(android.R.id.content, mFragment);
ft.attach(mFragment);
}
public void onTabUnselected(Tab tab, FragmentTransaction ft) {
ft.remove(mFragment);
}
public void onTabReselected(Tab tab, FragmentTransaction ft) {
}
}
Just set a background color to your <fragment /> in XML file.
Solves the issue.
Well Setting up fragment background color is not a solution because fragment will be still in the activity stack which may consume memory.
Solution would be remove all views from your framelayout before adding any new fragment.
private void changeFragment(Fragment fr){
FrameLayout fl = (FrameLayout) findViewById(R.id.mainframe);
fl.removeAllViews();
FragmentTransaction transaction1 = getSupportFragmentManager().beginTransaction();
transaction1.add(R.id.mainframe, fr);
transaction1.commit();
}
I may be very late to answer this question.
Note:
This answer may not be related to the above question, But hope it will help for some.
Sometimes, Fragment overlap issue occurs when we try to use the different type of fragments( i.e using support fragment's in few fragments and normal fragments in someother fragment )
Recently i faced the same problem in Navigation drawer.
By mistake, i used "import android.support.v4.app.Fragment;" in one fragment, And used "import android.app.Fragment;" in few other fragment.
Hope this will help for somebody..
fragment manager maintains the stack of all the previous fragments that are replaced sometimes the back stack fragments overlaps with the fragment we replaced, for me
fragmentManager.popBackStack();
works, we can do this in a loop too to pop all the fragments in the stack hope it helps, Thanks. Happy Coding :)
This is how I fixed it ..
Setting the background would remove the overlapping effect from the screen only if the layout is matched to fill screen
New fragments replaced on button clicks were not getting replaced on tab_selected or tab change action
following code fixed it for me
public void onTabUnselected(Tab tab, FragmentTransaction ft) {
// This is required since button click replaces fragment whose link is lost hence overlapping isuee was occuring
ft.replace(android.R.id.content, mFragment);
// On Tab Change remove old fragment views
ft.remove(mFragment);
}
Did you check your XML and see if the main layout is Frame Layout? If not then, use the Frame Layout instead. This will resolve overlapping issue. That's the only way to fix. I tried the "accepted" answer while searching for a solution for this problem and it didn't work.
Another problem can be related to using android.R.id.content as a container. I've just created FrameLayout and use id from there.
I also faced fragment overlapping issue.Here is how I solved it -
1) We need to add the first fragment with addToBackStack, so that it is retained in the stack -
FirstFragment firstFragment = new FirstFragment();
getFragmentManager().beginTransaction().add(R.id.fragment_container, firstFragment).addToBackStack("first frag").commit();
2) While adding the second fragment, replace the first fragment rather then adding it.Since the first fragment was already added in the stack, so it will be present when you press back from second fragment -
SecondFragment secondFragment= new SecondFragment();
getFragmentManager().beginTransaction().replace(R.id.fragment_container, secondFragment).addToBackStack("second frag").commit();
3) Here is how back press can be handled, below code should be present in the parent Activity -
public void onBackPressed(){
if(getFragmentManager().getBackStackEntryCount() <= 1){
super.onBackPressed();
} else {
getFragmentManager().popBackStack();
}
}
private void changeFragment(Fragment fr){
FrameLayout fl = (FrameLayout) findViewById(R.id.mainframe);
fl.removeAllViews();
FragmentTransaction transaction1 =getSupportFragmentManager().beginTransaction();
transaction1.add(R.id.mainframe, fr);
transaction1.commit();}
when you have a overlap fragment, maybe your background of your fragment is transparent, you need put a android:background="#color/white"' inside your fragment propeties
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="#color/white"
and white you need put inside of the colors.xml
#FFFFFF in the rest folder.
I have sometimes the same problem, but my problem is not related to different fragment managers (getSupportFragmentManager(), getFragmentManager()). I think there is still another problem. In my case, when I open the navigation drawer, I always delete old fragments on every menu option, for example:
Fragment calendarFragment = context.getSupportFragmentManager().findFragmentByTag(FragmentTag.CALENDAR.name());
if (calendarFragment != null)
{
context.getSupportFragmentManager().beginTransaction().remove(calendarFragment).commit();
}
It's not possible to get into a sub menu without the navigation drawer, so the fragments are basically always removed. In some cases, after I remove and add a fragment again inside an Activity it suddenly overlaps with another (previous) fragment?! But why does the fragment manager suddenly finds previous fragments?
That can either mean that the fragment manager is buggy and it does not remove old fragments, or that something other is broken.
My thought is, that it's somehow the fault of Android Studio or any other adb development tool which is used by it. Why I think that is, because Android Studio sometimes seem to loose the instance of the running app. Probably this problem is somehow related to the same issue: Android Studio not deploying changes to app. I didn't figure out yet when this happens. What I know is that it can't be a programming issue, because it's not reproducible after I relaunched the app by Android Studio. I guess there are somehow any background processes hanging which causes multiple instances of Activities, Fragments, fragment managers and so on. Furthermore it's not just this bug. I saw a lot of strange behaviours in past which are similar to this one. (For example the behaviours suddenly disappeared when the app was not started by IDE).
It all has to do with the engineering behind the replace and the addToBackStack methods.
The replace method will actually do two things. Hide the existing fragment (let's say A) and add a new one (let's say B) in the container.
Adding that transaction to the back stack will do the opposite.
Remove B and add A.
So, the solution to your problem is
1. use addToBackStack method.
2. make sure that the reverse replacement of fragments is the correct order
The second suggestion is really important, because it is pretty often that at some point the current fragment is not removed and another one is added, which causes the two fragments showing at the same time.
Making the background color white solved it for me too. I think this is a bug or and implementation issue in the Android fragmentment manager. I was implementing my replace and popBackStack() correctly.
When I had a problem like this it appeared that I was adding one fragment with childFragmentManager and another with parent's fragmentManager, so check that you use same type of fragment manager.
I don't think implementing a white background is a safe solution although it may be convenient. Basically the problem occurs because fragment manager is confused about which fragment to pop.
backstack looks like this and thinks your on frag 4 1->2, 2->3, 3->4
but your actually on frag 6 for some reason so popbackstack goes
remove(4) add(3) <- now you have 3(new) and 6(left behind) blended together
To better control my navigation I keep track of my current/previous fragments and replace them like this. This allows my app to control fragment navigation.
if ( !(currentFragment instanceof Settings)) {
FragmentManager fragmentManager = getFragmentManager();
FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();
fragmentTransaction.replace(R.id.fragment_container, settings);
fragmentTransaction.addToBackStack(null);
previousFrag = currentFragment;
currentFragment = settings;
fragmentTransaction.commit();
}
Secondly, I believe the fragmentmanager.replace() method is a better alternative. Not sure if that is available to OP at the time.
Third, to handle the androids native back press you need to be able to scroll back indefinitely. Many people recommend not adding the first fragment to back stack by not using this line.
fragmentTransaction.addToBackStack(null);
However if that's the case you must check if its the first time the app has loaded. If its not and you exclude this line then your app will have these issues whenever you navigate through this fragment. I prefer to leave it in place and do the following instead.
Not sure if this is considered a good solution but it works very well.
1- get backstack count
2- remove all existing frags
3- keep track of you fragment objects
4- if its the last frag in the stack the user wishes to exit and since we added the main activity to the back stack we need to double pop
#Override
public void onBackPressed() {
int num = getFragmentManager().getBackStackEntryCount();
fl.removeAllViews();
super.onBackPressed();
if (currentFragment != previousFrag) {
currentFragment = previousFrag;
}else{
currentFragment = null;
}
if (num == 1){
super.onBackPressed();
}
I found simple and clean solution. For me problem was in execution fragment transaction in every call of onCreate() of my Activity.
Now I perform transaction only if savedInstanceState == null
#Override
protected void onCreate(#Nullable Bundle savedInstanceState) {
if (savedInstanceState == null) {
// replace fragment
}
}
Instead of using fragment as the container for the fragments, use FragmentContainerView. That solved the issue for me