I'm having some difficult time figuring out when the ListView decides to recycle all it's views. I have 2 different ListViews where i change some layout stuff and play an animation after that. In my first ListView this works fine, only the row i'm trying to change is actually being affected, yet in my other ListView all rows are affected and the Views are being reused.
I can't really post any code, as there are quite a few classes involved in this. I tried to break it down and noticed it reuses the rows after calling requestLayout() at one of the descendant views of the row. But in my other ListView i do the same and it's not called at all.
Nowhere in my code notifiyDatasetChanged() is called either, nor am i changing any other views.
I just trying to find out when ListView actually needs to reuse the views.
ps. I'm using 2.3.3. And i'm aware of setHasTransientState() in 4.1. But i can't use that unfortunately
I found my specific problem.
After long debugging through the source of the ListView I found the difference in behavior between my two ListView implementations. I found out that one of them was calling onSizeChanged(), first to a new height immediately followed by another onSizeChanged() with the old height. In this method it sets a flag mDataChanged which in turn will cause the views to be recycled.
In my other ListView i have fixed row heights so it never has this problem. I'm going to do the same for this situation as i don't really need different row heights.
Related
Regarding the lisview recycle, I'm reusing the views with viewholder, but now I need to add a number of Views(ImageViews and textviews) not clearcut( the number of views isnt always the same).
How can I add these items, without create a new view on every getView() method and without affecting the performance of the list?
No way to create different layouts without overriding getView(). You can reuse as much view types as you want, read this answer.
If you have perfomance issue, try a new widjet RecyclerView, available at Support-V7 library.
my strategy to implement what you described without creating new view every time getView() is called, is:
let's say you have at the most 10 image views. your view xml will contain 10 ImageView items,
but when getView() been called - you'll set the visibility of the un-needed elements to View.GONE, and the only ones you needed to View.Visible.
working great for me, and that's the only why not to create new view...
My problem is on two fronts.
First issue: Scrolling amnesia
I have a ListView with spinners and edit texts. It acquires it's data from webservice. The problem is when I write up a value on the EditText or select something for the spinners and scroll them out of view. When I come back the fields are empty and the spinners are again in their default selection.
Attempted solution
I have tried resolving the issue by setting ScrollingCacheEnabled programmatic and within the AXML file to both true and false just to see if that is an issue. It seems not to have any kind of an effect.
Second issue: Focus Loss
When I touch the EditText within this same ListView I get the keyboard to appear but I loose the focus on the field and it needs to get touched again to get focus and it allows me to be written.
Attempted solution
I fiddled with setting the fields focusable, Focusavle in toucmode, touchable and whatnot but came out empty handed.
Honestly I am quite new to android and to programming on this level as well but I tried my best on this. I might have just missed something due to lack of knowledge or it's just something somebody with more experience could tackle and solve.
The second issue isn't that bad for now (still after filling out quite a number of fields it does get tiring to set it twice...) but the scrolling issue is a must.
I think you problem relates to that you forget to update the items in the Adapters when you alter the Views containing them. So you need to wire up the events from the Views to update the items.
Why? If you look carefully at your Adapter for you ListView you populate the convertView with the values of GetItem(position). So if that item does not reflect the changes you have made to the View you are bound to get the initial values of that item.
So what you need to do is to hook up SpinnerValue.ItemSelected and all the other Views which can be altered events, so that the items in the Adapter get their values updated. Remember to only add event handlers when you first create the View. So that is when convertView is null.
Also consider changing the lines:
if (SpinnerValue.Adapter.Count.Equals(2))
{
SpinnerValue.SetSelection(1);
}
To be based on the items in the Adapter rather than setting it to 1 every time.
You focus problem is based in that ListView is not really made for having Views inside of it wanting the focus. Try setting the ListView DecendantFocusability when you instantiate it to DescendantFocusability.AfterDescendants like so:
lstPrevzem.DescendantFocusability = DescendantFocusability.AfterDescendants;
I resolved the issue by replacing the listview with LinearLayout and pinning the adapter to it. The "fixed" code is available on pastebin.
Fixed code:
http://pastebin.com/vn3SPrFz
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 ListView with custom Adapter. To be honest, I have many of them at the same time on screen, and my Tegra 3 device started to lag, what made me really confused... I found than in each ListView's Adapter the getView() method is called for all visible rows every time any animations runs on screen. That gives me like few hundreds of calls per second! Digging more, most of these calls are due to measure() and onMeasure() calls of ListViews' parents, and - this is tke key - they are useless, because all the layouts of my ListViews
have const size.
So my question is: how to eliminate these calls? Of course I want to leave proper calls alone (caused by adding items to Adapter and notifyDataSetChanged() ).
I've tried almost anything, but either the whole list doesn't draw itself (when I overriden it's onMeasure() and forced to returned const size without calling super.onMeasure()) or stops updating at some time.
How you implemented the getView() method? If you implement it in the correct way there should be nearly no lagging.
Check out this really really good video:
http://www.youtube.com/watch?v=wDBM6wVEO70
Slides: http://dl.google.com/googleio/2010/android-world-of-listview-android.pdf
As Romain said, work with it not against it. Best is to leave measure() alone and focus on your adapter.
Thats how ListView is implemented.. I don't think that will cause a performance Overhead.. Provided you do things properly there..
For example..
Don't instanciate LayoutInflator inside GetView Method, Do it at class level..
And Inflate View Only if the convertView==null or else just return convertView.. Inflating view is a costly process....
Well like you said these calls are due to measure() and onMeasure() calls of ListViews parents and I'm sure you are using height=wrap_content also with wrap_content on height your ListView will check without stop if your height has changed.
So the solution is to put the height=fill_parent.
I hope this helped you.
The underlying reason for this is that ListView.onMeasure() calls AbsListView.obtainView(), which will request a view from your list adapter. So if your view is being remeasured through animations, your performance will be very poor.
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.