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.
When you are working with a long, big list, certainly one should use ListView because it handles cell recycling.
Notice here, for example Can i use nested linearlayouts instead of list view, for a big list? the OP is asking about ListView verses a dynamic LinearList -- the answer is "have to use a ListView, because of recycling"
Now, say you are making a short list -- imagine say a popup with only 10 or 20 items. It may even fit all on the one screen, so there's no recycling.
In fact, is there any difference between using a ListView and just using a LinearLayout, and dynamically populating the little views inside it?
It seems to me that the latter is in many cases much simpler, more elegant, and easier to work with. But I could well be missing something that seasoned Android engineers know about.
Should I just use an ordinary LinearList (populate it dynamically) for lists where recycling is not relevant? What's the usual, and why? Cheers!
{Incidentally, for popup cases, is there some better, lightweight method for "choose one from a popup-list" that I'm too silly to know about?! :) )
ListView(and other lists) supports very useful idea: splitting data and view. These parts could be changed at any time so it's important to support flexibility. And it could be solved by special mediator object: Adapter. Adapter roughly speaking says how to fill your view with particular data item.
So I'm sure that if you decide to use LinearLayout sooner or later you will implement you own Adapter.
If you used dynamic linear view then rendering the view will take more time as compare to listview. In listview we are rendering views which are visible only but if you used dynamic linear view then its problem.
I'm building a contacts app and wanted to know what the best way of building something like the image below(Jessica is not too shabby...) in terms of using a list view, scrollview, etc.
Ideally, all of my data is in the sql database so a cursor adapter wouldn't be an issue. Is it better to have a listview with separators, or a scrollview where you add views. Since all contacts won't have exactly the same information, what can we do to make that? Any ideas would be greatly appreciated.
If you plan to have interactive elements inside of the items (e.g. the message button in the screenshot above) I'd recommend a ScrollView. Actually, since you probably don't have that many items I would again recommend a ScrollView. Then it's justa matter of having a set of layouts that you dynamically add depending on the information you have for the contact.
I have a RelativeLayout with different elements. I was planning to have two ListViews on it, but I have noticed there are some problems with scrolling. Since each ListView only shows a maximum of 5 rows should I try to make some kind of custom adapter to merge those ListViews? Or is it better to replace the ListView with a LinearLayout/RelativeLayout and add the rows as I get them manually? (like the first answer in here: android listview display all available items without scroll with static header ).
Which should be the proper way on doing this? or is there another way? Also, each row will have an OnClickListener.
There's two solutions if you'd like to keep your list... list-y, without having to prerender all the row Views like the above solution suggests (which can be slow to render, eats RAM and doesn't scale nicely to more than a screen or two of Views, but is a fine quick solution for smaller lists, though I'd just use a bunch of Views in a LinearLayout in a ScrollView rather than a ListView in that case).
Write a custom ListAdapter, overriding getItemViewType, getViewTypeCount and GetView to inflate the proper kind of view and recycle appropriately for your two types of views. You'll also either need to override getItem to contain custom logic for figuring out which set of source data to look in and to map the data accordingly, or mush the data down into one list of Objects (if you're using an arrayadapter) and cast in the getView method (probably a bit slower than handling it in the getItem without casting).
Just use cwac-merge, a view-and-adapter wrapping adapter. You can put two ListAdapters into a MergeAdapter and set that as your single ListView's adapter.
I had problems with scrolling. I never figured out how to have the ListView share vertical space with a different View, and have a single scrollbar for them both.
I worked around it by having everything that needs to scroll on the layout a row in the ListView.
Adding views as rows to a LinearLayout may have problems scaling up, but I think you'll be OK if you only have 10 rows in total. On 1st gen Android devices it'll probably start to get sluggish around 20 items (depends on Layout complexity obviously). ListView scales up by only inflating views as they come on screen.
So in answer to your question either of the two alternatives you suggest will be OK, but the LinearLayout option will be the easiest to code.
I'm trying to tackle a problem that seemingly many Android developers have, which is how to intersperse lists with non-list data, in one big scrollable pane.
The model I have in mind is the screen for an individual app in the Market. You have a big description, a list of a few lazily loaded comments, and then some individual items that do different things, like visit the developer's web page, call them, etc. And then in between them all, are nice section headers.
Emulating this approach seems to be extremely hard. I've read enough SO answers and mailing list posts to know not to put a ListView inside of a ScrollView, but I want the same effect without using addHeader() and addFooter() with very complex header and footer views.
I've tried using a LinearLayout that I stock with views myself, but I can't get the pleasant click effects that default list items have (the orange background, white for long-click, etc.).
What do I do?
Take a look at my MergeAdapter, which is designed to handle scenarios like this.
Why not use a header? It's easy. Define the header contents in a separate layout. Your activity layout contains nothing but the ListView that you want at the bottom. No scroll view!
Then call
View headerView = getLayoutInflater().inflate(R.layout.header_layout, null);
ListView listView = (ListView) findViewById(R.id.my_list_view);
listView.addHeaderView(headerView, null, false);
It's crucial to call that form of addHeaderView so that the header is disabled. Otherwise, it can be selected, which looks totally weird.
Mark's example would work. basically you need an adapter with different view types. Another nice example is
http://jsharkey.org/blog/2008/08/18/separating-lists-with-headers-in-android-09/
which might work better than Mark's because you want to have separators and group things together.