What will happen if we keep on loading thousands of items in any type list in Android? Will Android be able to recycle it correctly?
Short Answer
In your case, there Would not be any problem in recycling of list view or recycler view.
Long Answer
The list view or recycler view would just load and show the amount of data which are visible on the UI. So the size of the items in it is not any problem.
BUT
there are some cases which would make problem.
for example if you put a recycler view inside a Scroll view!
In such cases all of the items are loaded and there is no GC. That's where you would have big problems with lots of data.
List is an Interface, not a class, so there are ArrayLists and LinkedLists and several other types, but ArrayLists for example can handle up to Integer.MAX_VALUE elements. I've never had a problem with an ArrayList and garbage collection at least and thousands of items is far below the limits of that class.
Related
I want to put a list of items I am extracting from a firebase database. I was using RecyclerView for this but now I came to know that we can create Buttons, TextViews etc programmatically. I was wondering if there are any benefits of recyclerview or any special cases where it is preferable to use recyclerview.
Use RecyclerView, it is memory efficient. It does create view when it is visible and destroys it when it is not visible anymore, this way you can have infinite list without using a lot of resources.
Not bad thing to maintain view dynamically, But you need to know full concept of recycler view before taking the decision because there are lot's of aspect depend on when you are deciding to any component
Key aspects,
- Why you are using view?
- Is it sequential?
- All the data in the list are the same type?
- Also, How many records in the list if there is only tow-three record then no need to take the recyclerview.
Ultimately recyclerview is the optimized view for list out the item as a list,
Also, we suggest if your most of the data same type then take recyclerview don't do at dynamically, Because name self saying how recycler view (Recycle) will work
I can't understand how the RecyclerView recycle the views and reuses them if there are more than one type of views.I know that the Adapter will create two more ViewHolders for reusing.In that case,there are no more than two type of views that can be reused to present the next item in the window.But if the type of next item doesn't match either of the two types that have been recycled,there will be no views available to be reused to present the next item because the type of view it needs is still visible on the screen and cannot not be recycled.How does the system handle it ? Any and all answers are appreciated.
If there is a recycled view available that MATCHES to the new one that's becoming visible, then it will re-use. Otherwise it'll create the new object for the new view. It uses getViewType () to find that.
You can take a look at this for few more related points.
The RecyclerView will create as many ViewHolders as it needs to fill the available visible space. Recycling happens when one scrolls out of view. At that time, it will be reused for a new item scrolling into view.
The number of ViewHolders that have been created. Typically, you can figure out how many
there should be by determining how many list items fit on your screen at once and add 2 to 4
to that number. That isn't the exact formula, but will give you an idea of how many
ViewHolders have been created to display any given RecyclerView.
There is object array received from server
there are two ways to show items :
Adapt Objects To ListView
Use Scroll View
So If I use scroll View and add items programmatically, There are some Questions:
Does Adding Items Programmatically Cause Out Of Memory ?
Does It Need To Remove Items from memory ? or it will remove automatic after onDestroy Called or Items moved out of screen?
Regards
If the data set is large, a ListView won't stop OOMs by itself, you will have to avoid loading the entire data set in memory by using a CusorAdapter backed by some non-memory data store (like a sql database).
A ListView will reduce the amount of memory that the Views use to represent the data to the user, since it will only initialise Views that the user can see (and recycle Views if possible when the user scrolls).
Since only the Views visible are loaded with a ListView, performance should* also be better since the layout process will be quicker.
In most cases, a ListView would be better for this type of thing.
(*) If the adapter's getView or bindView e.t.c. are complex, or each row in the list has its own view type, the scrolling performance could actually be worse.
Listview is the Best case for you. and I will prefer to use volly library of android . It is easy to use and very handy and helpfull.
I have a list of lists of lists, implemented as a MvxListView.
It looks like
-Parent-
MvxListView containing items of Fruit
-HumanCell-
Some forms and an MvxListView containing items of ExistingFruitColors
-ExistingFruitColors-
Some forms and an MvxListView containing items of ExistingShapes
-ExistingShapes
Some forms
I noticed that when I'm navigating in my app (this closing and reopening the ViewModel) as well as when I'm scrolling in the listview, I'm seeing some garbage collecting GC_BRIDGE appearing in the debug screen. In 2 minutes, memory consumption can grow from 6MB to 12MB for a simple 30 cells list.
The fact that a lot of object are created is not a problem, but I'm curious if it's possible to override a method either in the adapter or in the list to garbage or dispose of some views and listeners.
There is no changes happening in the list, but there's a lot of memory variations.
I'm thinking about listening to ViewModel changes and only update the listview canvas when a real change happens, but that's an ugly solution.
Is there something I should be aware when nesting binded lists into binded lists?
Can I force the MvxListView to just draw my items and not attempt to do anything else with it?
Is there something I should be aware when nesting binded lists into binded lists?
IMO, generally, this is normally better done as a single list with sections/groups. It's easy to use header/footer cells for each section and to use a custom adapter to decide which cell to draw.
Having lists within lists can also give a strange touch experience for the user - since the lists can scroll independently - but if this is the UX you desire, then this should be OK.
Can I force the MvxListView to just draw my items and not attempt to do anything else with it?
Sorry, but I'm not entirely sure what this question means.
In general, MvxListView (and ListView) only draw the cells/items currently on screen - recycling is used on cells to reduce the memory used.
When a Activity is Finished, then the MvxListView's ItemSource is set to null - which should result in the ListView memory being cleared up when the Activity is complete.
One thing to be aware of is that in order to estimate the total list scroll size, then the list view does initially have to consider all the list items - it does have to estimate how high each cell is.
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.