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.
Related
RecyclerView is added into v7 support library since Android API 22 officially. And many people said that it is a enhancement over ListView and many brief introductions to the usage of it were posted over the internet. But most of these articles are very simple, shallow and hollow. The enhancement is just RecyclerView.ViewHolder, RecyclerView.ItemAnimator or RecylerView.SmoothScroller? Did the recycling and reuse mechanism of items' views during scrolling differ from the ListView's? And what exactly is the enhancement of RecyclerView over ListView?
Any answers, tips or links are appreciated. Thanks in advance.
And what exactly is the enhancement of RecyclerView over ListView?
RecyclerView is not an "enhancement" "over ListView", strictly speaking. ListView actually does something; RecyclerView, on its own, does not. A more accurate comparison would be that the RecyclerView framework is an improvement over AdapterView, and to some extent the AbsListView parent class of ListView and GridView.
RecyclerView focuses on widget recycling and gross child View management. It delegates everything else to other classes. AdapterView does far less of this, making it more difficult to extend functionally.
Of note:
Laying out the children, within the scrollable space of the RecyclerView, is delegated to managers. Hence, not only do three ship with recyclerview-v7 (list, grid, staggered grid), but others can be developed for alternative scenarios (e.g., overlapping children, for a StackView or Gallery sort of experience).
Updates from adapters can be much more fine-grained. With AdapterView, you pretty much have to redraw the entire view (e.g., a ListView and all its rows) on any change of significance, especially when adding and removing items. The update mechanism in the RecyclerView adapters indicate the specific positions that change. Not only does this require less processing time, but it helps enable the animated effects that RecyclerView offers (again, with pluggable replacements) for adding, moving, and removing items.
Other stuff that was "baked into" ListView, like drawing dividers, is now pulled out into extension points, such as an ItemDecorator. Now, you can choose how to "decorate" items, with line dividers or boxes or colored bar separators or whatever. Decoration is not limited to "dividers", but can affect anything in the views that, for one reason or another, you consider to be separate from the item views themselves.
RecyclerView, though, is fairly complicated to get going. What you get from ListView "out of the box" takes a lot more code -- yours or a third-party library's -- to match. For experienced developers, this is a feature, in that the code is replaceable with other code. For newcomers, this is a bug, in that there is a steeper learning curve for RecyclerView, IMHO.
As per the official documentation RecyclerView is a major enhancement over ListView. It contains many new features like ViewHolder, ItemDecorator, LayoutManager, and SmoothScroller. But one thing that certainly gives it an edge over the ListView is; the ability to have animations while adding or removing an item.
View Holders
In ListView, defining view holders was a suggested approach for
keeping references for views. But it was not a compulsion. Although by
not doing so, ListView used show stale data. Another major drawback of
not using view holders could lead to a heavy operation of finding
views by ids every time. Which resulted in laggy ListViews.
This problem is solved in RecylerView by the use of
RecyclerView.ViewHolder class. This is one of the major differences in
RecyclerView and ListView. When implementing a RecyclerView this class
is used to define a ViewHolder object which is used by the adapter to
bind ViewHolder with a position. Another point to be noted here, is
that while implementing the adapter for RecyclerView, providing a
ViewHolder is compulsory. This makes the implementation a little
complex, but solves the issues faced in ListView.
Layout Manager
When speaking of ListViews, only one type of ListView is available
i.e. the vertical ListView. You cannot implement a ListView with
horizontal scroll. I know there are ways to implement a horizontal
scroll, but believe me it was not designed to work that way.
But now when we look at Android RecyclerView vs ListView, we have
support for horizontal collections as well. In-fact it supports
multiple types of lists. To support multiple types of lists it uses
RecyclerView.LayoutManager class. This is something new that ListView
does not have. RecyclerView supports three types of predefined Layout
Managers:
LinearLayoutManager – This is the most commonly used layout manager in
case of RecyclerView. Through this, we can create both horizontal and
vertical scroll lists. StaggeredGridLayoutManager – Through this
layout manager, we can create staggered lists. Just like the Pinterest
screen. GridLayoutManager– This layout manager can be used to display
grids, like any picture gallery.
Item Animator
Animations in a list is a whole new dimension, which has endless
possibilities. In a ListView, as such there are no special provisions
through which one can animate, addition or deletion of items. Instead
later on as android evolved ViewPropertyAnimator was suggested by
Google’s Chet Haase in this video tutorial for animations in ListView.
On the other hand comparing Android RecyclerView vs ListView, it has
RecyclerView.ItemAnimator class for handling animations. Through this
class custom animations can be defined for item addition, deletion and
move events. Also it provides a DefaultItemAnimator, in case you don’t
need any customizations.
Adapter
ListView adapters were simple to implement. They had a main method
getView where all the magic used to happen. Where the views were bound
to a position. Also they used to have an interesting method
registerDataSetObserver where one can set an observer right in the
adapter. This feature is also present in RecyclerView, but
RecyclerView.AdapterDataObserver class is used for it. But the point
in favor of ListView is that it supports three default implementations
of adapters:ArrayAdapter CursorAdapter SimpleCursorAdapter Whereas RecyclerView
adapter, has all the functionality that ListView adapters had except
the built in support for DB cursors and ArrayLists. In
RecyclerView.Adapter as of now we have to make a custom implementation
to supply data to the adapter. Just like a BaseAdapter does for
ListViews. Although if you wish to know more about RecyclerView
adapter implementation, please refer to Android RecyclerView Example.
Item Decoration
To display custom dividers in a ListView, one could have easily added
these parameters in the ListView XML:
android:divider="#android:color/transparent"
android:dividerHeight="5dp" The interesting part about Android
RecyclerView is that, as of now it does not show a divider between
items by default. Although the guys at Google must have left this out
for customization, intentionally. But this greatly increases the
effort for a developer. If you wish to add a divider between items,
you may need to do a custom implementation by using
RecyclerView.ItemDecoration class. Or you can apply a hack by using
this file from official samples: DividerItemDecoration.java
View Holders
RecylerView by the use of RecyclerView.ViewHolder class. This is one
of the major differences in RecyclerView and ListView. When
implementing a RecyclerView this class is used to define a ViewHolder
object which is used by the adapter to bind ViewHolder with a position
Layout Manager
support for horizontal collections as well. In-fact it supports
multiple types of lists. To support multiple types of lists it uses
RecyclerView.LayoutManager class. This is something new that ListView
does not have. RecyclerView supports three types of predefined Layout
Managers: LinearLayoutManager – This is the most commonly used layout
manager in case of RecyclerView. Through this, we can create both
horizontal and vertical scroll lists. StaggeredGridLayoutManager –
Through this layout manager, we can create staggered lists. Just like
the Pinterest screen. GridLayoutManager– This layout manager can be
used to display grids, like any picture gallery.
Item Animator
RecyclerView has RecyclerView.ItemAnimator class for handling
animations. Through this class custom animations can be defined for
item addition, deletion and move events. Also it provides a
DefaultItemAnimator, in case you don’t need any customizations.
Adapter
In RecyclerView.Adapter as of now we have to make a custom
implementation to supply data to the adapter. Just like a BaseAdapter
does for ListViews.
Source: http://www.truiton.com/2015/03/android-recyclerview-vs-listview-comparison/
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.
I have a ListView which onItemClick selected item changes its layout, pops different buttons. If any other item is selected, the previous selected one returns to normal. My ListView adapter works fine but refreshing the whole list with notifyDataSetChanged() in my adapter takes too much time.
My problem is to refresh only the changed items in the ListView.
And also I would like to have suggestions for better scrolling performance.
try to implement View Holder Pattern it increases the performance of loading and scrolling of ListViews
Making ListView Scrolling Smooth | Android Developers
Using lists in Android (ListView) - Tutorial - Vogella
from the docs:
Your code might call findViewById() frequently during the scrolling of ListView, which can slow down performance. Even when the Adapter returns an inflated view for recycling, you still need to look up the elements and update them. A way around repeated use of findViewById() is to use the "view holder" design pattern.
you can define one method in adapter class which will return current item view. in onitemclick use this method to make changes in clicked item. You can define class view type class variable in activity and store previous view there...
ListView scrolling performance slows down when widgests like textviews, images are at the bottom of the layout hierarchy.
So for improving list performance one should design item xmls with minimum layout tree levels.
My problem is similar to ListView getChildAt returning null for visible children, but despite searching I cannot find a solution.
I have a ListView with a Scroll. The ListView has 10 items, 7 of which are visible and 3 are hidden by scroll. I also have an external method (out of adapter) that must get all of the children from this ListView (e.g. using getChildAt()).
I need all 10 of the items, but the last 3 are null objects. I've tried code like the following:
getListView().smoothScrollToPosition();
But this doesn't work.
I think that I don't need to post the rest of my code, as the description says everything?
As you have already seen you can't get all the child row views from a ListView simply because a ListView holds only the views for the visible rows(plus some recycled rows but you can't reach those). The correct way to do what you want is to store whatever data in the adapter's data and retrieve it from there.
But the ListView doesn't keep the current values from RadioGroup in
running time.
I've seen that you have some problems with this so I've adapted some old code to build a basic example, code that you can find here.
I don't think so you need to add scroll view for a listView. Scroll automatically works on ListView. Try your application without adding scroll view and I'm sure it'll work as you needed.
The reason those children are null it's because they really do not exist and they will never exist, if only 7 children are on the screen at one time, the system will only create 7 and re-use by passing the convertView back to the adapter getView() method.
If you want to grab information regarding your whole dataset you should search on the dataset itself, instead of the views on the screen. E.g. if it's an ArrayAdapter, loop the array; if it's a CursorAdapter, loop the cursor; etc.
The non-visible children of a listView don't actually exist. When they become visible, one of the redundant views is recycled or a new view is generated. So you can't actually access all the views. Why do you want to? Whatever changes you want to make should be made to the data that populates the views rather than the views themselves.
There are a few point that you need to take care of:
1. List view provides inbuilt scroll functionality, So don't use Scroll view. It will only mess up things.
2. List view doesn't contain ALL the children. When you scroll it, it creates only visible items on run time.
3. If you want to get all the children altogether, Better keep an ArrayList of the child objects that your list has. You can add or remove children to this ArrayList as per requirement.
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.