Let's say I have three fragments, A, B, C;
A -> B <-> C
Between B and C it is a circular relationship. Either B or C fragments requires arguments, example
val args = Bundle()
args.putString("StringKeyBC", argValueBtoC)
findNavController().navigate(R.id.action_fragmentB_to_fragmentC, args, null)
args.putString("StringKeyCB", argValueCtoB)
findNavController().navigate(R.id.action_fragmentC_to_fragmentB, args, null)
The problem is that every time I move between B & C, the fragments are added to back stack and I don't want that. If the fragment is already to back stack I want just to pop it, but if I use popBackStack I can not add arguments anymore:
public boolean popBackStack(#IdRes int destinationId, boolean inclusive)
So, how can I constanlty switch between the two fragments without adding them every time to back stack?
You can pop fragments from back stack simply by adding a popUpTo attribute to a navigation action. This way you navigate using an action with arguments, but with pop back stack behaviour.
For example, you can add attribute app:popUpTo="#+id/fragmentB" to the action action_fragmentC_to_fragmentB. This way you'll be popping fragmentC from backstack each time you go from fragmentC to fragmentB.
See the docs with example for this here.
There's another option, which is likely an overhead for the case you described, but that allows to use popBackStack method and send arguments - using 'navigate back with result' approach. For it fragments should implement an interface (callback) with a method that receives bundle. Use addOnBackStackChangedListener in the fragment manager to trigger this method, providing all the data necessary, after popBackStack is called. (Described here in the section "How to navigate back with a result?": https://medium.com/google-developer-experts/using-navigation-architecture-component-in-a-large-banking-app-ac84936a42c2, and with slightly different implementation here: https://medium.com/#zawadz88/david-vávra-thank-you-for-this-great-article-ae3e602b880a)
Related
In my app, I have a TopActionBar fragment that is loaded on the MainActivity that loads a MaterialToolbar, along with my navigation drawer. I have a FrameLayout in this fragment that I replace with fragments to navigate between pages. When I replace a fragment (using a function I have defined in a utils.kt file), I am tracking the fragments that are loaded for the first time and adding them to the BackStack so that I can pop them and prevent duplicates of that fragment from being added to the BackStack. Here is the relevant logic for how that is being managed in my Utils.kt file:
fun replaceFragment(destinationFragment : Fragment,
currentFragment: String,
title : String,
initialLaunch: Boolean = false
) {
val destinationFragmentName = destinationFragment.javaClass.simpleName
val fragmentTag : Fragment? = fragmentManager.findFragmentByTag(destinationFragmentName)
if(destinationFragmentName !== currentFragment || initialLaunch) {
val fragmentTransaction = fragmentManager.beginTransaction()
// some logic to determine animations depending on the fragment being replaced
if (fragmentTag == null) {
fragmentTransaction.replace(R.id.frame_layout, destinationFragment, destinationFragmentName)
fragmentTransaction.addToBackStack(destinationFragmentName)
} else { // re-use the old fragment
fragmentTransaction.replace(R.id.frame_layout, destinationFragment, destinationFragmentName)
}
fragmentTransaction.commit()
}
}
And then this is how I have overwritten the onBackPressed function in my MainActivity:
override fun onBackPressed() {
if (fragmentManager.backStackEntryCount > 0) {
fragmentManager.popBackStackImmediate()
} else {
super.onBackPressed()
}
}
A couple of things aren't working properly. Take this example flow of fragments below:
A -> B -> C -> B -> C
When I press back I get this flow:
BC -> AC -> App Close
Here multiple Fragments are being displayed at the same time.
What I expect to happen is:
C -> B -> A -> App Close
Can someone maybe offer some insights into why this is occurring and what I can do to fix this? If I don't conditionally addToBackStack, and just addToBackStack for every single Fragment I replace, it works fine, but I don't want the multiple copies in the BackStack. I need to keep the most recent instance of each Fragment in the BackStack. So in my example:
A -> B -> C -> B -> C
The BackStack would no longer have the first C, just the most recent one.
As per the FragmentManager guide:
When you call addToBackStack() on a transaction, note that the transaction can include any number of operations, such as adding multiple fragments, replacing fragments in multiple containers, and so on. When the back stack is popped, all of these operations are reversed as a single atomic action. If you've committed additional transactions prior to the popBackStack() call, and if you did not use addToBackStack() for the transaction, these operations are not reversed. Therefore, within a single FragmentManager, avoid interleaving transactions that affect the back stack with those that do not.
So what you are experiencing is the operation you did with addToBackStack being reversed (causing your original copy of B to reappear) while not touching the new C you did not use addToBackStack.
The FragmentManager's back stack is just that: a stack. That means you can't remove B from the stack unless it is at the top of the back stack. That means there's no way to remove B from the middle of the stack without using something like the support for multiple back stacks to completely swap between independent back stacks.
If you just want to make sure there is only one copy of B on the top of the stack, you'll want to popBackStack() to remove the topmost if the names are the same before unconditionally using addToBackStack() on your new instance.
I add fragments to back stack. For instance: A, B, C, A, D. Then from D I want to update the second A.
If I use supportFragmentManager.findFragmentByTag("A"), I have a reference to the first A, that is in a bottom of the back stack.
I tried to search through fragments collection, getBackStackEntryAt(i), but with no success.
Sorry, looking at get the latest fragment in backstack I understood that findFragmentByTag(tag) finds the last fragment with required tag. In my case after adding many fragments it sometimes found not last fragment with tag, but a previous to last (with the same tag). Maybe there is a bug in my code, I don't know, why is that.
First I tried to use callbacks, then tried to use parentFragment and childFragmentManager, see getParentFragment returning null. In fragment D I called parentFragment and accessed to methods of A and could update the last A fragment. This solution has two problems.
1) Child fragment (D) inherits a toolbar from parent (A) and adds own buttons. And after clicking Back button we return not to a parent, but even quit parent (A).
2) If we want to update not previous fragment (so that between A and D are also 3 fragments), it seems to be impossible.
So, I cancelled that solution and changed the application behaviour. I clear a backstack where it is possible. So that we cannot have two A fragments in backstack. I use supportFragmentManager.popBackStack(null, FragmentManager.POP_BACK_STACK_INCLUSIVE). Yes, that's a workaround, but I don't know, how to deal with that bug.
I am trying to use the Navigation architecture component in my toy app.
First I drew the fragments relationship in my "nav_graph.xml".
For example, I drew 3 fragments A, B, and C like below:
A -> B -> C
So I have 2 actions:
action_a_to_b
action_b_to_c
In general, I use the below code to move another fragment.
In A fragment,
findNavController().navigate(ADirections.actionAToB())
In B fragment,
findNavController().navigate(ADirections.actionBToC())
But you may know, there is another way to navigate.
The fragment id can be used to navigate directly like below:
findNavController().navigate(R.id.a)
In my case, I don't have the action for A to C fragment.
But if I use the below code in my A fragment, I can navigate!
findNavController().navigate(R.id.c)
Is it a bug? or intented?
This is intentional as per the documentation for navigate():
This supports both navigating via an action and directly navigating to a destination.
If you're using Safe Args, then only actions are supported. This ensures that you're only using the connections you've specified in your graph.
I've a fragment A. I add() it with tag like this:
fragmentTransaction.addToBackStack(special_tag);
Then I simply add() fragment B on top of fragment A. After that, I decide to remove fragment B and go back to fragment A using:
activity.fragmentManager.popBackStackImmediate(special_tag, 0)
When I reach the fragment A, it seems that fragment doesn't re-run it's lifecycle methods: onAttach(), onResume(), onCreate() ect.
Can someone explain this behavior and maybe suggest an alternative?
(I need to "refresh" the data when I come back to fragment A second time)
What is causing this result?
Is there a clean solution/work-around?
Update
Fragment B is GuidedStepFragment and does not have a .replace() function. I found that it has finishGuidedStepFragments(), but it behaves the same (it does not call fragment life cycle functions)
Situation (again):
Fragment A (Simple fragment) -> .add(Fragment B) (GuidedStepFragment) -> popBackStackImmediate() or finishGuidedStepFragments()
I add Fragment B like this:
GuidedStepFragment.add(activity.fragmentManager, fragmentB.createInstance())
Using fragmentTransaction.add(Fragment) doesn't remove Fragment A. What is actually happening is that Fragment A is still running behind Fragment B. Since Fragment A never stopped running, it's lifecycle has no need to retrigger.
Consider using fragmentTransaction.replace(Fragment) and replace the fragment in the container (fragment A) with fragment B. If you pop that transaction from the back stack, then Fragment A will reattach and follow your expected lifecycle.
Update
Since you seem to be using GuidedStepFragments from the leanback library, this is a little tricky. GuidedStepFragment actually performs replace(...) under the hood, but you're adding fragment B to a different container so the original behavior I mentioned doesn't apply.
I'm not super familiar with leanback (since it's usually only used for android tv), but I do know that you can at least do the following. If you keep track of your backstack size, when all of the GuidedStepFragments have been popped, you will have returned to your original fragment. For example, let's assume your backstack starts at zero:
activity.fragmentManager.addOnBackStackChangedListener(new FragmentManager.OnBackStackChangedListener() {
#Override
public void onBackStackChanged() {
if (activity.fragmentManager.getBackStackEntryCount() == 0){
// handle your updates
}
}
});
// the next line of code will add an entry to the backstack
GuidedStepFragment.add(activity.fragmentManager, fragmentB.createInstance());
// eventually when back is pressed and the guided fragment is removed, the backstack listener should trigger
I am a bit confused about what is the ideologically correct way of using fragments.
As the Android Developers states,
A Fragment represents a behavior or a portion of user interface in an
Activity. You can combine multiple fragments in a single activity to
build a multi-pane UI and reuse a fragment in multiple activities. You
can think of a fragment as a modular section of an activity, which has
its own lifecycle, receives its own input events, and which you can
add or remove while the activity is running (sort of like a "sub
activity" that you can reuse in different activities).
And also:
Fragments decompose application functionality and UI into reusable
modules Add multiple fragments to a screen to avoid switching
activities
And my usage of fragments goes the following way:
I have only one main Activity and a whole bunch of fragments. Instead of starting activities, I prefer replacing fragments.
For example, I have FeedsFragment, FriendsFragment, MessagesFragment, and when I select something from sliding menu, my Activity just replaces the main Fragment. If I'm launching a Fragment from other Fragment, I put the previous one in backstack.
Some fragments require the Activity to change the actionbar, an I do it directly by
((MainActivity)getActivity()).setupActionBar();
Currently I don't have any code that supports tablet layouts (as seen in examples on android developers), but I'm planning to add it.
So, is this the right way of doing things? Or am I completely missing something?
As you know fragment has their own lifecycle, and you can use its event when ever you want from the activity lifecyle.
But Fragments lifecycle depens on activity lifecycle So when actvity destroyed, fragments destroyed also.
// Create new fragment and transaction
Fragment newFragment = new ExampleFragment();
FragmentTransaction transaction = getFragmentManager().beginTransaction();
// Replace whatever is in the fragment_container view with this fragment,
// and add the transaction to the back stack
transaction.replace(R.id.fragment_container, newFragment);
transaction.addToBackStack(null);
// Commit the transaction
transaction.commit();
Yo can use the fragment transaction, to replace them in one activity, I think you use the same way,
i think you arent wrong way and there are no problem to use fragment instead of using different activites.
But you should think about, you realy need to use them in one activty ? If you dont need to show them in one activity you dont need to use fragment.
A fragment must always be embedded in an activity and the fragment's
lifecycle is directly affected by the host activity's lifecycle. For
example, when the activity is paused, so are all fragments in it, and
when the activity is destroyed, so are all fragments. However, while
an activity is running (it is in the resumed lifecycle state), you can
manipulate each fragment independently, such as add or remove them.
When you perform such a fragment transaction, you can also add it to a
back stack that's managed by the activity—each back stack entry in the
activity is a record of the fragment transaction that occurred. The
back stack allows the user to reverse a fragment transaction (navigate
backwards), by pressing the Back button.
As a result , it is not wrong , but i think if you dont need, creating different activity is easy to maintain.