getView from CustomizedAdapter called several times

by Ola Ingvaldsen » Thu, 23 Jul 2009 16:20:32 GMT

Sponsored Links
  am having the same problem. In my case it only happens if I specify my own
layout using setContentView in onCreate() of my ListActivity. If i use the
standard layout i get correct number of calls to getView.

The thing is that if I have 5 items in my list i suspect the first 5 calls
to getView to have convertView=null each time. But its not. First time its
null, then the next 5 calls have the same convertView as the previous call
and then 5 more calls where the convertView is null. So the first 6 calls
to getView only results in changing the first element 5 times more than
whats necessary. After the 5 first calls the convertView is null and the
rest of the items in the list are filled out correctly. But when i scroll
down the list, we have 10 more calls again.

Does anybody have an idea whats wrong? Or how it can be avoided?

I have no weights in my layout at all. Its just a simple textView with a
status message and a listView.


On Wed, Jul 15, 2009 at 4:05 PM, Streets Of Boston


getView from CustomizedAdapter called several times

by Romain Guy » Thu, 03 Sep 2009 00:02:37 GMT

 here's nothing wrong with this, it can (and it will in some
situations) happen. getView() is not guaranteed to be called exactly
once per item. It happens for instance when you set the list/grid with
a height=wrap_content.

On Wed, Sep 2, 2009 at 5:32 AM, Guitou<> wrote:

Romain Guy
Android framework engineer

Note: please don't send private questions to me, as I don't have time
to provide private support. All such questions should be posted on
public forums, where I and others can see and answer them


Sponsored Links

Other Threads

1. Where can I find the source code of camcorder application on g1 phone?

Where can I find the source code of camcorder application on g1 phone?



2. RelativeLayout breaks the paradigm of ViewGroup with onMeasure and onLayout

According to

onMeasure(int, int)     Called to determine the size requirements for this
view and all of its children.
onLayout(boolean, int, int, int, int)   Called when this view should
assign a size and position to all of its children.

RelativeLayout doesn't do this; it actually assigns a size and
position to all of its children in onMeasure.  From the source code of
    protected void onLayout(boolean changed, int l, int t, int r, int
b) {
        //  The layout has actually already been performed and the
        //  cached.  Apply the cached values to the children.

This is bad because, I wanted to override a RelativeLayout and assign
it a specific height.  However, the children of this RelativeLayout
would not respect the height I assigned, because the children assign
themselves positions and sizes in onMeasure.  And therefore the
children don't fit in the RelativeLayout.

IMHO it's a bad sign of the design when the actual framework doesn't
follow its own design.  I know this sounds like a flame or a rant, but
I'm just trying to point out what I believe to be a underlying problem
here.  If you can't override a RelativeLayout then it should have been
declared final (but that's too drastic).  Perhaps the onMeasure and
onLayout need to be rethought (guess it's too late for that :).  At
the very least, the documentation should be updated so that one knows
that when subclassing RelativeLayout, that the size and position of
all of its children are actually assigned in onMeasure and onLayout.


3. Set time in VirtualBox and USB mouse problem

4. A LiveCD for Android

5. <android-porting> Need help porting android on X86

6. TabHost runtime image changing

7. How can I instantiate android.R.layout.simple_list_item_1 in Custom ListAdapter?