IssueTracker

Can you explain what your use case is?

A home page fragment will be showing more than any other screen, for example. Hide and show of that home screen in any app would be much more efficient, faster to draw and would consume less CPU and battery resources than if that same screen is replaced and redrawn every time it shows.

Thanks for your suggestion and further explanation. We won't be allowing customization of the transaction type (such as hiding/showing, etc) for the foreseeable future.

I understand it is not a bug. Since Navigation is still in beta can you please translate this into a feature request?

This isn't a feature request we'll be implementing in the foreseeable future, sorry.

Does that mean Google will be dropping beta developer input? That is very discouraging. Why would I bother to file issues when that is the case.

Add/hide/show are used under the covers and are valuable for system transactions and Google apps. Are there plans to offer architecture improvements like JetPack Navigation that have efficient fragment management or is that too much for the Google team?

We're looking more holistically at the Fragment API and will take this use case under consideration there (since it is an important use case).

Hey guys! Have you tried to run the sunflower app? I've tried and noticed the following behavior: when the user navigates from PlantListFragment to PlantDetailFragment and go back, the PlantListFragment is unchanged (holds the same state after the navigation).

The bad thing is: when i try to create my own project with navigation, this behavior doesn't work. When the user goes back all the previous state is lost. Any of you had experienced something like that?

Thanks!

Hi there #9 - I maintain the Sunflower repo.  I think issue #10 in the Sunflower GitHub project (https://github.com/googlesamples/android-sunflower/issues/10) might be related to the behavior you're trying to replicate.

Hi there #10! Thank you soooo fu**** much for your answer! I was really desperate for a clue.

I've followed the link and tested with the tip, but it doens't work, my list keep reloading from the top. I'm writing in Java, can be this the problem?

Hi #11 - this issue tracker is for bugs related to the Navigation component.  For further troubleshooting I recommend posting your issue on StackOverflow's with an 'android' tag: http://stackoverflow.com/questions/tagged/android

On Android YouTube app, the BottomNavigationView (if it is such widget) behaves as follows:
1. Default: Home
2. Click on Trending - scroll way down - say Video "HelloWorld" is displayed
3. Click on Subscriptions - scroll way down - say Video "FooBar" is displayed
4. Click on Trending - scrolling position is the same as in (2) - therefore, the fragment is reused, not recreated
5. BACK - Subscriptions is displayed - scrolling position is the same as in (3) - therefore, the fragment is reused, not recreated.
6. BACK - surprisingly, Home is displayed - the logic in YouTube app is that when going back, navigation passes only once on each different fragment

It seems like YouTube app is NOT using the Navigation API - fair enough.
BUT, having the Navigation API recreating each destination fragment whenever an action is taken is wrong. Or, at least, there should should be a flag to reuse the destination fragment rather than create a new instance.
While this new API simplifies overall app navigation, it utilizes more resources and for some use-cases, it will not work - if the YouTube app would use this new API, the scrolling on each section will be reset/reloaded every time we switch... if no caching/local-persistence, this will result in more network calls.

Saving state across bottom navigation items is covered in https://issuetracker.google.com/issues/80029773 which is something Navigation will support.

About #8 When will this holistically retouched version of fragment will come? Can we not invest on other ways to hack this thing when our release date is more than 6 months?  you have any alternative suggestions to achieve this thing?

Yes please suggest some alternative for the time being is possible.

Any workaround so far? It's been a year since the official release of this library, yet we still cannot solve this basic issue?

This issue seems to be highly neglected

It's intended behavior, this means that Google doesn't want you to stack a bunch of fragments on top of each other using show/hide because it promotes bad app architecture and wastes available memory.

Fix/simplify your layouts (Constraint layout), use AsyncInflater, cache your data (ViewModels/Room) or use Epoxy (Complex RecyclerView). It's true that Google is doing a bad job explaining this but it's intended behavior for a reason. Fix the root of the issues and actually understand when to use navigation components (hint: you don't use it for viewpagers). Same for the scrolling issues you guys are mentioning (Epoxy does this nicely already), the scroll position is also something you simply need to save and restore back.

If you REALLY want to do this, just use your own fragment transactions (go old-school) OR don't inflate the view in OnViewCreated but manually keep a reference to it (without leaking) and re-use it manually. Nobody is stopping you from keeping views in memory manually, but the whole point of these jetpack components is to stop you from doing these mistakes in the first place.

Yeah Google also raises the expense of inflating views frequently. So if there does happen to be one main fragment that is viewed more than any others, it will have to be inflated every time. this kind of homepage scenario is quite common in app development. Is this good architecture from Google?

I think the proposed change could potentially cause developers to keep multiple fragment screens in memory. And memory >>> CPU IMO.

For most screens layout inflation of a typical homepage is instant IF correct methods are used. If your homepage is extremely complex (custom views, graphics, nested layouts) you CAN do lazy view inflation but in practice I think such a layout is rare unless you are making a game or something. It's not the job of this library to keep views in memory if you so desire...

Maybe Google will change their mind in the future but doesn't seem like it...