listview的使用
这篇讲在koltin中如何使用listview，跟java代码比起来又会有哪些不同呢
先用java代码创建一个bookAdapter.继承自BaseAdapter，实现那固定的几个方法，贴一下代码：
public class BookAdapter2 extends BaseAdapter {
private List<Book> books = new ArrayList<>();
@Override
public int getCount() {
return books.size();
}
@Override
public Object getItem(int position) {
return books.get(position);
}
@Override
public long getItemId(int id) {
return id;
}
@Override
public View getView(int position, View convertView, ViewGroup container) {
ViewHolder viewHolder;
Book book = (Book) getItem(position);
if (convertView == null) {
convertView = LayoutInflater.from(container.getContext()).inflate(R.layout.view_book_list_item, container, false);
viewHolder = new ViewHolder(convertView);
convertView.setTag(viewHolder);
} else {
viewHolder = (ViewHolder) convertView.getTag();
}
viewHolder.author.setText(book.getAuthor());
viewHolder.name.setText(book.getName());
return convertView;
}
static class ViewHolder {
TextView author;
TextView name;
ViewHolder(View itemView) {
author = itemView.findViewById(R.id.author);
name = itemView.findViewById(R.id.name);
}
}
}
adapter里面最关键的代码就是getView了。那我们看看转换成kotlin之后改怎么写，笔者这里没有使用一键转换，有点不太靠谱，还不如自己手敲，看一下得到的最原始的代码
override fun getView(position: Int, convertView: View?, container: ViewGroup): View {
val data = getItem(position) as Book
val view: View
val viewHolder: ViewHolder
if (convertView == null) {
view = LayoutInflater.from(container.context).inflate(R.layout.view_book_list_item, container, false)
viewHolder = ViewHolder(view)
view.tag = viewHolder
} else {
view = convertView
viewHolder = view.tag as ViewHolder
}
viewHolder.name.text = data.name
viewHolder.author.text = data.author
return view
}
getView方法在转换为java方法的时候，override fun getView(position: Int, convertView: View?, container: ViewGroup): View{}后两个参数都是可空的，而且参数都是常量了，不能够当做变量用，这个地方得注意一下。
在这里，由于converView可能为null，而且是常量，不能修改值，那么原来的返回converView就不行了，得重新定义一个view，在convertView为空的时候加载布局，非空的时候把converView赋值给view。以上的代码写法，是初学使用kotlin的写法，但是代码看起来也还是清晰的。。
那么我们是否有办法修改优化呢，变得更加函数式风格一点呢。
override fun getView(position: Int, convertView: View?, container: ViewGroup): View {
val data = getItem(position) as Book
val view: View = convertView ?: LayoutInflater.from(container.context).inflate(R.layout.view_book_list_item, container, false).apply {
tag = ViewHolder(this)
}
(view.tag as ViewHolder).apply {
name.text = data.name
author.text = data.author
}
return view
}
直接看这么一段代码，这个就是我们做了一定程度的代码优化，是的看起来更加偏函数式编程，思路是直接对view赋值，根据converView是否为空做区分，不为空直接复制，为空的话，先加载布局同时执行apply{}代码块，设置viewHolder。
然后就是讲viewHolder取出来了，对控件进行赋值,思路其实跟最开始的koltin的思路是一样的，只不过代码风格上面变化了。
那么是否可以再进一步演进呢。
override fun getView(position: Int, convertView: View?, container: ViewGroup): View {
val data = getItem(position) as Book
return (convertView ?: LayoutInflater.from(container.context).inflate(R.layout.view_book_list_item, container, false).apply {
tag = ViewHolder(this)
}).apply {
(tag as ViewHolder).apply {
name.text = data.name
author.text = data.author
//this@apply.container.isSelected = selectedBooks.contains(data)
}
}
}
这样看起来就只定义了一个data常量，然后就直接return了convertView。显得挺简洁了。
当然了这样的代码看起来可能不是很直观，因为if条件不是很明显，没有java代码写出来的逻辑清晰分明，条件判断区分的很显眼。需要团队成员熟悉这种写法才好。初看这段代码几乎是一脸懵逼的，都不知道为啥这样apply{}.apply{}的嵌套代码，而且直接引用的是类属性，各种this之类的，不好好的分析代码，肯定会很困惑的，如果项目里面类似这样的代码多了，新成员刚接触肯定很不适应的。在这里就得扯远一点了，如何让代码变得清晰可读并且简洁？
个人有一些看法，清晰可读简洁，我觉得得从逻辑的角度上来说
逻辑上得清晰，无论是if条件判断，多重if/else判断，还是循环嵌套，递归，或者是其他的设计模式等逻辑上一定得清晰，读代码的人能够知道你是怎么区分的，依据条件是什么，是否分类的完善，逻辑跳转是否合理正常等。
代码可读性强，写出来的代码，让团队成员看着不困惑，就如同知名的开源项目那样，大神写出来的java代码，基本上做过java开发的同学都是能够看懂的，java语言决定了它的代码写出来的就是这样的套路，只不过在大神的手里，写出来可读性，逻辑性都很高。让人觉得代码写的很漂亮，很清爽。代码的流转执行过程比较符合正常人的思维习惯等，这样的代码容易给开发者一种亲切感
简洁，简洁还是得是逻辑上简洁，更多的时候不要过度沉迷于代码层面了，比如说，某某一个验证码控件，不同业务都有自己的特殊场景，这种情况下不好复用的话，就按业务拆离，不要为了节省代码，而将这两三个业务的代码都放在一起，而且还堆缠在一起，这样不太好，还不如为每一个业务做一个独立的封装，出现部分重复的代码是可以接受的，一定要记住，我们需要的是逻辑上的简洁，在举个例子形容，比如说图片加载组件picasso，或者是Glide等，我在项目中使用了其中一个，那么我需要考虑到以后存在换组件的问题而封装一个抽象层吗(当然了这个例子可能举的不好，但是这里我还是想说下这个)，我觉得是没有必要的，这种组件api已经足够简单了，使用也是极其方便，而且还很方面开发者扩展一些特殊的需求，比如说加载通知栏的icon等场景，使用组件原生api已经足够方便，足够简洁了，我觉得在做封装是没有必要的，等你真正觉得需要换的时候，半天到一天就换过来了，毕竟我也是做过这种工作，不觉得有多麻烦。更何况做的封装，不见的能够满足所有的场景，难道等不满足的时候在重新写一个新的方法吗，或者就是直接调用原生组件的api呢？ 反正我觉得没必要。这就是我的技术理念。
