Today, We will learn about the hidden costs of hiding fragments over replacing fragments.
Recently, I found an issue with following code in one of my sample project so, I have decided to share it with you.
What happens when we call
hide on any
fragment transaction :
- It hides an existing fragment.
- It will cause the
view to be hiddenfor the
fragmentwhose views have been added to a container.
- It triggers the
onHiddenChanged(hidden: Boolean)method on
It just hides the views, fragment is still in
How it can effects the performance of the App :
- Let say you update
Textview’s textby observing
ViewModel,then It will keep sending the changes to the UI because
As you can see
MainFragment is not
visible to the user but instead of replacing it with
SecondFragment we call the
hide on fragment transaction which just hides it’s view. It’s still in
RESUMED state and keep sending the updates to the UI
- As we discussed because fragment is still in
RESUMEDstate that means it keeps the
all the resourceswhich leads to memory leaks/wastage issues.
Ex : ViewBinding’s stay alive and keep the references to all it’s views, resources, etc.
- In small application with 1 or 2 fragments it might doesn’t show the impact at large scale, but imagine if you have app with
100+ fragmentsand you just
hide the current fragment and add new fragment on top of it. It will ultimately leads to
memory or resource consumption.
- Pop the last fragment transition from the manager’s fragment back stack
- Pop the top state off the back stack.
- It is asynchronous — it enqueues the request to pop, but the action will not be performed until the application returns to its event loop.
- Check the logs when
POP BACK STACKpressed, you can see that it triggers the
MainFragmentwhich sets the visibility to
Overlapped content issue :
At some point, If you want to load full screen fragment then you can load it to
android.R.id.content instead of adding it to existing container but at this point in existing container(
RESUMED fragment is still accessible although it’s overlapped by fragment which is added to
As you can see in the logs
fragment which is
Tricky solutions to fix this behavior :
- You might do the trick to
add background colorto the top most
fragment’s layout’s parent tagso that
not be visiblebut any
random click on UIcan put you in a situation where you don’t expect to be.
- Set the
parent tag of fragment’s layoutwhich is loaded into
android.R.id.contentso that any clicks on screen can’t go beyond it’s content.
Recommend solution to fix this issue :
- Before loading the fragment into
backStackso that only
- hide all the previous fragments because
2 different fragmentsare in
2 different containers
So whenever you are handling multiple fragments you need to be careful to make sure that you are not wasting resources and also at particular instance only required content is visible, not something which is not important or relevant to the current flow.
It’s totally up to you whatever works(hide/replace) for you go for it.
😊😊 👏👏👏👏 HAPPY CODING 👏👏👏👏 😊😊
Stay in touch
navczydev - Overview
Android Developer Organizer at GDG-Montreal. navczydev has 86 repositories available. Follow their code on GitHub.
Nav Singh - Writer - Medium | LinkedIn
View Nav Singh's profile on LinkedIn, the world's largest professional community. Nav has 7 jobs listed on their…