I want to implement an ConcatAdapter like this image:
This page's recyclerView contains these elements:
Title
Horizontal recyclerView (with pagination)
Title
Vertical recyclerView (no pagination)
Title
Horizontal recyclerView (with pagination)
But the problem is I can set only one LayoutManager to recyclerView that holds ConcatAdapter as I know.
How can set different layoutmanager to each adapter?
Or any other solution to implement this page with CocantAdapter?
(Why ConcatAdapter? Because it sovle performance prblems of nestedRecyclerView even with recyclerViewPool as I know)
This unfortunately is not possible. A RecyclerView adapter is just a component to provide and bind views for each row. A ConcatAdapter is no different, it just redirects from the individual adapters.
If it did have any control over the layout managers it would really defeat the entire point of the modularity of RecyclerView, which is what makes it so powerful in the first place.
You can take a look at the source code here to find out more about how it is implemented.
Simple solution is to create a Viewpool in the Activity/Fragment.
The Adapter for the recyclerview has 2 different types of items,
The regular one and the other that actually has a recyclerview with the horizontal layout as Adapter in it.
So a Viewholder that holds a recyclerview inside with its own viewholders.
Then you just grab the created viewpool from the activity to assign it as the shared Pool to all of the adapters with the horizontal scroll, thats it :-)
Concat Adapter doesnt help with this im afraid so this would be my alternative solution
This question already has answers here:
Android Recyclerview vs ListView with Viewholder
(7 answers)
Closed 3 years ago.
I was reading about the difference b/w recyclerview and listview and found out that recyclerview is faster than listview.
I tried to search online but not found any satisfactory answer I know it is used ViewHolder pattern and Notifying adapter but what does it does intearlly so it is faster?
Recycler View you could say is an efficient way to create list of views.
If you have 1000 items like ur contact list , and If ur visible screen can show only 10 items at once, it will Create only 10+1 (or +2) Views and as u scroll , items/views that left will be reused (not create) to show new data.
Recycler View by default does this, where as List View by default doesn't do.
There are some differences between these two views.
ListView is a bit heavy and it has a lot of responsibilities. Whenever we have to handle the list, such as to configure it in some way, the only way to do this is through the ListView object or inside the adapter.
A lot of bad things in the ListView were fixed or changed in the RecyclerView. It’s more efficient by default, the layout is separated and we have more possibilities over the data set inside the adapter.
These are some crucial differences between ListView and RecyclerView:
1 ViewHolder
The ViewHolder pattern allows us to make our list scrolling act smoothly. It stores list row views references and, thanks to this, calling the findViewById() method only occurs a couple of times, rather than for the entire dataset and on each bind view.
The RecyclerView’s adapter forces us to use the ViewHolder pattern. The creating part (inflating the layout and finding views) and updating the views is split into two methods — onCreateViewHolder() and onBindViewHolder().
The ListView, on the other hand, doesn’t give us that kind of protection by default, so without implementing the ViewHolder pattern inside the getView() method, we’ll end with inefficient scrolling in our list.
2 LayoutManager
The LayoutManager takes responsibility for layouting row views. Thanks to this, RecyclerView doesn’t have to think about how to position the row view. This class gives us the opportunity to choose the way that we want to show the row views and how to scroll the list. For example, if we want to scroll our list vertically or horizontally, we can choose LinearLayoutManager. For grids, it is more suitable to choose the GridLayoutManager.
Previously, with the use of the ListView, we were only able to create a vertical-scrolling list, so it wasn’t that flexible. If we wanted grids on our list, we had to choose the other widget for that — GridView.
3 ItemDecoration
A duty of the ItemDecoration is simple in theory – add some decorations for the list row views – but in practice, it’s that simple to implement if we want to create a custom one. In this case, we should extend the ItemDecoration class and implement our solution. For example, the RecyclerView list has no dividers between rows by default and it’s consistent with the Material Design guidelines. However, if we want to add a divider for some reason, we can use DividerItemDecoration and add it to the RecyclerView. In case we use the ListView, we have to figure out rows decorations by ourselves. There is no helper class like ItemDecoration for this widget.
4 ItemAnimator
The last but not least component of RecyclerView that I want to mention is ItemAnimator. As we can expect, it’s handling row views animations like list appearance and disappearance, adding or removing particular views and so on. By default, RecyclerView’s list animations are nice and smooth. Of course, we can change that by creating our own ItemAnimator, which is also not that easy. To make it easier, we should extend the SimpleItemAnimator class and implement the methods that we need (just add animations to a ViewHolder’s views). To be honest, implementing animations on the ListView was a pain. Again, we had to figure out how we want to handle them.
5 Notifying adapter
We have a couple of cool notifiers on the RecyclerView’s adapter. We are still able to use notifyDataSetChanged() but there are also ones for particular list elements, like notifyItemInserted(), notifyItemRemoved() or even notifyItemChanged() and more. We should use the most appropriate ones for what is actually happening, so the proper animations will fire correctly.
Using ListView, we were able to use just notifyDataSetChanged() on the adapter and then had to handle the rest ourselves, again.
Because of ViewHolder Pattern.
Thats was the simplest answer. Now for some details.
What recycler view does is what it's name indicates "Recycle", yes it recycles items, and it does it with the help of ViewHolder Pattern.
By Using ViewHolder we do-not need to call findViewByID() every time we go through getView()method. The reference for all rows are stored in-memory. This increases the performance significantly, as findViewByID()is a heavy process.
Hope this clears your confusion.
I'm trying to make a android app with a scrollable list like this one...
When I made this app in iOS, I used a UICollectionView. What`s the best way to make this in android studios?
I tried using a list view, but I can't seem to customize it to my needs?
Any Ideas?
ListView was a great way to start and it is customizable to your needs.
However I would recommend to use RecyclerView which works almost on the same principle as ListView but it is a newer concept in Android. It handles the usage of the ViewHolder pattern for you which makes everything super easy.(With ListView, you would've had to implement your own ViewHolder pattern)
All you need to do is to have the RecyclerView in your activity/fragment as the view to hold your data. Then, the key component is to implement the RecyclerView's Adapter which will handle the inflation and setup of each list item.
Here is a really great and short tutorial to get you started with RecyclerView.
If you're done with that here is a bit more advanced video material on RecyclerView from Dave Smith explaining a lot of ways on how to understand and use RecyclerView in your apps.
A ListView fed by an ArrayAdapter of custom objects can do the job.
You might have a class that contains the text and the image of a single item.
Then you can create an ArrayList with items of that class, where you put in all the data.
This ArrayList can be used as dataset for a custom ArrayAdapter, which overrides the getView()-method.
The getView()-method must inflate the xml-layout for each item and attach the data from the ArrayList to the inflated view.
You might want to implement the Viewholder-pattern to achieve a good performance and avoid unnecessary inflations and getViewByID()-calls.
You can also use the new CardView, which can make it a lot easier, since it is made for the new material design in android 5, which looks similar to your item list.
So, Vogella seems to suggest that ListView is completely being deprecated in comparison with RecyclerView. And not actually deprecated, but rather that there is no situation in which ListView would be a better choice. Is this true? The commonsware book suggests that it might be faster at updating. Is there any other reason to completely avoid ListView from now on? Just reading through some examples, it seems that RecyclerView adds many layers of difficulty/convolution to the code, hence my desire to avoid using such unless there's a very good reason (animation isn't a superb-enough reason)
RecyclerView mechanism contains:
RecyclerView: A ViewGroup or Container
LayoutManager: Responsible for the layout and the arrangement of items, there are 3 built-in LayoutManagers, LinearLayoutManager, GridLayoutManager and StaggeredGridLayoutManager.
ItemDecoration: Custom item decoration, for example: DividerItemDecoration
ItemAnimator: Custom item animation
ListView = RecyclerView + LinearLayoutManager(Vertical).
RecyclerView mechanism can implement ListView, GridView, WaterFall... easily, and also can implement other custom views by custmom LayoutManager.
That is why we should use RecyclerView in the future.
I believe the listview will be phased out eventually, but you will always be able to use it. I use listviews in drawer layouts for example. since drawers usually dont have that many items in them to begin with, the viewholder pattern doesnt really apply. So its much simpler to use.
From android developer (Creating Lists and Cards):
The RecyclerView widget is a more advanced and flexible version of
ListView.
Okay, it sounds cool, but when I saw this example picture, I got really confused about the difference between these two.
The picture above can be easily created by ListView using custom adapter.
So, in what situation should one use RecyclerView?
RecyclerView was created as a ListView improvement, so yes, you can create an attached list with ListView control, but using RecyclerView is easier as it:
Reuses cells while scrolling up/down - this is possible with implementing View Holder in the ListView adapter, but it was an optional thing, while in the RecycleView it's the default way of writing adapter.
Decouples list from its container - so you can put list items easily at run time in the different containers (linearLayout, gridLayout) with setting LayoutManager.
Example:
mRecyclerView = (RecyclerView) findViewById(R.id.my_recycler_view);
mRecyclerView.setLayoutManager(new LinearLayoutManager(this));
//or
mRecyclerView.setLayoutManager(new GridLayoutManager(this, 2));
Animates common list actions - Animations are decoupled and delegated to ItemAnimator.
There is more about RecyclerView, but I think these points are the main ones.
So, to conclude, RecyclerView is a more flexible control for handling "list data" that follows patterns of delegation of concerns and leaves for itself only one task - recycling items.
For list views to have good performance you'll need to implement the holder pattern, and that's easy to mess up especially when you want to populate the list with several different kinds of views.
The RecyclerView bakes this pattern in, making it more difficult to mess up. It's also more flexible, making it easier to handle different layouts, that aren't straight linear, like a grid.
ListView is the ancestor to RecyclerView. There were many things that ListView either didn't do, or didn't do well. If you were to gather the shortcomings of the ListView and solved the problem by abstracting the problems into different domains you'd end up with something like the recycler view. Here are the main problem points with ListViews:
Didn't enforce View Reuse for same item types (look at one of the adapters that are used in a ListView, if you study the getView method you will see that nothing prevents a programmer from creating a new view for every row even if one is passed in via the convertView variable)
Didn't prevent costly findViewById uses(Even if you were recycling views as noted above it was possible for devs to be calling findViewById to update the displayed contents of child views. The main purpose of the ViewHolder pattern in ListViews was to cache the findViewById calls. However this was only available if you knew about it as it wasn't part of the platform at all)
Only supported Vertical Scrolling with Row displayed Views (Recycler view doesn't care about where views are placed and how they are moved, it's abstracted into a LayoutManager. A Recycler can therefore support the traditional ListView as shown above, as well as things like the GridView, but it isn't limited to that, it can do more, but you have to do the programming foot work to make it happen).
Animations to added/removed was not a use case that was considered. It was completely up to you to figure out how go about this (compare the RecyclerView. Adapter classes notify* method offerings v. ListViews to get an idea).
In short RecyclerView is a more flexible take on the ListView, albeit more coding may need to be done on your part.
The RecyclerView is a new ViewGroup that is prepared to render any
adapter-based view in a similar way. It is supossed to be the
successor of ListView and GridView, and it can be found in the
latest support-v7 version. The RecyclerView has been developed
with extensibility in mind, so it is possible to create any kind of
layout you can think of, but not without a little pain-in-the-ass
dose.
Answer taken from Antonio leiva
compile 'com.android.support:recyclerview-v7:27.0.0'
RecyclerView is indeed a powerful view than ListView .
For more details you can visit This page.
Following are few key points/differences between RecyclerView & ListView. Take your call wisely.
If ListView works for you, there is no reason to migrate. If you are
writing a new UI, you might be better off with RecyclerView.
RecylerView has inbuilt ViewHolder, doesn't need to implement our own
like in listView. It support notify at particular index as well
Things like animating the addition or removal of items are already
implemented in the RecyclerView without you having to do anything
We can associate a layout manager with a RecyclerView, this can be
used for getting random views in recycleview while this was limitation
in ListView In a ListView, the only type of view available is the
vertical ListView. There is no official way to even implement a
horizontal ListView. Now using a RecyclerView, we can have a
i) LinearLayoutManager - which supports both vertical and horizontal
lists, ii) StaggeredLayoutManager - which supports Pinterest like
staggered lists, iii) GridLayoutManager - which supports displaying
grids as seen in Gallery apps.
And the best thing is that we can do all these dynamically as we want.
Major advantage :
ViewHolder is not available by default in ListView. We will be creating explicitly inside the getView().
RecyclerView has inbuilt Viewholder.
Advantages of RecyclerView over listview :
Contains ViewHolder by default.
Easy animations.
Supports horizontal , grid and staggered layouts
Advantages of listView over recyclerView :
Easy to add divider.
Can use inbuilt arrayAdapter for simple plain lists
Supports Header and footer .
Supports OnItemClickListner .
I think the main and biggest difference they have is that ListView looks for the position of the item while creating or putting it, on the other hand RecyclerView looks for the type of the item. if there is another item created with the same type RecyclerView does not create it again. It asks first adapter and then asks to recycledpool, if recycled pool says "yeah I've created a type similar to it", then RecyclerView doesn't try to create same type. ListView doesn't have a this kind of pooling mechanism.
RecyclerView info
The RecyclerView was introduced with Android 5.0 (Lollipop). it is included in the Support Library. Thus, it is compatible with Android API Level 7.
Similarly to the ListView, RecyclerView’s main idea is to provide listing functionality in a performance friendly manner. The ‘Recycler’ part of this view’s name is not there by coincidence. The RecyclerView can actually recycle the items with which it’s currently working. The recycling process is done thanks to a pattern called View Holder.
Pros & Cons of RecyclerView
Pros:
integrated animations for adding, updating and removing items
enforces the recycling of views by using the ViewHolder pattern
supports both grids and lists
supports vertical and horizontal scrolling
can be used together with DiffUtil
Cons:
adds complexity
no OnItemClickListener
ListView info
The ListView has been around since the very beginning of Android. It was available even in API Level 1 and it has the same purpose as the RecyclerView.
The usage of the ListView is actually really simple. In this aspect, it’s not like its successor. The learning curve is smoother than the one for the RecyclerView. Thus, it is easier to grasp. We don’t have to deal with things like the LayoutManager, ItemAnimator or DiffUtil.
Pros & Cons of ListView
Pros:
simple usage
default adapters
available OnItemClickListener
it’s the foundation of the ExpandableListView
Cons:
doesn’t embrace the usage of the ViewHolder pattern
In addition to above differences following are few more:
RV separates view creation and binding of data to view.
In LV, you need to check if convertView is null or not for creating view, before binding data to it.
So, in case of RV, view will be created only when it is needed but in case of LV, one can miss the check for convertview and will create view everytime.
Switching between Grid and List is more easy now with LayoutManager.
No need to notify and update all items, even if only single item is changed.
One had to implement view caching in case of LV.
It is provided in RV by default. (There is difference between view caching n recycling.)
Very easy item animations in case of RV.
In my opinion RecyclerView was made to address the problem with the recycle pattern used in listviews because it was making developer's life more difficult.
All the other you could handle more or less.
For instance I use the same adapter for ListView and GridView it doesn't matter in both views the getView, getItemCount, getTypeCount is used so it's the same.
RecyclerView isn't needed if ListView with ListAdapter or GridView with grid adapters is already working for you.
If you have implemented correctly the ViewHolder pattern in your listviews then you won't see any big improvement over RecycleView.
I worked a little with RecyclerView and still prefer ListView.
Sure, both of them use ViewHolders, so this is not an advantage.
A RecyclerView is more difficult in coding.
A RecyclerView doesn't contain a header and footer, so it's a minus.
A ListView doesn't require to make a ViewHolder. In cases where you want to have a list with sections or subheaders it would be a good idea to make independent items (without a ViewHolder), it's easier and doesn't require separate classes.
You can use an interface to provide a click listener. I use this
technique with ListViews, too.
No divider: Simply add in your row a View with a width of
match_parent and a height of 1dp and give it a background color.
Simply use a StateList selector for the row background.
addHeaderView can be avoided in ListViews, too: simply put the
Header outside the View.
So, if efficiency is your concern, then yes, it's a good idea to replace a ListView with a RecyclerView.
Simple answer: You should use RecyclerView in a situation where you want to show a lot of items, and the number of them is dynamic. ListView should only be used when the number of items is always the same and is limited to the screen size.
You find it harder because you are thinking just with the Android library in mind.
Today there exists a lot of options that help you build your own adapters, making it easy to build lists and grids of dynamic items that you can pick, reorder, use animation, dividers, add footers, headers, etc, etc.
Don't get scared and give a try to RecyclerView, you can starting to love it making a list of 100 items downloaded from the web (like facebook news) in a ListView and a RecyclerView, you will see the difference in the UX (user experience) when you try to scroll, probably the test app will stop before you can even do it.
I recommend you to check this two libraries for making easy adapters:
FastAdapter by mikepenz
FlexibleAdapter by davideas
There are many differences between ListView and RecyclerView, but you should be aware of the following in particular:
The ViewHolder pattern is entirely optional in ListView, but it’s baked into RecyclerView.
ListView only supports vertical scrolling, but RecyclerView isn’t limited to vertically scrolling lists.
I want just emphasize that RecyclerView is a part of the compatibility package. It means that instead of using the feature and code from OS, every application carries own RecyclerView implementation. Potentially, a feature similar to RecyclerView can be a part of a future OS and using it from there can be beneficial. For example Harmony OS will be out soon.The compatibility package license can be changed in the future and it can be an implication. Summery of disadvantages:
licensing
a bigger foot print especially as a part of many apps
losing in efficiency if some feature coming from OS can be there
But on a good note, an implementation of some functionality, as swiping items, is coming from RecyclerView.
All said above has to be taken in a consideration.