WAI
Status Update
Comments
il...@google.com <il...@google.com> #2
Fragments on the back stack automatically have their state saved and restored.
Can you describe your use case and exactly what user interaction pattern you're trying to achieve?
Can you describe your use case and exactly what user interaction pattern you're trying to achieve?
gi...@gmail.com <gi...@gmail.com> #3
Hello, even if I didn't open this issue I'd like to contribute to it instead of opening a new one.
Imagine this situation: I have two pages, A and B that are hosted within Fragment in order to follow 1-Activity pattern advised by Google.
In A I have a list of items in a list and a search box in the toolbar that is used to filter the list items and maybe I also have other elements in the UI (maybe custom views).
The user searches for some elements and scrolls a bit the list. Maybe he performs some other operations that change the UI.
The user then clicks on an item of the list and then B is being shown. Fragment hosting A is getting destroyed by the framework: this is because Android X Navigation library uses FragmentTransaction#replace.
When the user goes back to display A again, the Fragment hosting A is getting recreated so onCreate and onCreateView will be called.
In order to restore (and also save) the state I have to write a lot of code in order to display the exact view as the user left it before landing to B. True, ViewModel helps but still, I have to write some code.
Usually on Android, in order to avoid this, developers approach the problem with two solutions:
1) Use Activities instead of Fragments
2) Use FragmentTransaction#add instead of #replace and hide and show properly the fragments in the backstack
I understand that Android X Navigation library supports solution #1 (this is just an assumption, I haven't tried it because not interested in this architecture) but not #2.
I saw some developers implementing solution #2 (for examplehttps://goo.gl/Wb3iFT ) but it would be cool this feature would come from the library itself.
Imagine this situation: I have two pages, A and B that are hosted within Fragment in order to follow 1-Activity pattern advised by Google.
In A I have a list of items in a list and a search box in the toolbar that is used to filter the list items and maybe I also have other elements in the UI (maybe custom views).
The user searches for some elements and scrolls a bit the list. Maybe he performs some other operations that change the UI.
The user then clicks on an item of the list and then B is being shown. Fragment hosting A is getting destroyed by the framework: this is because Android X Navigation library uses FragmentTransaction#replace.
When the user goes back to display A again, the Fragment hosting A is getting recreated so onCreate and onCreateView will be called.
In order to restore (and also save) the state I have to write a lot of code in order to display the exact view as the user left it before landing to B. True, ViewModel helps but still, I have to write some code.
Usually on Android, in order to avoid this, developers approach the problem with two solutions:
1) Use Activities instead of Fragments
2) Use FragmentTransaction#add instead of #replace and hide and show properly the fragments in the backstack
I understand that Android X Navigation library supports solution #1 (this is just an assumption, I haven't tried it because not interested in this architecture) but not #2.
I saw some developers implementing solution #2 (for example
en...@gmail.com <en...@gmail.com> #4
This is the whole thing.
I was just using navigation component in production and I struggled too much with this issue in two places in my app.
1- I have a main screen that contains list of items.. When I open filter screen from this main screen, I make some selection in filter screen or just cancel... When I back to main screen I lose the Statue and the screen loaded again.
2- again, I have main screen with two spinner inside it.. The spinner is settled on default values because I filter the list in main screen by choosing from spinner. When I open detail fragment from main screen and go back to main screen, I found the spinner has selected a new values... Which produces very wrong behavior.
So I solved first issue by making filter screen activity, and second issue forced me to remove the spinner from the screen..
This was really bad situation.
I was just using navigation component in production and I struggled too much with this issue in two places in my app.
1- I have a main screen that contains list of items.. When I open filter screen from this main screen, I make some selection in filter screen or just cancel... When I back to main screen I lose the Statue and the screen loaded again.
2- again, I have main screen with two spinner inside it.. The spinner is settled on default values because I filter the list in main screen by choosing from spinner. When I open detail fragment from main screen and go back to main screen, I found the spinner has selected a new values... Which produces very wrong behavior.
So I solved first issue by making filter screen activity, and second issue forced me to remove the spinner from the screen..
This was really bad situation.
il...@google.com <il...@google.com> #5
If your Fragment can restore its View state over configuration changes (such as rotating your device) and restore its state exactly as it was over process death (such as when you have "Don't keep activities" enabled), then it can also keep its View state while it is on the back stack.
This is true with or without Navigation and generally requires no extra code on your part besides ensuring that your Views have unique android:id values and that custom views you've written are set up to save and restore their state. If you're having problem with that, you need to fix that issue with your code first or file a bug against the specific View that is unable to keep its state.
This is true with or without Navigation and generally requires no extra code on your part besides ensuring that your Views have unique android:id values and that custom views you've written are set up to save and restore their state. If you're having problem with that, you need to fix that issue with your code first or file a bug against the specific View that is unable to keep its state.
gi...@gmail.com <gi...@gmail.com> #6
I understand your point.
What I am asking, and OP too, I think, is to add a feature that uses FragmentTransactions#add with #hide and #show. Is Google against adding fragments instead of replacing?
What I am asking, and OP too, I think, is to add a feature that uses FragmentTransactions#add with #hide and #show. Is Google against adding fragments instead of replacing?
il...@google.com <il...@google.com> #7
Let's take a step back: http://xyproblem.info/
You've explained a solution, but I'd prefer to solve a problem you're having. If the problem is that your Fragment loses View state when coming back from the back stack, as mentioned in the title of this issue and comments #3 and #4, then all of the tools needed to solve this problem already exist and you absolutely need to solve this problem for the configuration change and process death situations, whether Navigation provided add/hide/show functionality or replace functionality.
You've explained a solution, but I'd prefer to solve a problem you're having. If the problem is that your Fragment loses View state when coming back from the back stack, as mentioned in the title of this issue and comments #3 and #4, then all of the tools needed to solve this problem already exist and you absolutely need to solve this problem for the configuration change and process death situations, whether Navigation provided add/hide/show functionality or replace functionality.
en...@gmail.com <en...@gmail.com> #8
We don't have any problem with screen configuration or changing the screen orientation!
If we have screen A as main screen and open any other fragment in the same navigation.xml (the same activity container) the problem occur.
And the problem is: when I get back to the main screen "A" it's reloaded again, which equal to `FragmentTransactions#replace`, which equal to recreating the screen (Fragment).
How I can solve this Issue in the regular `FragmentTransactions` ? : I solve this Issue by using `add()` Instead of `replace()`
How is that related to the Issue title? : **Open fragment without lose the previous fragment states** keeping states doesn't main using `savingInstance` or saving viewsInstance, It's just mean keep screen as it, like we do using `FragmentTransactions#add` and that's described in github link I provided, also concluded from comments in github.
Thank you, I hope you got our problem now.
If we have screen A as main screen and open any other fragment in the same navigation.xml (the same activity container) the problem occur.
And the problem is: when I get back to the main screen "A" it's reloaded again, which equal to `FragmentTransactions#replace`, which equal to recreating the screen (Fragment).
How I can solve this Issue in the regular `FragmentTransactions` ? : I solve this Issue by using `add()` Instead of `replace()`
How is that related to the Issue title? : **Open fragment without lose the previous fragment states** keeping states doesn't main using `savingInstance` or saving viewsInstance, It's just mean keep screen as it, like we do using `FragmentTransactions#add` and that's described in github link I provided, also concluded from comments in github.
Thank you, I hope you got our problem now.
il...@google.com <il...@google.com> #9
Please include a sample project of a Fragment that restores its view state correctly over configuration changes, restores its view state when using 'Don't keep activities' and restoring from saved instance state, and does *not* restore its view state correctly when restored from the back stack after a replace operation (i.e., what Navigation does when you pop the back stack). That would be helpful in narrowing down why you are losing state.
gi...@gmail.com <gi...@gmail.com> #10
It is not mandatory to implement a correct fragment state restoration and saving. The activity might be ignoring configuration changes or the fragment might have retainInstance set to true.
If we consider iOS, the screens that are stacked during the navigation are not destroyed but only notified when visible or not.
I really think the team working on this library should consider also this option because a lot of users won't be using it because framentTransaction#add is not being used.
If we consider iOS, the screens that are stacked during the navigation are not destroyed but only notified when visible or not.
I really think the team working on this library should consider also this option because a lot of users won't be using it because framentTransaction#add is not being used.
mo...@gmail.com <mo...@gmail.com> #11
There is an easier case:
Consider a fragment that is heavy to create. Containing viewPager, a MapFragment etc.
Recreating the above fragment is a heavy operation, add here makes more sense, and why is Google against adding? Is it deprecated? If not then this should be reflected in the navigation architecture component
Consider a fragment that is heavy to create. Containing viewPager, a MapFragment etc.
Recreating the above fragment is a heavy operation, add here makes more sense, and why is Google against adding? Is it deprecated? If not then this should be reflected in the navigation architecture component
[Deleted User] <[Deleted User]> #12
I also don't understand why only replace transactions are supported. Maybe giving a detailed answer would help us understand. Is it technically difficult? If so then why? If it's not difficult to add then why not make the API more flexible?
[Deleted User] <[Deleted User]> #13
Quoting Ian Lake - twitter.com/ianhlake/status/1103522856535638016
"You don't have to inflate a new View every time onCreateView is called - you can keep a reference to the View you created the first time and return it again. Of course, that is a constant waste of memory and resources for something not visible. Keeping your data >> your View"
So basically you can save view instance and pass pre-stored view on onCreateView() if not null.
"You don't have to inflate a new View every time onCreateView is called - you can keep a reference to the View you created the first time and return it again. Of course, that is a constant waste of memory and resources for something not visible. Keeping your data >> your View"
So basically you can save view instance and pass pre-stored view on onCreateView() if not null.
al...@gmail.com <al...@gmail.com> #14
I also don't understand why use replace to switch frgments. bad user experience
au...@gmail.com <au...@gmail.com> #15
I also don't understand why use replace to switch frgments. bad user experience +1
iu...@gmail.com <iu...@gmail.com> #16
Any solution to this problem??? Still waiting ...
[Deleted User] <[Deleted User]> #17
an...@block.one <an...@block.one> #18
Interesting. Nobody from Google has care about this issue from Mar?
Still waiting for the solution.
Still waiting for the solution.
he...@gmail.com <he...@gmail.com> #19
Also dealing with the issue where I have a heavy fragment which I do not want to recreate.. (I understand the point of dealing with fragment recreation in any case for configuration changes and process death and I have already implemented this), but it genuinely is an issue when you have two fragments that the user is constantly switching between and one of them takes long to initialize. I was caught off guard when I realized this is not supported.
nu...@gmail.com <nu...@gmail.com> #20
I have been using the navigation in production for about a year now, and I am completely dissatisfied with this problem.
This is creates VERY noticeable lags during an animated change of fragments transactions (for example, slide from the edge of the screen).
Yes, i am caching heavy views. But what is the point if this, while they are used like a main screen, and the user is guaranteed to return to this screen after each interaction?
Navigation is qite inflexible and tiring due to such and some another things.
This is creates VERY noticeable lags during an animated change of fragments transactions (for example, slide from the edge of the screen).
Yes, i am caching heavy views. But what is the point if this, while they are used like a main screen, and the user is guaranteed to return to this screen after each interaction?
Navigation is qite inflexible and tiring due to such and some another things.
kt...@gmail.com <kt...@gmail.com> #21
I need to solution for this issue.
WebView will reload when recreate fragment. It's very very terrible.
WebView will reload when recreate fragment. It's very very terrible.
su...@gmail.com <su...@gmail.com> #22
WOW google doesn't give a damn about their backyard dev projects!
They have updated status of the issue
Won't Fix (Intended behavior)
Not cool!
fa...@tinroofsoftware.softvision.com <fa...@tinroofsoftware.softvision.com> #23
I think this has been closed because there is an ongoing issue about adding the functionality as a feature rather than a bug fix
https://issuetracker.google.com/issues/80029773
si...@gmail.com <si...@gmail.com> #24
so it is 2021 now. Is there any solution to this issue.
I am using paging library(data from network) with recyclerview in fragment A and when user click list item, a detail fragment is show. But when user taps back, fragment A get recreated and request new data
I am using paging library(data from network) with recyclerview in fragment A and when user click list item, a detail fragment is show. But when user taps back, fragment A get recreated and request new data
il...@google.com <il...@google.com> #25
Re #24 - all of the
fi...@gmail.com <fi...@gmail.com> #26
Nr. 1 reason why iOS apps are so much more smooth, faster and beautiful, compared to Android apps. Android API's sucks. It's sad to read the comments from Google on this. Forcing fragments to be recreated is simply pathetic and causes so many bad UI/UX experiences with heavy views.
mi...@gmail.com <mi...@gmail.com> #27
Omg, "Google" just repeat answer without explanation why ADD can´t be used, when is clearly faster for back navigation. There is no other solution for us. Imagine viewpager with 7 fragments and each fragments holds hundreds of items in recyclerviews. It take some time to present this and forcing recreate it over and over is very bad practice.
so...@gmail.com <so...@gmail.com> #28
It seems we have to write unnecessary work around code to keep the fragment state as it is using navigation component. Or else google must provide complete example for this if it is really possible
bi...@gmail.com <bi...@gmail.com> #29
End of May, 2022, and we still have this issue...
ro...@gmail.com <ro...@gmail.com> #30
June 2022, still having the issue. C'mon google, get it together...
am...@starzplayarabia.com <am...@starzplayarabia.com> #31
End of June 2022 and we are still looking forward for this fix/update
ch...@gmail.com <ch...@gmail.com> #32
In July 2022, this issue has not been resolved
so...@gmail.com <so...@gmail.com> #33
Those who facing this issue are you guys using the Navigation Component or Fragment Manager?
as...@gmail.com <as...@gmail.com> #34
I am facing this issue using the navigation component.
ts...@gmail.com <ts...@gmail.com> #35
Damn this is stupid.
da...@gmail.com <da...@gmail.com> #36
Damn this is stupid. +1
hu...@gmail.com <hu...@gmail.com> #37
I don't think we are ready for this, we are used to activities that help us to handle backstack and recreation. what's the point of using newer navigation component but result in worse user experience than older way with activities
so...@gmail.com <so...@gmail.com> #38
#37 hi, but sometimes we have design like common toolbar with a notification icon & counter. how you refresh all previous screens?
[Deleted User] <[Deleted User]> #39
Comment has been deleted.
gu...@gmail.com <gu...@gmail.com> #40
2023 june, is there any solution yet ? or andoid is dead ?
en...@gmail.com <en...@gmail.com> #41
Hire me and I will solve this issue for you.
lz...@gmail.com <lz...@gmail.com> #42
Comment has been deleted.
lz...@gmail.com <lz...@gmail.com> #43
I'm so disappointed with Google's capriciousness
bh...@gmail.com <bh...@gmail.com> #44
The People of google Please Just tell me How did you manage this in Google Playstore App ?
When I select "Game" Bottom menu and scroll down after that come back to app menu and again go back to Game menu... And It's exactly at same place where I left it.
So If you don't want to solve or add that feature I want you to create a sample which can have heavy image load verticle and horizontal multiple list etc. Like Google play.
ma...@gmail.com <ma...@gmail.com> #45
I have question. I am using Navigation controller with bottomAppbar navigation which is currntly 5 fragments 1, 2second has three child fragment with viewpager and three of them have recyclerview to fill the data val query: Query =
FirebaseFirestore.getInstance().collection(Constants.collectionPathMatchList)
.whereEqualTo(Constants.matchStatus, Constants.statusUpcoming)
.orderBy(Constants.matchDate, Query.Direction.ASCENDING).limit(30)
val options: FirestoreRecyclerOptions<HomeMatch> =
FirestoreRecyclerOptions.Builder<HomeMatch>().setQuery(query, HomeMatch::class.java)
.setLifecycleOwner(viewLifecycleOwner).build()
upComingAdapter = HomeCardAdapter(requireActivity(), options)
using this method is perfectly but when we launch new activity to call recyclerview item click after that new activity is close then fragment is reloaded I am unable to track how to this issue prevent to stop it. and 3,and 4 fragment also 3 fragmetn like second have same as even if we scrolling 20 out of 30 item of array then as it is not reload if we go with new activity after return the main activity it reloads the fragment how can we stop that (note: I am using kotlin)
FirebaseFirestore.getInstance().collection(Constants.collectionPathMatchList)
.whereEqualTo(Constants.matchStatus, Constants.statusUpcoming)
.orderBy(Constants.matchDate, Query.Direction.ASCENDING).limit(30)
val options: FirestoreRecyclerOptions<HomeMatch> =
FirestoreRecyclerOptions.Builder<HomeMatch>().setQuery(query, HomeMatch::class.java)
.setLifecycleOwner(viewLifecycleOwner).build()
upComingAdapter = HomeCardAdapter(requireActivity(), options)
using this method is perfectly but when we launch new activity to call recyclerview item click after that new activity is close then fragment is reloaded I am unable to track how to this issue prevent to stop it. and 3,and 4 fragment also 3 fragmetn like second have same as even if we scrolling 20 out of 30 item of array then as it is not reload if we go with new activity after return the main activity it reloads the fragment how can we stop that (note: I am using kotlin)
Description
Version used:
Devices/Android versions reproduced on:
Please it will be great if you added this feature to the navigation library (Open fragment without losing the previous fragment state)
Thank you.