Is it a good idea to make everything a RecyclerView in Android?
If you think about it, all scrolling UI could be composed with a RecyclerView with multiple viewTypes.
Is that a good or a bad thing to do?
Here is my opinion.
Apply RecyclerView with multiple take more code than ScrollView. If apply RecyclerView don't make any thing better (eg: performance) then I will not use RecyclerView
So I only apply RecyclerView when
- I have a long list (at least the number of list should > 6, because after debug I see RecyclerView default create and keep 6 views)
- Item in RecyclerView can reuse, example I have a list with 10 item but 10 item is completely different (eg: each item is a type) -> I will not use RecyclerView
- Sometime, I apply RecyclerView for the list which can expand in future. Example, I have a setting screen with setting option item, I apply RecyclerView here because I want to add new option item easier
There's a library called Epoxy by Airbnb that does exactly this. So clearly at least some people think it's a good idea.
Personally, I think that most UIs are easy enough to represent with just a ScrollView and some static views, and therefore the (admittedly not-huge) overhead of Epoxy isn't worth it. But it's certainly not a crazy idea. And if your layout is getting complex, then the overhead becomes less and less in relation to your overall codebase and so it could be worth it.
At the very least, this is one good way to avoid having to manually set up RecyclerViews that use multiple view types.
I'm currently researching why some of my RecyclerViews do not perform very well. The UI lags especially when the whole content of the view needs to be drawn.
Using systrace I've come across a large frame in which the RecyclerView layouts its views:
As you can see the same views are drawn repeatedly. Inside the systrace I've found the following description on the RecyclerView frame:
OnLayout has been called by the View system. If this shows up too many times in Systrace, make sure the children of RecyclerView do not update themselves directly. This will cause a full re-layout but when it happens via the Adapter notifyItemChanged, RecyclerView can avoid full layout calculation.
The views of my RecyclerView are using google's data binding with observable values.
Meaning to update a TextView I don't use textView.setText(titleTxt) but title.set(titleTxt) where title would be of the type ObservableField<String>.
So evidently I'm not calling notifyItemChanged but only update observable fields on objects bound to the layout.
Is it wrong to use data binding in this case performance wise? If so, whats the point of data binding then? Mobile UI consists largely of lists.
Unfortunately Google left data binding behind with the arrival of Kotlin, so if you think it is slowing things down like it did with me, just stop using it or move to Kotlin all together. Kinda sucks for us to try and work with things that are constantly breaking and being left behind, but that's just what Google decided to become.
I have a mix of 10-15 custom views and fragments to be shown in a vertical list. I am not sure if RecyclerView has any advantage in scenarios where all views are dissimilar. RecyclerView seems to add lot of boiler-plate code, and I think the only advantage I would get is easier enter/exit animation.
My custom views/fragment also make web-service call on being created. We don't cache web-requests for business reasons. My understanding is that RecyclerView would trigger these web-service calls on each binding, resulting in redundant calls and visible latency. Comparatively ScrollView should load the views once, and it keeps them all in memory, avoiding multiple calls.
Is my understanding correct ? I need some help understanding performance implications with ScrollViews, in the given scenario.
ScrollView
With a ScrollView, all of its subviews will be created at once, regardless of visibility on screen. If using a ScrollView for your solution, you'll probably want to "listen" for when its subviews become visible to update their content, using placeholders initially. You could also build something that will fetch the content in a background thread. This may get more complex than you want very quickly.
RecyclerView
A RecyclerView provides the advantage of deferring creation of child views until they become visible automatically, and can re-use child views with common layouts.
By using different "item view types" for each of your children, you'll disable the "recycling" part of RecyclerView, but still get the benefit of deferring the creation of views until they are scrolled into view.
RecyclerViews do provide a fairly structured pattern for you to work with via the Adapter and ViewHolders. Though not personally familiar with it, RecyclerView also has a RecyclerView.ViewCacheExtension which is intended to give the developer control over caching of views.
Overall, the advantage of late binding (don't create and load views that might never be viewed) and the flexibility of the RecyclerView will probably yield good results for you.
First of all you have to decide what you are using View or Fragment or maybe both. Don't compare View with Fragment there is a common misconception about these two, they are not similar, actually a Fragment is close to an Activity in terms of architecture and implementation.
Second, can you reuse some of these View/Fragment, if yes, then RecycleView can help you a lot.
After you decided about the topics above:
My understanding is that RecyclerView would trigger these web-service
calls on each binding
No, this is not true, the binding method is called whenever a new item is displayed (reused or newly created), you can implement adapter to perform the web API only once on an item, this is your choice.
I always go for RecycleView/ListView whenever possible, it helps to reduce the memory footprint and can reduce the implementation. In some cases, where there is no huge memory usage on views and I can't reuse some of the implementation, then I go for ScrollView, but I think twice before implementing it.
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.