Following will be the layout in my app
So I am considering of using recycler view. There will be a parent recyclerview, I which I will define different view types for each section e.g, viewpager, horizontal block etc. Depending on view types, different viewholders will be created. Horizontal block will be displayed in horizontal recyclerview. For grid there will be a recycler view in another viewholder. The data for each section will be loaded from a different API. Means the first API will only give metadata, using that metadata, another API will be called whose data will be used to populated in the blocks.
My question is whether is this a good approach to have a parent recycler view, define view types and have other recylerviews inside view olders. As I am nesting recyclerview in other recycler, so should this approach will be fine wrt performance or there is some other way to implement such design.
I am using recycler view as it will be easy to implement pagination.
PS: I am not using linear layout as implementing pagination on linear layout is a bit tricky. I find it more easier in listview/recycler view. Also the sections like list/grid as shown, are dynamic one and there is no fixed number that they will be upto 2 or 5. It can be upto n. So, with linear layout, I have to add all sections in loop which will be overkill if the no. of sections quite large.
Related
I am using a recyclerView, with a GridLayoutManager layout.
The recycler view contains 2 types on ViewHolders, one having span size equal to 3 in order to separate different types of grid elements and one of size equal to one.
What i want is to be able to hold always on the top one of the view holders of the size 3 (depending on the horizontal scroll position), like shown in the image below.
Does anyone has any idea how to do it? If it is possible i would want to avoid to create a custom layout, is there an easier way to do it?
grid layout exemple
You can check this github project
StickyHeaders
You can use directly this and import it as a dependency or you can look at the code and try to implement your own "sticky" header.
Am trying to create a page with a scrollable list. Features would be a normal list to remove item by clicking on it. Number of items in that list are limited and added dynamically by user. You can consider a to do list as example. Now which would be a better approach to implement it? Recycler view with data bound to its adapter? Or the normal linear layout with items added as children at run time?
My current implementation is recycler view. But,I found it lagging and animations are not performing well. So a linear layout is auto animated by specifying it xml -- by setting animate layout changes to true.
FYI data is local and syncs in background.
Never use a LinearLayout for anything longer than a single screen. The whole point of ListView and RecyclerView is to efficiently reuse views instead of needing to hold things in memory when they're not visible. Maybe you can refine or reask your question so people can help you with whatever difficulty you're having with animations, rather than avoiding the issue.
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.
My assignment is to create an interface much same like Google Play Store.There will a Category name followed by 3 or 4 cards (horizontal) followed by More button. Then again next category.
I already had implemented this using nesting the horizontal listview inside Vertical listview.
I know, I can achieve this by using the Recycler view with LinearLayoutManager with horizontal orientation. Using this I'll be having one only row.
My question is how do I add 2nd, 3rd row to this?
Should I use again nested Recycler view?
Are there some better options?
Dont use nested listviews (you cant scroll horizontally in play store).
Consider the following options:
You can use a simple LinearLayoutManager and make different view types. For the with 3 cards horizontally use a GridLayout or LinearLayout with same weights. The problem here is, that you have to consider the indexes of your underlying data list used in the adapter
Write your own LayoutManager for RecyclerView
Use TwoWay View which is based on RecyclerView and offers a Spannable Grid Layout manager, which seems to be what you are looking for.
If you inspect the layout of the Google Play app, they do not use a listview/recyclerview for the horizontal cards. I'm pretty sure that is just a linearlayout (horizontal) within a vertical listview / recyclerview.
If you insist on using a horizontal recyclerview for each row, then having a nested recyclerview would be your best option. You can specify a RecycledViewPool so that all the nested recyclerviews share the same pool instead of creating their own.
You may like to do it as one vertical RecyclerView (Main recycler) and for every section you can inflate a horizontal RecyclerView as well (Section recycler) as this blog answer mention:
Also, consider using:
A cache layer for Bitmaps for persistent access through your other store screens
A lazy load method for your category/section images
A place holder before showing new items
I'm making a GUI with two different parts. The first part (at the top) is composed of some banners, several fixed buttons. So I think using LinearLayout is the most straightforward way to implement. The second part is composed of several similar items grouped together which can be implemented by using ExpandableListView, I think.
However the problem is that the content exceeds the screen size. So I intend to put two of them into a ScrollView. I checked several sources, it seems that putting "ExpandableListView" inside a ScroolView is NOT possible, or not efficent, so I'm afraid...
Would you help to confirm if this is possible? efficient ?
If no, would you give me some recommendations for this layout design?
I'm indeed looking forward to your supports.
Sincerely.
If you have a fixed header at the top of a list, use ListView's header view feature.
Putting ListViews in ScrollViews fundamentally makes no sense and here is why:
ListView has one purpose: to efficiently display unbounded data sets. Since these can be extremely large (tens of thousands of items and more) you do not want to create a View for each item up front. Instead, ListView asks its Adapter for Views only for the items that currently fit in the ListView's measured space on screen. When an item's View is scrolled out of sight, ListView disconnects that View and hands it back to the adapter to fill out with new data and reuse to show other items. (This is the convertView parameter to an Adapter's getView method.)
ScrollView also has one purpose: to take a single child view and give it "infinite" vertical space to fit within. The user can then scroll up and down to see the full content.
Now given this, how many item Views would a ListView create for a 100,000 item Adapter if it had infinite height available to fill? :)
By putting a ListView inside a ScrollView you defeat ListView's key purpose. The parent ScrollView will give the ListView effectively infinite height to work with, but ListView wants to have a bounded height so that it can provide a limited window into a large data set.
Well Expandable List View itself has scrollable property by placing it in scroll view is really undesirable.As the both scroll would contradict and smooth scrolling can't be obtained in that case..
If we have any data to be shown prior or later to list...
Best way is to use header and footer view to list...
I recommend you use header and footer in your case.