乐征skyline

过去开发Android的时候，是一个非常常用的类，但是却用起来有些麻烦，于是就根据需要写了很多XXXAdapter之类的工具，也有很多开源可用的Adapter工具。如果只用一个，养成习惯后不成问题，但是如果比较多，就容易忘记或记错混淆。于是就有了一个想法：我能不能写一个不需要去记忆的工具，即便很长时间没用忘记了，也可以直接上手用。本文以为例，来分享我的思考和实现方式。

前面讲了kotlin的it变量引起的遮蔽问题，见，本篇聊聊作用域函数（scoped function）可能引起的遮蔽问题。这里涉及3个上下文：全局上下文、test函数局部上下文、also引入的上下文。不过这里涉及4个上下文：全局上下文、test函数局部上下文、apply引入的大括号之间的上下文，以及调用apply的字符串对象的对象上下文。两段程序极为相似，在词法和语法结构上光靠肉眼难以发现差异，但上下文环境却有着较大的差别。在我第一次学习到Kotlin的这个特性时，心里有些不安。

虽然在工程应用中没有遮蔽现象的发生是最好的，但上面的kotlin代码中这种显式的遮蔽也没有太大的危害，毕竟这种遮蔽发生在同段代码中肉眼可见的范围内（顶多代码较长的时候鼠标再滚一下），也不会因为外部程序的变化而影响到这段程序的语义。不过，在kotlin中存在的隐式变量it却很容易导致隐式遮蔽的情况发生。不管是标准库中的作用域函数（Scoping Function），但是一般的接受单参lambda作为参数的过程，使用的时候很可能省略唯一参数，那么就会发生上述情况。代码经过多人多次修改，就可能出现问题。

由于kotlin支持类型推导，所以很多时候变量的类型可以省略，但有时候省略变量类型又可能带来一些不便，甚至隐患。本文记录下一些“建议声明类型”、“可以省略类型”的场景。（暂时想到的不多，后续持续更新）

最近看到两段相似的代码，第一段是第二段为两段代码的差别仅在启动线程的位置。有时候写程序比较随意的时候，两种形式的代码都可以可能出现，下面记录下我对这种形式的一些想法。

最近看了篇关于新技术风险的文章，结合自身经历，反思并总结下项目中应用所谓“新技术”的一些想法。

对参数进行有效性检测看上去是在为安全考虑，但是却包含了一些隐患。文本就分享一些我对这类隐患的一些思考。

平时的Android开发中，我们经常要在Fragment中去获取当前的Activity实例，刚开始的时候可能使用使用Fragment提供的getActivity方法来获取，但是这个方法可能返回null，本文分场景分别介绍几种优化的方式。

最近在开发中遇到一个关于Java方法重写的一些问题，对于方法重写的用法以及可能导致的问题产生了一些思考，本文用于记录下这些想法。

随着集成开发环境越来越强大，编程开发工作也变得越来越高效，很多的代码都不需要逐字输入，可以利用代码生成和自动补全来辅助开发。但是这样的便利也可能引起一些疏忽，本文就Java开发中默认生成的接口实现方法来谈谈以前遇到的问题。

前言随着近几年新语言（例如，rust、kotlin、dart等10后的语言）的出现，经常有同事问起“最近有个xx语言挺火，你怎么看”这类问题。这种情况下，一般都不太想回答（根本不知道从哪说起…）。平时身边的同事中是某个语言的用户或者说是依赖/利用某个语言来完成工作的居多，把某个语言用得如手脚般灵活的极少，把自己擅长的语言控制得如手术刀那样精细的更少，每次自己写的程序出了问题5分钟都查不出原因，我会把这样的情况归结为–程序失控了。没有办法，工作中很多时候都是赶鸭子上架，两天学一个语言，一天学框架，然后直接做