Should I use NestedVerticalScrollview Android with 1000 child view?
Generating views in Android is generally fast, but if doing it a lot, it can get expensive. Depending on the complexity of your itemView, this could get very expensive when scrolling in your case. Unless you use a RecyclerView, whenever a view goes off screen that View will be destroyed, and each new item revealed by scrolling would have to be created anew. RecyclerView performs a recycling process on these views, so if each itemView has the same layout, it can reuse past views to present new information, thereby saving the time required for creating the view.
In your case, it sounds like all 1000 views would be created upon creation, which would probably take a fair amount of time to create the activity/fragment, and is a waste of resources, since only about a dozen could likely be displayed at any one time.
I suggest two things:
Use a RecyclerView in place of the NestedVerticalScrollView. Here is the official android codelab for RecyclerView in java. I'm sure you can find a kotlin version by search, if you're coding in kotlin.
If your itemView (in recyclerView terminology this is a ViewHolder) is complex (aka nesting), use a constraintLayout within your ViewHolder. If it is a simple layout, you may use a LinearLayout, or if that does not provide the layout you desire, RelativeLayout. Even if you are just creating one TextView, you should use the ViewHolder pattern required by RecyclerView.
You could test out the performance of your scrolling behavior manually to see if you experience lag when scrolling in a ScrollView with a 1000 child views. I suspect you would, even with the most basic itemView.
Also, do not use a RecyclerView within a ScrollView, this will not work well (as explained in the RecyclerView docs I linked in the first link above.)
Related
I am trying to achive this:
First I tried by putting all my recyclerviews (with WRAP_CONTENT) inside a nestedscrollview. That worked, but the performance was awful. Then I tried to set a height for my recyclerviews, that was a lot better (especially the first gridlayout and the horizontal linearlayout loaded very fast), but still had the problem with the dynamic "category" part.
Now I am trying to put all my recyclerviews inside a single recyclerview with different viewtypes. Since that is a pretty big deal (I need to refactor a lot of code because I have diveded every area from the screenshot inside a single fragment and now I need to put all that code inside an adapter) I wanted to ask if I can actually expect any gain from this, because in the end its again a "nestedscrollview" (made by myself, but...). Or if there is some other "best practice" way to achive this layout.
Thank you
Edit:
As expected this didnt do the trick neither. When just the two first recyclerviews are added as viewtype it scrolls and loads smoothly. But as as soon as I try to add the category items (below the category), I notice a lag and especially when selecting multiple categories and scrolling fast up, there is noticable lag. I guess I will have to change my layout and move the category selection part inside a separate view, just need to come up with a user friendly solution. But its acutally quite dissapointing that, in my opinion such trivial task, laying out multiple tables, is such a pain in the ass on android.
I didn't manage to get it working with standard android stuff.
Now I am using epoxy from airbnb ,and I have converted all my views from nestedscrollview to the epoxy recyclerview. Its a great library, and airbnb use it too for all their views.
Nevertheless it's sad that the android dev team doesn't address this problem and provide a solution besides the info "don't nest multiple scrollviews(recyclerviews) that scroll into the same direction".
You can use Recyclerview in recyclerview.
https://irpdevelop.wordpress.com/2016/02/10/horizontal-recyclerview-inside-a-vertical-recyclerview/
And make sure to use multiple view types.
This is not a design question, I have the item designed. I am confused on how to pull it off.
I am tasked with designing a view for Android that has a view of a user's post and the comments under it. The post contains some extra information and widely different design from the comments, but all of them need to scroll in tandem, like a web page would (Oh, how I am spoiled by my years of web dev...).
My current solution is to nest a LinearLayout (at the top of the view to contain the user's post) and a RecyclerView (below the post to display the comments) inside a vertical ScrollView. The information is actually displayed, but the RecyclerView, of course, scrolls independently of the LinearLayout above it and ruins the functionality of the view.
I wish, if possible, to keep the RecyclerView in use
The best case scenario would be to have the LinearLayout with the post scroll a certain amount, and then the RecyclerView take over. However, I don't want to poison my codebase with 200+ ugly lines of code to achieve this, so if this is a laborious task to complete, I would rather look for alternatives.
The first thing to understand is: do you really need a RecyclerView, or even better, do you really need recycling?
If the answer is yes, the way to go is two different item types in the RecyclerView's Adapter (for more details, see here or here). This concept was already present in the ListView: the main difference is that RecyclerView enforce the use of the View Holder pattern. It is not so complex, and, more importantly, is the way the RecyclerView is supposed to solve that problem. Depending on your UI design, you may also want to have different view types for different types of comments (plain text, images, ...). Remember that, when the RecyclerView is included in a ScrollView, the recycling won't work, because all the items in it will be drawn at once to compute the height of the content of the parent ScrollView.
If the answer is no, then you could just create your views at runtime and add them to a parent LinearLayout in a ScrollView. It is really nothing more than a for loop.
A more fancy approach would be to use an ItemDecoration for the user's post, but I don't see any specific advantage in this case.
I want to implement a schedule-like overview as List and as Grid View. Currently this works using a RecyclerView and swapping out the LayoutManager at Runtime. This works fine in general, but as soon as I tuned the grid cells to have a fixed height, I realised that the RecyclerView does not respect the wrap_content layout property and instead introduces whitespace between my grid items.
I then stumbled over more or less the same question for the linear LayoutManager and the third-party provided specialisations of the LayoutManager. A quick searched revealed nothing similar for the GridLayoutManager and I am beginning to suspect I am going down the wrong road:
Apart from the easy switching between layouts, there seems to be no reason for me to work with a recycler view:
I dont't require any special animation stuff.
My adapter returns a fixed list without loading more items on demand.
Actual recycling of items doesn't even take place.
So I am currently evaluating to simply switch to separate Fragments using an ordinary ListView and GridView. But this does feel a little like working against the intentions of Android ... After all, they introduced a single view that (in theory) should exactly do what I need.
Am I missing something obvious that could turn out to be painful when using those "legacy" Views to get the job done? Or are there maybe other, more specific Views that allow switching from linear to grid layouts apart from the RecyclerView?
If this should be of importance: I am using Xamarin.Android, not native Java. But I would be willing to port some code from Java to C#.
Follow this ticket:
https://code.google.com/p/android/issues/detail?id=74772
It is not merged yet but soon should be merged and WRAP_CONTENT support should be available in the next version (23.1.1+) or the one after.
I have successfully followed the tutorial on RecyclerView here.
but I was wondering if I could build more complex behaviour using Fragments inside the RecyclerView instead of plain old Views.
using fragments can help make a reusable item with complex behaviour that can be placed in other places and can be much more flexible.
Is it possible and if so , how ?
RecyclerView is for a view that repeats a lot with different data, it's designed for use in long scrolly lists because inflating (constructing) the View Object takes some effort, so recycling takes the View you just scrolled off the top of the screen, quickly fills it with new data and puts it at the bottom.
I wouldn't have thought using a Fragment like that would work well, whenever you scroll the list it'll need to be re-created and run its various setup methods which will be quite expensive. And if you make it so it doesn't have to do that (setRetainInstance()) then you're not getting anything from it that you wouldn't get from a view.
If that's what you're getting at then yes you could create a Fragment, set it up, mark it as retained and keep a reference to it so it hangs around in memory for you to re-attach to some other parent at some other time. But if you have to change its contents and re-build it then you're not gaining much.
Do we get any benefits of implementing a ListView for which every item would have different layout? Would it be a better idea to put those items into ScrollView with LinearLayout instead?
Intuitively, it seems like using a ListView may still give better performance, though it might be negligible depending on the size of your content. Because the ListView inflates the views as it needs them, it seems like you might save some time by not parsing/rendering views that a user might never see. A long ScrollView with a bunch of views inside seems like it would take additional time when first launched, since the view hierarchy is more complex.
I do think Michael is mostly correct though, that the main advantage of a ListView is that views are reused, which saves on memory/processing. Unless you have a ton of content in the ScrollView, I suspect the performance difference is not significant, and will almost definitely be more complex -- in particular, having to create an adapter that knows how to create each view type for each row.
I don't understand why you may use ListView for this. Listview is a list of common data using the same layout if you click on it. Users depend on same/similar GUI patterns.
How about Sliding Tabs or the newer navigation drawer, link NavigationDrawer.
If you like sliding tabs, then I can give you more details.