Edittext In the Adapter in Android, checkbox remember status solution (1), androidedittext

Edittext In the Adapter in Android, checkbox remember status solution (1), androidedittext

I. Cause

We all know that the view of the adapter in Android uses a reuse mechanism. Simply put, when the items on the screen are full, when we slide the listview, the first item will exit the screen, the last item enters the screen

View getView(final int position, View convertView, ViewGroup parent)

At this time, convertview in getview is not empty, and its value is the view of the first item. We usually cache the item through ViewHolder, so we do not need to repeat findid, you can directly use the cached controls.

This cache mechanism is the root cause of the problem. Some may have said that the problem cannot be solved as long as convertview is not used for caching. For such a solution, I can only say that all users who can use this solution are thinking about the problem with their ass!

Ii. Problem Solving

1. There are two problems above: editText and checkBox. First, we should simply consider the two statuses of checkbox, so we should solve the checkBox first.

First, use enum to mark the selected and unselected statuses.

public enum Type {Checked, UnCheck;}

Then simulate the data in the constructor. Here I use typeList to save the checkbox status, which is not selected by default.

private List<CartBean> list;private List<Type> typeList = new ArrayList<Type>();public CartAdapter(Context context, List<CartBean> list) {this.list = list;this.context = context;initData();}private void initData() {for (CartBean cartBean : list) {Type type = Type.UnCheck;typeList.add(type);}

Next,

        mHolder.cb.setOnCheckedChangeListener(new OnCheckedChangeListener() {@Overridepublic void onCheckedChanged(CompoundButton buttonView,boolean isChecked) {if (isChecked) {typeList.set(position, Type.Checked);} else {typeList.set(position, Type.UnCheck);}}});if (typeList.get(position) == Type.Checked) {mHolder.cb.setChecked(true);} else if (typeList.get(position) == Type.UnCheck) {mHolder.cb.setChecked(false);} else {mHolder.cb.setChecked(false);}

I first registered a listener for the checkbox. When the checkbox status changes, I also change the status of the corresponding position in the typeList, then, set whether to select the checkbox Based on the status stored in my typeList, so that the problem can be solved. However, if you place the listening code after setting the checkbox status, the checkbox status will still be lost.Why? Viewholder caches items at the beginning of the article. Therefore, if the listener writes the item at the end, when the checkBox attribute is initialized, The onCheckedChange () method is called because it may change its status, this listener was added during the previous initialization, so the position is the previous one, not the current position, which leads to the status error in typeList.

Let me give you an example. For example, if I select the checkbox of the first item, 10 items will be displayed on the screen. When sliding the item, 11th items will be displayed, it re-uses the view of the first item, and the checkbox is also the first, and the listener is also the first. When the system executes this code

if (typeList.get(position) == Type.Checked) {mHolder.cb.setChecked(true);} else if (typeList.get(position) == Type.UnCheck) {mHolder.cb.setChecked(false);} else {mHolder.cb.setChecked(false);}

You have to change the checkbox status from the selected status to the unselected status, which triggers the listener event.

public void onCheckedChanged(CompoundButton buttonView,boolean isChecked) {if (isChecked) {typeList.set(position, Type.Checked);} else {<strong>typeList.set(position, Type.UnCheck);</strong>}}

Based on this code, the status of the checkbox at position 0 is set to uncheck. In this way, when we slide back and the first item re-enters the screen, we will find that the item state is lost and becomes unselected.

To avoid this problem, you must register the listener each time, and then set whether the item is selected based on the storage status in typelist.

The checkbox problem is solved, and the next step is editText. This is a little troublesome. Let's take a look at the picture at the beginning of my article. I will not only save the value in edittext, make sure that the edittext object operated on is correct when adding or subtracting buttons, and there is still a focus issue.

2. Let's talk about the focus problem first. In listview, we click editText to find that the soft keyboard is displayed and the cursor is moved to EditText. However, no matter what editText is entered, it is not displayed! For this, we can configure this in the Activity.

Android: windowSoftInputMode = "adjustPan"This is the pop-up mode for setting the input method. If the layout is not squashed, the input method will overwrite the layout, and editText will also get the focus. In fact, editText cannot be input because there is no focus, which can solve the problem. You do not need to dynamically obtain the editText focus.

In this case, edittext can be used to input the content, and the next step is to save the content and the edittext that the button can operate on.

My practice is to save the edittext object in the list. This is not good because edittext cannot be serialized and stored persistently, which leads to the loss of this object. We all know that when the system switches between the horizontal and vertical screens, the Activity will be restarted or the system will clear the Activity when the application remains in the background for a long time, when the user returns to the application, the Activity will be restarted. If we cannot store the status, the user experience is not very good. You can store this list in the application for static storage, just like the list for managing all activities in the project.

The next article will have a demo.

Edittext In the Adapter in Android, and checkbox remembers the status solution (2)