How to correctly handle multiple fragment change in Android

Question

Assume I have 4 fragments A B C and D.

A and B are major fragments, C and D are minor.

I use navigation drawer to switch fragments.

A is the default starting fragment.

I want to achieve following features but cannot figure out how to play with the fragment manager and transactions.

1. A -> B or B -> A, replace current fragment, do not push backstack, but I want to keep the current fragment status (e.g. list view position) after navigate back
2. A/B -> C/D, add C/D on top of A/B, using back button to navigate back to A/B.
3. C -> D or D -> C, replace current fagment
4. C/D -> A/B, remove current fragment C/D and show A/B

Is the only way to implement this function that I should write some complicated function for switching the fragments (and also need to keep what is current fragment and what is the wanted target fragment)?

Is there better way out?

---

According to @DeeV 's answer, I came out with something like following.

LocalBrowse and WebsiteExplore are main fragments while Settings and About are sub fragments.

It seems to work fine but still a little bit ugly, any better idea?

private void switchToFragment(Class<?> targetFragmentClz) {
    if(mCurrentFagment!=null && mCurrentFagment.getClass().equals(targetFragmentClz)) {
        return;
    }
    BaseFragment targetFragment = null;
    FragmentTransaction transaction = getSupportFragmentManager().beginTransaction();
    if(targetFragmentClz.equals(LocalBrowseFragment.class)
            || targetFragmentClz.equals(WebsiteExploreFragment.class)) {
        if(mCurrentFagment instanceof SettingsFragment //mCurrentFragment will not be null this time
                || mCurrentFagment instanceof AboutFragment) {
            transaction.remove(mCurrentFagment);
        }
        if(mCurrentMainFagment==null || !mCurrentMainFagment.getClass().equals(targetFragmentClz)) {
            targetFragment = (BaseFragment) Fragment.instantiate(this, targetFragmentClz.getName());
            targetFragment.setHasOptionsMenu(true);
            transaction.replace(R.id.ac_content_frame_main, targetFragment);
            mCurrentMainFagment = targetFragment;
        }
    } else {
        targetFragment = (BaseFragment) Fragment.instantiate(this, targetFragmentClz.getName());
        targetFragment.setHasOptionsMenu(true);
        getSupportFragmentManager().popBackStackImmediate();
        transaction.replace(R.id.ac_content_frame_sub, targetFragment)
                   .addToBackStack(null);
    }

    transaction.commit();
    mCurrentFagment = targetFragment;
}

Answer 1

One method that I can think of is to stack the two types of fragments on each other. So a system like this:

<FrameLayout>
  <FrameLayout id="main_container">
  <FrameLayout id="sub_container">
<FrameLayout>

Would mean that you have two containers holding fragments. The top one completely covers the other. Thus, you could have two method likes this:

public void swapMainContainer(FragmentManager fm, Fragment frag)
{
   fm.beginTransaction().
   .replace(R.id.main_container, frag, "TAG")
   .commit();
}

public void swapSubContainer(FragmentManager fm, Fragment frag)
{
   fm.popBackstackImmediate();
   fm.beginTransaction()
   .replace(R.id.sub_container, frag, "SUBTAG")
   .addToBackStack(null)
   .commit();
}

So if you use swapMainContainer() only with Fragment A and Fragment B, they will constantly replace each other but the commits won't be added to the backstack.

If you use swapSubContainer() only with Fragment C and Fragment D, they will likewise replace each other, but "Back" will close them. You are also popping the backstack every time you commit a sub Fragment thus removing the previous commit. Though, if there's nothing in the backstack, it won't do anything.

To remove C/D, simply call popBackStack() and it will remove them from the stack.

The flaw in this approach however is if you have more than these two Fragments that are added to the backstack. It may get corrupted.

EDIT:

Regarding saving view state, the fragment itself will have to handle that via this method.