Learning and summarizing of Android Listview--arrayadapter

Issue: There are some UI components in the ListView selected ListItem view, such as a checkbox, for the expectation of state saving, it is found that when the list is checked and then slid back, it is unexpectedly found that the state is not saved

Resolution process:

1) Think of this reason is because of the reuse of Convertview, when re-Converview, the original checked state is not saved, and is overwritten by the new data source, the key code is:

 if  (Convertview = = null   = Getlayoutinflater (). Inflate (            R.layout.city_list_item,  null  ); }checkbox selectedcheckbox  = = cityitems.get (position); // data is the data source                                       selectedcheckbox.setchecked (data.getselected ());                                                                                  // getselected () intended to read the save state  

View Reuse

It is later done by adding a isselected variable to the data source to record the selection value and to add a listener on the checkbox that triggers the Save event when checked:

1Selectedcheckbox.setoncheckedchangelistener (NewOncheckedchangelistener () {2 3 @Override4                  Public voidoncheckedchanged (Compoundbutton Buttonview,5                         BooleanisChecked) {6                     //TODO auto-generated Method Stub7                     8Cityitem c=Cityitems.get (position);9 c.setselected (isChecked);TenLOG.I ("Change2", "Change2" + "" "+c.tostring () +" "+isChecked); One                 } A                  -});

Monitor tick status change events

Note Here is a small detail, that is, the position variable is set to final when passed into the GetView, becomes a constant, bound to the listener event, when the tick state changes will refer to the original bound constants to set, so that corresponds to the actual data source;

2) Run again, found that there is still a problem, the state is still not saved, by running a breakpoint to find that the monitoring event is triggered, but the triggering of the occasion is not as perfect as we imagined, you will find the rewrite view when the listener event is also captured, why? Because "selectedcheckbox.setchecked (c.getselected ());" This method also changed the state value, was captured by the listener, we can understand the idea: the original view is bound to a data source (for testing convenience, put a data display in the list header), tick the binding event triggered, the value is saved, and then slide the interface, so that a data source bound view is reused, then " Cityitem C = cityitems.get (position); "Obtained is a new data source B, but at this time we executed the checkbox state setting statement, when the listener event is triggered, but the listener is still bound to the original position, the tragedy occurred, a data source of the state is covered by the B data source;

At this point, the problem is obvious, because the position in the listener and the state change of the monitor is not necessarily consistent, resulting in confusion.

3) In the reading study of the Sunset City blog http://www.cnblogs.com/wujd/archive/2012/08/17/2635309.html on this aspect of the analysis, A solution was found: setting state statements after listening for events and reusing objects by swapping; I've been trying to figure out why it's possible at first. Later thought for a while finally understand, because the listener settings in advance in the state settings statement, so that each listener is guaranteed to bind the position and trigger the event of the same, even if later state settings triggered a state change event has been able to ensure that its own data source correctly displayed.

Learning and summarizing of Android Listview--arrayadapter