kotlin开发经验谈5

listview的使用

这篇讲在koltin中如何使用listview，跟java代码比起来又会有哪些不同呢
先用java代码创建一个bookAdapter.继承自BaseAdapter，实现那固定的几个方法，贴一下代码：

public class BookAdapter2 extends BaseAdapter {
    private List 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
                    //[email protected] = selectedBooks.contains(data)
                }
            }
        }

这样看起来就只定义了一个data常量，然后就直接return了convertView。显得挺简洁了。
当然了这样的代码看起来可能不是很直观，因为if条件不是很明显，没有java代码写出来的逻辑清晰分明，条件判断区分的很显眼。需要团队成员熟悉这种写法才好。初看这段代码几乎是一脸懵逼的，都不知道为啥这样apply{}.apply{}的嵌套代码，而且直接引用的是类属性，各种this之类的，不好好的分析代码，肯定会很困惑的，如果项目里面类似这样的代码多了，新成员刚接触肯定很不适应的。在这里就得扯远一点了，如何让代码变得清晰可读并且简洁？

个人有一些看法，清晰可读简洁，我觉得得从逻辑的角度上来说

逻辑上得清晰，无论是if条件判断，多重if/else判断，还是循环嵌套，递归，或者是其他的设计模式等逻辑上一定得清晰，读代码的人能够知道你是怎么区分的，依据条件是什么，是否分类的完善，逻辑跳转是否合理正常等。

代码可读性强，写出来的代码，让团队成员看着不困惑，就如同知名的开源项目那样，大神写出来的java代码，基本上做过java开发的同学都是能够看懂的，java语言决定了它的代码写出来的就是这样的套路，只不过在大神的手里，写出来可读性，逻辑性都很高。让人觉得代码写的很漂亮，很清爽。代码的流转执行过程比较符合正常人的思维习惯等，这样的代码容易给开发者一种亲切感

简洁，简洁还是得是逻辑上简洁，更多的时候不要过度沉迷于代码层面了，比如说，某某一个验证码控件，不同业务都有自己的特殊场景，这种情况下不好复用的话，就按业务拆离，不要为了节省代码，而将这两三个业务的代码都放在一起，而且还堆缠在一起，这样不太好，还不如为每一个业务做一个独立的封装，出现部分重复的代码是可以接受的，一定要记住，我们需要的是逻辑上的简洁，在举个例子形容，比如说图片加载组件picasso，或者是Glide等，我在项目中使用了其中一个，那么我需要考虑到以后存在换组件的问题而封装一个抽象层吗(当然了这个例子可能举的不好，但是这里我还是想说下这个)，我觉得是没有必要的，这种组件api已经足够简单了，使用也是极其方便，而且还很方面开发者扩展一些特殊的需求，比如说加载通知栏的icon等场景，使用组件原生api已经足够方便，足够简洁了，我觉得在做封装是没有必要的，等你真正觉得需要换的时候，半天到一天就换过来了，毕竟我也是做过这种工作，不觉得有多麻烦。更何况做的封装，不见的能够满足所有的场景，难道等不满足的时候在重新写一个新的方法吗，或者就是直接调用原生组件的api呢？ 反正我觉得没必要。这就是我的技术理念。