Using Support library 27.1.1. I have a NestedScrollView with BottomSheetBehavior. Inside the bottom sheet layout I have LinearLayout with a header view at the top, then a RecyclerView at the bottom. The RecyclerView is populated with 10-20 custom views with heavy onDraw methods.
The whole idea of having a RecyclerView was to avoid inflating these views, as they are quite heavy to render. I want these views to render as soon as they are scrolled into view (dragging the bottom sheet header). The problem is that all children of the RecyclerView are inflated/rendered immediately. I thought I could stop this from happening using a custom LinearLayoutManager but haven't succeeded thus far.
There are a few sources on the net, discussing this particular problem. However, in my case there are a few things that change the conditions.
The RecyclerView is used along with the BottomSheetBehavior. With a height of 0dp the sheet cannot be opened!
The height of the custom views is known to be half the view width.
Support Library 27.1.1 or later is targeted (most discussions on the net consider v23.2).
Q: Is it possible to get the RecyclerView to recycle its views when put inside a NestedScrollView with BottomSheetBehavior? Or would it be easier to somehow prevent the heavy onDraw in the child views?
Related
Here is what I am trying to achieve:
Link to google's material design guide
In my case I have multiple cards in a scrollView, which contains a linear layout. I did not use a recycler view because the number of cards is always about the same (below 10). One of the cards contains two recyclerviews showing a list of for example comments. The problem is that I can't find a way to disable scrolling of the internal recyclerview without causing it to not scroll at all and show incomplete data.
Thanks for your help!
Use a NestedScrollView and put your RecyclerView inside it.
If you wish the RecyclerView to become a scrolling part of your NestedScrollView, set nested scrolling to false.
NestedScrollView nestedScrollView = findViewById(R.id.myNestedScrollView);
nestedScrollView.setNestedScrollingEnabled(false);
If you want an independent scroll you don't need to do anything since nested scrolling is set to true by default.
This is a question regarding the use of Android Transition API.
I am trying to animate the height change of a list, just like a dropdown menu.
I tried 2 approaches
Use a RecyclerView and animates its height change
Use a ScrollView > LinearLayout hierarchy and animates ScrollView's height.
The 2nd approach works perfectly.
But the 1st approach has a serious glitch - when the collapse transition starts, items disappear immediately.
By looking at the below GIF you can observe clearly the difference:
To be exact, items' visibility changes at the moment I change RecyclerView's LayoutParams, without waiting for the transition to finish, whatever it is expanding or collapsing
Code
I have created a minimal project on Github.
If you just want to look at the code, here is the MainActivity.
Question
Is it possible to achieve ScrollView's effect with a RecyclerView?
If yes, how?
My Idea is to do the transition of all the recycler view rows individual rather than the whole RecyclerView:
So when collapsing iterate through each ROW of a RecyclerView and do a transition. Remember to check for null if some rows are recycled they may return null. So after that collapse the whole recyclerView.
And like wise for the expanding do the same for the views.
This issue is cause by RecyclerView has many views with it but Scroll View has only one View nested in it.
Structure of my Android app is forcing me to create Vertical Nested RecyclerView inside Vertical Nested RecyclerView because of the pre-drawing all nested items inside every RootRecyclerView. The View of RootRecyclerView has approximately 5 - 10 views and the View of InsideRecyclerView consists also from 5-10 views. There is not necessarity for scrolling this ChildRecyclerView, because all scrolling is handled by RootRecyclerView (same term as Nested RecyclerView)
I have two options:
1. ChildRecyclerView, that will predraw all child items when the root item will reached the screen (it lags, but the result looks good under the 30 child rows)
2. Join the Root+Child View, remove Child RecyclerView and the all logic will be handled in the Root RecyclerView. - i tried this, also used ConstraintLayout, so the whole layout was only 1-LEVEL, but it was still laggy, even if I set Visibility of half of the views in this layout. I also setup setHasFixedSize(true), tried to use Cache methods of RecyclerView, initialCacheItemSize and so on.
So do you have any ideas, how to solve this problem? Did somebody of you met with this kind of problem? You could also imagine the case of ChildRecyclerView inside another ChildRecyclerView that is inside RootRecyclerView.
I have a ScrollView that contains several other views and I would like for one of these views to be a grid of other views having the same layout (e.g. ImageView).
Since having one scrollable view inside another is not recommended, I would like this grid view not to be scrollable, otherwise I would have used GridView or RecyclerView.
Surely I can place the grid views inside one of the standard layouts (e.g. TableLayout) but this may cause memory issues when many grid items exist.
Is there any standard approach or a library that allows to recycle views for a non scrollbale view inside ScrollView?
If you try to force GridView or RecyclerView to be non-scrollable (so basically you would have to force the dimensions of the view to display all the elements) you will end up in the same situation as if you used TableLayout (so you would need to watch out for memory issues).
If you disable the scrolling of scrollable (recycling) elements like GridView/RecyclerView you disable the most important part that makes those things work efficiently (that makes those things reuse their views).
The way you should solve your issue is to implement your other Views of your ScrollView as a part of the RecyclerView. Your RecyclerView should be equipped with the adapter that can inflate multiple types of Views (you can read about it for example here).
Since you are using RecyclerView you could use NestedScrollView instead of ScrollView They should play more nicely since RecyclerView extends from NestedScrollingChild and NestedScrollView extends from NestedScrollingParent.
Other views you can use are VerticalGridView or HorizontalGridView but as you said you are worried about performance issues and you can provide a GridLayoutManager to the RecyclerView I would stick with that.
I'm developing an app that has an UI pretty similar to Play Store. It is organized as a multiple panels one above another. First it has a panel containing a photo. Under that it has another panel containing some text and a custom background color. Under that it has another photo and finally it has a Linear Layout with vertical orientation containing a pretty long list of little views filled dynamically at runtime. I have all this inside a Scroll View, naturally.
The problem? That dynamic fill of the linear layout takes a long processor time and makes my app unresponsive during those inner views inflation. So I thought to replace the linear layout by a Recycler View. And the performance is awesome!
So? Well... Not everything is so awesome. I can't scroll the Recycler View because it's inside the Scroll View. And if I remove the Scroll View then I can't scroll the entire view (some things doesn't fit on the screen).
What's the best approach for fixing this?
It's not recommended to use a RecyclerView or ListView inside of a ScrollView precisely due to the double scrolling issues. RecyclerView is very robust and is prepared to receive headers, footers, etc. I see no reason why the entire layout could not be inside of a RecyclerView instead of a ScrollView
The ViewHolder implementation can include logic to inflate different layouts depending on what section should be next.
Pseudocode:
i.e.
if(currentAdapterItem == sectionA){
useLayoutA();
} else{
useLayoutB();
}
Just use a NestedScrollView instead of a normal ScrollView. It handles the nested scrolling quite well.