In general, it was necessary to implement the task without using PageView, where this task would be much easier to solve. enter image description here

here is my application structure. There is a root FrameView, where I substitute the fragment I need. All would be fine if the three main fragments were not switched by the navigation navigation. The problem is that if you are on a third-level child fragment to switch to another fragment from the bottom navigation, then all the logic of the backStack fragments will fall. A fly of tar still adds an additional fragment, which is called from the side menu. I ask for advice or tips on how best to organize the switching between fragments. if, when switching a fragment in the lower menu, call getFragmentManager.beginTracsacion (). remove (...). commit () and suppress all other fragments, the transition stack is still not reset and even the transition to the zero fragment with the FragmentManager.POP_BACK_STACK_INCLUSIVE flag does not provide the necessary result. in general, the head swells already

    1 answer 1

    Some tips on how I solved a similar problem:

    1) I, having suffered greatly, created my own stack of fragments, such as:

    class SimpleFragmentStack { //содержит в себе теги фрагментов Stack<String> fragmentStack; //добавить фрагмент public void push(int fragmentContainer, Fragment fragment, String tag) { fragmentManager.beginTransaction().replace(fragmentContainer, fragment, tag).addToBackStack(tag).commit(); fragmentStack.push(tag); } //заменить фрагмент на верхушке стека public void replace(int fragmentContainer, Fragment fragment, String tag); //вытолкнуть верхний фрагмент public Fragment pop(); //извлечь фрагмент из верхушки (текущий) public Fragment peek(); //очистить стек public void reset(); public int size() {return fragmentStack.size();} } 

    The idea is that this manual manager of fragments as if duplicates its own stack of system fragments, but at the same time I always have full control over where and which fragment is located, any fragment can be pulled out by its tag, which is stored in my stack of tags. Well, by the way, debugging is also much easier.

    2) The second story is related to the fact that when you have nested fragments in order to reach the nested fragment, you need to use the getChildFragmentManager () method — it works with API 17

    • The idea is interesting .. Now, too, the semblance of manual control of the stack, only in a more collective farm form. getChildFragmentManager () does not suit me, since the minimum API should be 16 ... I now had a thought for using root fragments to use getFragmentManager, and for children, getSupportFragmentManager, to separate flies from cutlets and kill without serious consequences without fear of breaking the stack. but has not yet gone deeper into the jungle of the support library ... if the parent context is also used there, then this is another rake, but less global - baralgin1003