I'm new to Android programming. I wonder how many items a ListView can store? I search in docs but they don't talk about this. What if I put a lot (maybe 10k) items into a ListAdapter, will it affect to the performance?
Cheers,
MK.
The ListView is virtualized in Android. Practically speaking, that means that there's no actual limit for the number of elements inside it. You can put millions of rows inside the list and it'll only allocate memory for the currently visible ones (or a few more tops).
Check out the dozens of tutorials regarding writing a custom Adapter class for an AdapterView (ListView extends that). Also check out the Google I/O 2010 session on ListViews; it's really useful: here
There's no limit as the ListView only renders items when they come into view, and so only cares about the data for the ListView when it comes to render the item (though it needs to know the quantity of items to render the scrollbar correctly)
The Google IO video really is great for learning about ListView
http://www.youtube.com/watch?v=wDBM6wVEO70
That said, I'd ask whether you SHOULD load that many, as clearly the user cannot look at them all and scrolling around a ListView with that many items will be very tedious. If it was me I'd be asking some questions:
Does the list need to show them ALL initially? Can it just show the most relevant set? The nearest/biggest/smallest/best/etc
Rather than load them all at once, can you load blocks in pages of items? So for example you load 10-100 initially, and when the user gets to the bottom show "Loading more..." with a progress spinning icon, and pull more in, then the user can choose how many to load, and how much scrolling they are prepared to do
Should you be building a UI to filter the items so there's never a need for them to look at 10,000?
More on ListView
http://www.softwarepassion.com/android-series-custom-listview-items-and-adapters/
http://developer.android.com/guide/topics/ui/binding.html
http://www.androidguys.com/2008/07/14/fancy-listviews-part-one/
Integer.MAX_VALUE since most of its functions will break as they rely on int position.
I created a ListView and used Integer.MAX_VALUE as the number returned to the adapter for the number of items in the list. This had no effect on the performance of the ListView even though it was holding about 2 billion items.
I think 10k will work :P
Check out my answer here to see in detail what I mean : How to create a closed (circular) ListView?
You have a memory limit (which is device specific). As long as you don't exhaust your memory limit, you can store as many items as you wish. There are ADT tools that you can use to monitor how much memory your application is using at any moment.
Related
This is not a code problem, I interpret the guidelines as that being OK.
I've been researching a way of building an infinitely scrolling calendar-like view in Android, but I've reached an impasse.
Right now my dilemma is that most of the similar views available have their children placed relative each other in a recurring style. With this I mean:
item 4 comes after item 3, which comes after item 2, and there is constant padding/margin between all items.
What I need is a way to produce an infinitely long scrollable view that may, or may not, contain items. The items should be placed at variable positions within the view. The best way I can describe a similar looking view is a one-day calendar-like view that is infinitely scrollable.
So far my best two bets are using the new RecyclerView with a custom LayoutManager (this seems very complex and still not perfectly documented by Google though). I like this approach because, among other things, it is optimized for displaying large sets in a limited view.
My other solution would be to build a completely custom View. However, with that solution I loose the adapter unless I build a container view (which is probably more complex than building a layout manager).
How would you go about solving such a problem? Tips are appreciated, I don't need code examples, just ideas which path is the best to solve this problem.
Thanks.
Apologies if I've misunderstood the guidelines
Edit: How I resolved this problem
My first solution to use RecyclerView with a special Decorator seemed promising, but it remained a "hack" so we decided not to go for that solution since we were afraid of the complications that it would create down the line.
To solve the problem I went with a SurfaceView instead of an Adapter, this means having to rewrite all the adapter-functionality for my SurfaceView but it seemed to be the best way of solving this issue of very custom drawing and layout managing for my use-case.
It still would be nice to build a custom Viewgroup that can handle this kind of layout problems.
ListView and ListAdapter are based on a fixed list, so the current infinite-scrollers just keep adding more and more data to the end of the list.
But what you want is scroller similar to Google's Calendar app which has a bi-directional infinite scroller. The problem with using ListView and ListAdapter in this case is that if you add data to the front of the list, the index of any one item changes so that the list jumps.
If you really start thinking about this from the MVC perspective, you realize that ListAdapter does not provide a model that fits this need.
Instead of having absolute indexing (i.e. 1, 2, 3, 4, etc), what you really want is relative indexing, so instead of saying "Give me the item at index 42" you want to say "here's an item, give me the five items before it". Or you have something like a calendar date which is absolute; yet — unlike your device's memory — it has effectively no beginning or end, so what you really want here is a "window" into a section of that data.
A better data model for this would be a kind of double-ended queue that is partly a LRU cache. You place a limit on the number of items in the structure. Then as prior items are loaded (user is scrolling up) the items at back end are pushed off, and when subsequent items are added (user is scrolling down), items at the front are pushed off.
Also, you would have a threshold where if you got within a few items of of one edge of the structure, a "loadNext" or "loadPrevious" event would fire and invoke a callback that you set up to push more data onto the edge of the structure.
So once you've figured out that your model is completely different, you realize that even RecyclerView isn't going to help you here because it's tied to the absolute indexing model. You need some sort of custom ViewGroup subclass that recycles item views like a ListView, but can adapt to the double-ended queue. And when you search code repos for something like this, there's nothing out there.
Sounds like fun. I'll post a link when I get a project started. (Sadly, it won't be done in any timely manner to help you right now, sorry.)
Something that might help you a little sooner: look at Google's Calendar implementation and see how they did it: Google Calendar Git repo
What you may be searching for is a FragmentStatePagerAdapter , where you can implement a swiped view, meaning when the user (for example)swipes to the right, a completely new view is displayed.
Using a FragmentStatePagerAdapter , you can handle a huge amount of views without overflowing the memory, because this specific PagerAdapter only keeps the views' states and is explicitly meant to handle large sets of views.
Keeping your example of a calendar, you can implement swiped navigation between for example weeks and generate the week views on demand while only keeping for example the year and the week's number as identifiers.
There are plenty of online tutorials for Android, maybe you have a look at this one
Today I was thinking about how Android framework works, and I'm not sure about one thing - how developer (me) should program lists to show custom data from few sources. I created few apps, but its important to me to keep my applications clean and fast as possible.
So - I have an app, for example news reader. Im using Fragments, ListFragments, custom layouts for list items and BaseAdapter for showing data in many lists and activities. Nothing new here, and nothing special. At first I download all data from webserver to sqlite in app, so Im sure about it speed and stability. And then what's next?
Should i create List items from Java Lists (List items) and then pass it to baseadapter, or I should only use way SQLite Cursor->list item? What is better to refresh list, add new items and delete them? Remember that i have my ListFragment with baseadapter in separate class.
Im not sure about it, so I clearly dont know how should i refresh and load new items to my list. I just want to keep app clean, without many 3rd party libraries (so i dont care about EndlessList or something like that).
tl;dr
How should I create list for speed purposes, when i use few sources to show data?
I'm not sure whether I understand your full question but about the part which data source to use for an Adapter, here are my thoughts:
I think that depends on the amount of data you are dealing with. If it is sufficiently small you can keep everything in a List in memory, but you also need to be sure that the data won't grow over time.
Using a Cursor as a data source is unfortunately also not a safe option for getting around a possible "Out Of Memory" exception problem. There is a limit per query because of the implementation of the cursor which apparently loads the whole result set into memory.
So if you are dealing with a lot of data or data that potentially grows over time (like messages, user-created items), you need to have an Adapter that internally works with a data window which loads a fixed amount of items into memory at a time. That window always keeps a bunch of items in memory which can be currently viewed and quickly reached with the ListView (by scrolling up and down).
Let's say that window holds for example 200 items.
When the upper / lower bound of that window is reached the Adapter needs to load the next adjacent window. You can observe that kind of behavior in the GMail app ("Loading conversations....").
I would let that data sit in the cursor and not transfer it to a list first, because you can use the cursor like a list.
I am comparing performances, specifically scrolling speeds of a ListView, of apps that I create, to native Android 4.0 apps - Gmail, Gtalk, etc.
One thing I have noticed is that the scrolling frame rate of a ListView on the native Android apps are very high - almost 60fps. In my apps, a ListView don't scroll nearly as fast.
Assuming I'm using ListView incorrectly (which I'm not - I've followed everything stated here: http://www.youtube.com/watch?v=wDBM6wVEO70), I decided to create a dummy ListView that just returns a dozen almost empty LinearLayout views as it's rows (yes I'm using convertView correctly). What's disturbing here is that my almost blank ListView has slower scrolling performance than any of the native apps - Gmail, Gtalk, Contacts, etc.
As a side note, a simple ScrollView has really good scrolling performance, but it is inadvisable to use a ScrollView for large lists.
Clearly, the native apps are doing something (or have access to something) that I don't understand. Unfortunately these native apps aren't open source. Does anyone have any insight as to how these native apps achieve such tremendous performance?
After look at the source code for the native email application, I have found that the list items in a list of messages are single Views, not ViewGroups like LinearLayout. That makes for a very flat View hierarchy which leads to a better frame rate while scrolling the list. I think I remember watching a video of a talk by Romain Guy (one of the lead Android UI engineers) that mentioned that the Gmail team did something similar to increase performance.
To achieve this yourself, you'd have to subclass View and draw everything in the View yourself in the onDraw() method.
Here is the source for a message list item in the current email application.
They do a cool trick where you inflate a view (but don't attach it), get the coordinates of where the items go based on the ViewGroup it is in, and cache the coordinates in a Map so when a view is recycled in a list you don't have to inflate that view again. I might try this in a future project of mine!
I hope this helps!
There are some techniques to make ListView faster: caching and using dissapeared list items as new list items to avoid long operation of creating them. You need to create your own class based on ListView to realize these techniques. Read more here.
I also followed on that video to build my list view. In my app, there are not much items (rows). But I think if we just do as the video said, we are on right way, at least on the theory?
Building a dictionary application I need a ListView that shows over 100k items. I want to let the user scroll as much as needed.
What's the best practice for searching and showing words?
Is it ok to show 150,000 words in the ListView (for pereformance)?
If not how to add 100 other words after the user reaches to the end of the list?
Currently I show 50 words previous and 50 words next of searched word.
Thank you.
(second answer in response to clarification about performance)
There are different ways to do this based on where your data is.
The best way is to have your data in a sqlite database and use a CursorAdapter. Android then manages the fetching of your data and won't fetch data that isn't currently being shown on the screen.
If your words are in an array in memory, try ArrayAdapter or SimpleAdapter.
The Adapter interface, from which all of the above classes inherit, is designed to provide good ListView performance regardless of the number of objects in the list.
One built-in way to allow fast scrolling is via the fast scroll thumb. In your xml, set:
android:fastScrollEnabled="true"
on your ListView, or try:
listView.setFastScrollEnabled(true)
listView.setFastScrollAlwaysVisible(true)
RecyclerView is very good for this. I have developed an open source library especially designed to scroll through large list with extreme speed. In fact it can move well in excess of 1000 items per second both in single and multiple column layouts You can check out the repo here: https://bitbucket.org/warwick/hgfastlist or you can checkout the OpenGL version here: https://bitbucket.org/warwick/hgglfastlist. Here is a demo video on Youtube: https://www.youtube.com/watch?v=oz7aeAlOHBA&feature=youtu.be
Even if you don't want to use this library, there's loads of code to read through in the demo app that will give you good ideas.
When I have a ListActivity and an Adapter how does Android handle a list with 200 elements.
Does it try to load all of them directly how does it wait till the user scrolls and then renders those elements?
Do I have to worry with performance when a list is too long?
Depends how are the adapters implemented.
If you have an adapter that is not subclassed (you use one that is provider by SDK) Android will try to load all of them directly.
I recommend to subclass SimpleCursorAdapter and implement your custom adapter. This way you will have for example 10 views (as many your screen needs), and the view it will be reused for the rest of the 190 records.
There are several parts to this question. First of all, the data itself. Is that coming from a SQLite database via a query? If so, you have a Cursor object, which contains the entire result. So if you have a query that yields 200 rows, you will have all 200 rows in memory (which is why it's so important to narrow your projection).
As for the list itself, that part is pretty efficient - Android will only create views for the elements that you can actually see. And, depending on what kind of views you have, and whether they support recycling, Android will actually recycle existing objects to minimize the amount of overhead for initialization and memory management.
I'm not sure how Android handles it internally. But most programs I've seen handle the issue by loading 20 or so items and then making the last item say "Load next 20 items". Then when you click it, it loads the next 20 items.