标签:
问题:当ListView选定的ListItem视图中存在一些UI组件,如CheckBox,出于对状态保存的期望,发现当勾选后将列表往下滑再滑回去时,意外地发现状态没有保存
解决过程:
1)思考后想到这个原因是因为重用了convertView,当重用converView时,原先勾选的状态没有保存,又被新的数据源覆盖,重点代码为:
if (convertView == null) { convertView = getLayoutInflater().inflate( R.layout.city_list_item, null); } CheckBox selectedCheckBox = (CheckBox) convertView .findViewById(R.id.isSelected); CityItem data = cityItems.get(position); //data是数据源 selectedCheckBox.setChecked(data.getSelected()); //getSelected()意欲读取保存状态
后来的做法是在数据源中添加一个isSelected变量,来记录选择值,并在checkBox上添加监听器,当勾选时触发保存事件:
1 selectedCheckBox.setOnCheckedChangeListener(new OnCheckedChangeListener(){ 2 3 @Override 4 public void onCheckedChanged(CompoundButton buttonView, 5 boolean isChecked) { 6 // TODO Auto-generated method stub 7 8 CityItem c= cityItems.get(position); 9 c.setSelected(isChecked); 10 Log.i("change2","change2"+" "+c.toString()+" "+isChecked); 11 } 12 13 });
注意这里有个小细节,就是传入getView时将position变量设置为final,变成一个常量,绑定到监听事件中,当勾选状态改变时会引用原先绑定好的常量去设定,这样就对应到了实际的数据源;
2)再次运行时,发现还是有问题了,状态依旧没有保存,通过跑断点发现监听事件是有触发的,但是触发的场合并没有我们想象的那样完美,你会发现重写视图时该监听事件也是被捕捉到了,为什么呢?因为 "selectedCheckBox.setChecked(c.getSelected()); "这一方法也是改变了状态值,被监听器捕捉到了,理下思路我们也就能明白了:原先视图绑定了A数据源(为测试方便,将A数据展示放在了列表头),勾选绑定事件触发后,将值存入,然后滑动界面,使得A数据源被绑定的视图被重用,这时 “CityItem c = cityItems.get(position); ” 获得的是新的数据源B,但在这时我们执行了CheckBox的状态设置语句,此时监听事件就被触发了,但监听器中绑定的依旧是原先的position,悲剧就发生了,A数据源的状态被B数据源覆盖了;
这时问题就很明显了,因为监听器中绑定的position与监听到的状态改变不一定一致,导致错乱。
3)在阅读学习了日落城的博客 http://www.cnblogs.com/wujd/archive/2012/08/17/2635309.html 关于这方面的解析,找到了解决方案:那就是通过交换设置监听事件和重用对象后的设置状态语句;一开始一直想不明白,为什么可行?后来想了一阵子终于明白了,因为监听设置提前于状态设置语句,这样每次的监听都被保证绑定了的position与触发事件的项一致,哪怕后来状态设置时再次触发了状态改变事件也已经能保证是自身的数据源正确显示。
Android之ListView——ArrayAdapter的学习与总结
标签:
原文地址:http://www.cnblogs.com/lhppom/p/4903178.html