I use a BottomNavigationView for switching between fragments. The problem is that my first view has a webview included which is quite CPU heavy. I implemented a caching mechanism which holds my fragments in the backstack. Whenever i switch to a fragment, my app searches for the fragment and if it is not initialized, it creates a new one. So when i switch from the first to the second fragment or vice versa, my transaction animation is not really shown and it lags a bit.
Do you have any idea how I can make it perform better, or how I can prevent the lag, and make a smooth transition between those fragments?
If you don't care about visual delay, you could postpone the webview's loading with
webview.postDelayed({
//loading goes in here
},200)
Related
My main fragment has too many views to load because the lines of code in the file are increasing. To avoid this I decide to separate views using a child fragment. So now upper views are in the child fragment and the remaining bottom views are in the main fragment. Till this ok.
Now I am opening a new fragment by clicking one view from the main fragment. When I came back to the main fragment it is reloading the child fragment because of that I am getting NullPointerException and the app crashed.
Following is the way I am adding child fragments.
childFragmentManager.beginTransaction()
.replace(R.id.fragment_container, fragment)
.commitAllowingStateLoss()
For more understanding.
I am using Navigation with BottomNavigationBar.
How to avoid this?
In some cases, fragment views are flickering when back to that fragment. How to avoid that?
For your first question you want to avoid putting the fragment in the backstack.
childFragmentManager.beginTransaction()
.replace(R.id.fragment_container, fragment)
.addToBackStack(null)//<-- Here
.commitAllowingStateLoss()
For your second question Fragments are destroyed to conserve memory,typically happens when you can't see it. As such the recreation process could take some time, depending on how heavy the view is, thus the blinking.
The only way to stop it from blinking is to make sure the Fragment isn't doing so much that it can't seamlessly load back in.
You could do this by lazy loading your more heavy views, like lists, videos, and large images.
You could also look into Fragment transitions. These could visually smooth out the process of loading.
Here is a great source for some standard animations.
Fragment transaction animation: slide in and slide out
When using a fragment transaction we can do them using add and replace methods. If we use add, the previous fragment is not destroyed and kept in memory. And if we use replace the previous fragment is destroyed and recreated again when we go back. From an optimum (memory, cpu, etc) perspective what is more effective/better?
I've created a simple app that is capable of replace or add a fragment, you can find it here.
Following the android documentation I've used their tool to test the performace, those are the results:
By adding the fragment the usage of the cpu peaked was 17%
By replacing the fragment the usage of the cpu peaked was 23,3%
If you are talking about memory usage, then replace is better than add, because in add() the fragments's (which are in a stack of fragments) views are in memory, and all the images and views are taking memory, which is not released. Suppose you have 5 fragments A, B, C, D, E. You have added them one by one A->B->C->D->E Now E is at the top and all fragments A, B, C, D have their views and resources loaded in the memory, Suppose these fragments have a lot of heavy images, then there are chances your app may face out of memory. But If you use replace for each of them, their views are released so their resources are released (which is good, as these are no more visible to the screen, so should not hold resources, images and memory).
For more information, Google has introduced Jetpack navigation https://developer.android.com/guide/navigation
In this when fragments navigate from one to another, replace is performed.
The only thing required in case of replacing, is you need to handle onCreateView() properly so when the user comes back to destroyed fragment, Its views are populated again.
It depends on your scenario. Replace seems as better option generally because creating a new hierarchy doesn't cause a performance downfall and it releases its view hierarchy without destroying fragment instance if you save it to your back stack. However, there is some cases you should be aware of for example: you create a view like map view. It takes much time to create a view from scratch so you should keep that view in memory to prevent creating the view again and again user backs to this fragment. However if your memory starts to reach it bounds you should take care of it like destroying the fragment by using memory callbacks.
Most of the cases, replacing fragment is better option. You can see what happens when you add your fragment to a container without replacing previous one by not setting a background to your fragments.
As summary if your fragments take so much time to create its view hierarchy, you keep the view hierarch by transactions of show and hide not adding each fragment top of another. But if the fragment has a lightweight view hierarchy to create replace it.
I have a fragment that has a viewpager, let's call it fragmentA. I use a FragmentStatePagerAdapter for this. The problem occurs when I am replacing fragmentA with another fragment. For some reason, it causes the app to kind of lag for one or two seconds before actually committing the next fragment. The animations are also not run. I am thinking that Android is destroying the inner fragments before replacing it, and the inner fragments have lists in them which causes the app to lag. Is there a way to work around this?
It all depend on the speed and RAM of the device. The viewpager will have to poulate all its children before displaying on the screen. As a result, lag on some devices
I have an app that initially displays one fragment, when a button is clicked it transitions to the next fragment. However inside the 2nd fragment there's a ViewPager that holds images from a URL. It can take some time to process all the images. And it is processing the images as the button is clicked which then slows down the speed the fragment gets set up, which takes a lot of time. I want the fragment to be there and prepared instantly.
I can fetch the images in the mainActivity. I however cannot set them to the ViewPager before the fragmentTransaction is committed because the ViewPager doesn't exist until the onCreateView method occurs in the fragment which is only called when the transaction is committed. Is there any way to have the fragment set up in the activity before I commit the transaction.
So the user can easily switch between the two fragments without having to wait for them to process. Or should I have rather used tabs. The thing is I don't want a tabs bar to appear at the top of the screen. I want the tabs to change when by button is clicked.
It sounds like you're processing the images in the main thread? I think it would be best if, instead, you just pass the URL to your second fragment and have it use a Loader to process those images in the background, with placeholders for each image as it's getting loaded.
If you insist on doing the loading in the first fragment, you should just be able to set up and add your second fragment without any images, but have it be hidden. Then, once your loading is complete, you will still have access to your ViewPager from your first fragment and can use another transaction to show the second fragment when ready.
P.S. it would be easier to read/understand your question if it was laid out more logically and not a huge paragraph.
After spending a fair bit of time figuring out that the reason my fragments chosen from a drawer layout weren`t displaying sometimes due to the choreographer skipping frames (I was using transaction.replace rather than show/hide) it made me wonder -- what are the situations where one would want to use replace rather than show/hide or detach/reattach? My problem went away when I switched to using show/hide btw.
Taken from this thread I got this on what happens when you call FragmentTransaction.replace():
Android will effectively perform a sequence of
FragmentTransaction.remove(...) (for all Fragments currently added to
that container) and FragmentTransaction.add(...) (for your supplied
Fragment). Removing a Fragment from the FragmentManager will cause the
Fragment to be destroyed and its state will no longer be managed. Most
noticeably, when you re-add the Fragment all of the views will have
been reset. Note: since you are reusing the same Fragment instance,
the Fragment will still keep the value any instance variables.
and from this thread I got that it is probably better to show/hide rather than replace if you plan on using that fragment again. My question is, in which situations do you use FragmentTransaction.Replace()? The only place I could see it really being useful is for something you know you won`t need again, kind of like a dialog picker with options but I use dialog fragments for those situations.
Does anyone use FragmentTransaction.replace regularly, and if so, why did you choose that over another method? Cheers
It maybe useful, for example, when implementing a deep fragments hierarchy in Multi-pane pattern (when click on item in the right fragment moves it to the position of the left).
Also, since hiding a Fragment keeps it in FragmentManager, it maybe expensive if you have a heavy content in it or hide multiple instances. Calling remove() or replace() and properly saving fragment's state is more Android-way, I think.