Usage of ListView and Adapter in android Development

1. Adapter. getView ()

Public View getView (int position, View convertView, ViewGroup parent ){...}

This method is used to obtain the View to be displayed at the specified position. The official website is explained as follows:
Get a View that displays the data at the specified position in the data set. You can either create a View manually or inflate it from an XML layout file.

Call this method once to display a View. This method is the key to the performance of ListView. There is a convertView in the method. This is the cache mechanism Android is doing for us.
Each item in ListView is returned and displayed through getView. If there are many items, it is unreasonable to create so many objects repeatedly. Therefore, Android provides a Recycler to put items that are not being displayed into RecycleBin, and then reuse the View from RecycleBin when a new View is displayed.

Recycler generally works as follows:
Assuming that up to 11 items can be seen on the screen, When 1st items are out of the screen, the View of this item enters RecycleBin. Before the first item appears, use getView to RecycleBin) reuse this View and set the data without creating a new View.

We use APIDemos provided by Android to verify this process:

First look at the key code:Copy codeThe Code is as follows: public View getView (int position, View convertView, ViewGroup parent ){
// A ViewHolder keeps references to children views to avoid unneccessary CILS
// To findViewById () on each row.
ViewHolder holder;
// When convertView is not null, we can reuse it directly, there is no need
// To reinflate it. We only inflate a new View when the convertView supplied
// By ListView is null.
If (convertView = null ){
ConvertView = mInflater. inflate (R. layout. list_item_icon_text, null );
Log. v ("tag", "positon" + position + "convertView is null," + "new:" + convertView );
// Creates a ViewHolder and store references to the two children views
// We want to bind data.
Holder = new ViewHolder ();
Holder. text = (TextView) convertView. findViewById (R. id. text );
Holder. icon = (ImageView) convertView. findViewById (R. id. icon );
ConvertView. setTag (holder );
} Else {
// Get the ViewHolder back to get fast access to the TextView
// And the ImageView.
Holder = (ViewHolder) convertView. getTag ();
Log. v ("tag", "positon" + position + "convertView is not null," + convertView );
}
// Bind the data efficiently with the holder.
Holder. text. setText (DATA [position]);
Holder. icon. setImageBitmap (position & 1) = 1? MIcon1: mIcon2 );
Return convertView;
}

Static class ViewHolder {
TextView text;
ImageView icon;
}

:

You can see that 10 items are displayed when Activity is opened.

Let's look at the Log information:

It can be seen that each convertView is null and is displayed by creating a new View.

When we slide down, such,

Because item0 and item10 are both half displayed, item10 is also created. However, when item11 is to be displayed, item0 is no longer on the screen, so item11 reuse the item0 instance. We can see from the following Log information:

By analyzing the Log information, we can see that the item11 object is item0, The item12 object is item1, and so on.

In this way, by reusing convertView, you can avoid creating a View every time, saving memory and optimizing the sliding effect of ListView.

2. Layout XML of ListView

In addition to the preceding descriptions, the main point is the description of ListView in Layout XML.

First look at the problem:

Sometimes, we may see that as soon as ListView is opened, getView will call it again (assuming that at most 6 items can be seen on the screen), for example:

Always repeat 0-6, 0-5, 0-5, 0-5, 0-5. In addition, convertView is the same View at the beginning, because the ListView

Android: layout_height = "wrap_content ".

We changed it to android: layout_height = "fill_parent". The Log information is as follows:

It can be seen that after modification, the getView call of ListView is restored to be consistent with the Recycler action.

I have not studied why wrap_content is repeatedly called. However, I initially thought that it was caused by the use of an item to test the maximum height of the ListView in the screen because it was unclear when the ListView was depicted by Android. I hope some of you can tell me. Thank you!

Finally, if there is something wrong with it, I hope I can point it out and make mutual progress.

Supplement:

When using ListView, we found another strange phenomenon. After notifyDataSetChanged () is called, when ListView re-getView (), the order of all convertviews is reversed. See the following:

This should be because the recycleBin is a stack structure.

Others:

1. Disable divider:

Android: divider = "#00000000"
Android: dividerHeight = "0dp"

2. Disable ListView selector:

ConvertView. setOnClickListener (null );
To remove the color, use android: listSelector = "#00000000"

3. Disable header divider:

Android: headerDividersEnabled = "false"
4. getItemViewType (int) and getItemViewType (int)

GetItemViewType (int) can not return int value larger than getViewTypeCount ().
Otherwise you will get java. lang. ArrayIndexOutOfBoundsException at android. widget. AbsListView $ RecycleBin. addScrapView (AbsListView. java: 3523)
ListView returns convertView of the corresponding type based on different viewtypes.

General Syntax:

Copy codeThe Code is as follows: getView (){
Switch (getItemViewType (position )){
Case type1:
If (convertView = null ){
} Else {
}
Break;
Case type2:
Default:
If (convertView = null ){
} Else {
}
Break;
}
Return convertView;
}
GetItemViewType (int position ){
// Based on the scenario, there are generally:
// 1. The position corresponding to different item types is fixed, so the data of ListView can be separately stored
// 2. The position corresponding to different item types is not fixed, so you can put the data of ListView in the List <Object>,
// Use instanceof to determine the Object type and distinguish the view type corresponding to position.
}