Using convertView

The method receives, as one of its parameters, a named, by convention, . Sometimes will be null. In those cases, you have to create a new row from scratch (e.g., via inflation), just as we did before.

However, if is not null, then it is actually one of your previously created . This will be the case primarily when the user scrolls the – as new rows appear, Android will attempt to recycle the views of the rows that scrolled off the other end of the list, to save you having to rebuild them from scratch.

Assuming that each of your rows has the same basic structure, you can use to get at the individual widgets that make up your row and change their contents, then return from rather than create a whole new row.

For example, here is the implementation from last time, now optimized via (from the project at http://apress.com/):

Public class extends

Public onCreate

Super onCreate

SetContentView

SetListAdapter new IconicAdapter this

FindViewById

Public onListItemClick

SetText

Class extends

IconicAdapter

Super

This

Public getView

If null

GetLayoutInflater

Inflate null

FindViewById

SetText

FindViewById

If length

SetImageResource

Else

SetImageResource

Return

Here we check to see if the is null and, if so we then inflate our row – but if it is not null, we just reuse it. The work to fill in the contents (icon image, text) is the same in either case. The advantage is that if the is not null, we avoid the potentially expensive inflation step.

This approach will not work in every case, though. For example, it may be that you have a for which some rows will have one line of text and others will have two. In this case, recycling existing rows becomes tricky, as the layouts may differ significantly. For example, if the row we need to create a for requires two lines of text, we cannot just use a with one line of text as is. We either need to tinker with the innards of that , or ignore it and inflate a new .

Of course, there are ways to deal with this, such as making the second line of text visible or invisible depending on whether it is needed. And on a phone every millisecond of CPU time is precious, possibly for the user experience, but always for battery life – more CPU utilization means a more quickly drained battery.

That being said, particularly if you are a rookie to Android, focus on getting the functionality right first, then looking to optimize performance on a second pass through your code rather than getting lost in a sea of Views, trying to tackle it all in one shot.