想问问现在用 kotlin 写 android 的多吗

[whitepoppy]

class InTheVehicleFragment : FragmentCompat() { private val presenter = InTheVehiclePresenter(this)

companion object {
    fun newInstance(): InTheVehicleFragment {
        return InTheVehicleFragment()
    }
}

override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
    return inflater.inflate(R.layout.fragment_in_the_vehicle, container, false)
}

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    presenter.setup()
    initView()
    initListener()
}

private fun initView() {
    //setInCarNum(25)
}

private fun initListener() {
    container_add_car_plate_num.setOnClickListener { presenter.gotoAddCarPlate() }
    container_car_open_order.setOnClickListener { presenter.gotoSerOrder("") }
}

fun httpError() {
    rcv_today_cars.visibility = View.GONE
    container_loading.visibility = View.GONE
    container_fail.visibility = View.VISIBLE
    container_fail.setOnClickListener({
        presenter.fetchHistoryCars()
    })
}

fun httpSuccess() {
    rcv_today_cars.visibility = View.VISIBLE
    container_fail.visibility = View.GONE
    container_loading.visibility = View.GONE
}

fun setTodayRv(mAdapter: InTheVehicleAdapter) {
    rcv_today_cars.setupVertical()
    rcv_today_cars.adapter = mAdapter
}

fun nodify() {
    rcv_today_cars.post {
        rcv_today_cars.adapter.notifyDataSetChanged()
    }
}

}

写的我好难受啊

[loshine1992]

@whitepoppy #20

不爽就写 Java 啊，又不是不能混编，能过 Code Review 就行。

[sampeng]

kotlin 是唯一一个改善让我觉得 java 系还能一战的语言。

每个特性都是为了节省时间和吸收其他现代化语言设计的。。每个特性都爱不释手。。。

用 kotlin 和用 java 的思维去写代码不知道哪里冲突了。。。。。。

ps：lz 写的还蛮好的啊。。。

[whitepoppy]

@loshine1992 那倒是好了哦 关键不让啊 非要按他的要求写 天天还沾沾自喜 233

[storypanda]

让我想起了我当时选择 Swift 和 OC 的抉择，但 Android 自学我选择 Java

[GoodRainChen]

@icris
首先，我没打算否认 kotlin 的代码更加简洁，有他的先进性（当然，我个人用着其实也不算太舒服，先搁置这个问题）
但是，这些便捷对于开发效率，正如我之前写的，提升没有想象中的显著。写过一段时间就会发现，kotlin 对于类型安全等方面的限制更加严格，把简化写法带来的优势抵消了不少。
相反地，便捷的语法、简化的语法糖，势必带来代码阅读需要更多的思考，哪怕你觉得微不足道，但是积累起来也是影响效率的。毕竟你看代码思考要转个弯，没有 java 那么傻瓜（直白）。举个例子，B.setXXX(A) 简化成 B.XXX = A，代码上 set 改成了=,省不了两个字符，但是屏蔽了 setXXX 是个 method 的事实，也许别人就在这个 setXXX 里做了计算逻辑，你看代码的时候很容易不小心漏过去。这只是个例子，你可能有办法反驳我，但是我希望我的意思能传达到

[xd314697475]

官方没支持时就在用了，比 java 爽吧

[loshine1992]

@whitepoppy #23

要么写，要么炒 boss 咯，你们两个三观不合无解的啦。

PS：Kotlin 就是比 Java 好。

[whitepoppy]

@loshine1992 什么 boss 都是搬砖的

[whitepoppy]

@xd314697475 不爽 我感觉差别不大

[lucky2javascript]

现在用 flutter 写

[xiaoshenke]

不多 我就不用

[icris]

@GoodRainChen #25
从下往上说。
首先 getter setter 也不是 kotlin 首创，你可以观察观察 C# 程序员对 Java 的 set 方法什么评价。同时，方法调用者不需要也不应该关心方法内部逻辑。如果看一个 x.a = 1 你不知道里面有没有计算逻辑，那么如何知道 x.setA(1); 里面有没有计算逻辑？如果一样不知道，这一项打平没毛病吧？
那么便捷的语法对代码阅读需要的思考量会增多吗？我觉得会减少。对于语句 x.toJson() 和语句 objectMapper.writeValueAsString(x) ，哪一个能一眼看出在做什么？
再往上，类型安全限制，就是非空呗？首先自己写的 kotlin 方法和属性能不能空完全自己控制，Java 代码没有明确注解的都是 String! 类型，做不做检查都不会报错，Java 代码标注 Nullable 的你写 Java 不也得写一块儿检查？如果区别是 kotlin 必须检查而 Java 可以不检查让它运行时空指针，那我是只看出来好处。

但看起来楼主是来喷人的，在这讨论这些意义不大。

[GoodRainChen]

@icris
“如果看一个 x.a = 1 你不知道里面有没有计算逻辑，那么如何知道 x.setA(1); 里面有没有计算逻辑”。
x.setA(1)更接近本质，而 x.a = 1 是封装了一层的简化版本。实际工作中不关心他人代码的内部逻辑是很难的，场景很多：比如新人入职、新接手模块，又或者做 review，又或者定位问题，尤其是小团队或者小组负责人，每个人都必须对项目整体了如指掌。屏蔽越多本质上的细节，意味着越容易让人的思维被误导

第二点其实就是说到了这个 kotlin 麻烦的地方，目前 Android SDK 就是用 java 写的，kotlin 自己玩，对于空值的保护确实不错。但是带上 Java 写的 AndroidSDK，就有了不少的麻烦，两种语言之间的类型转换让事情变麻烦了

再说下去有点类似争 XX 语言天下第一了。我也觉得意义不大。

所以我再总结一下我的观点，kotlin 不坏，但是似乎没有好到顶着招聘和学习成本去强制引入它，尤其是如果其他同事不喜欢 kotlin，那更是带来内部矛盾，得不偿失

[mmdsun]

没有本质变化。Java13 估计 var 携程 扩展函数 都会有了

[icris]

@GoodRainChen #33
第二点我觉得我已经说清楚了，我再试着解释解释。注解 Nullable 的，具体举例
protected void onCreate(@Nullable Bundle savedInstanceState)，
它在 kotlin 里调用的时候提示是
onCreate(savedInstanceState: Bundle?) ，
注解了 NonNull 的
public void onSupportActionModeStarted(@NonNull ActionMode mode)，
它在 kotlin 里调用的时候提示是
onSupportActionModeFinished(mode: ActionMode)，
没注解的，具体举例
public void setContentView(View view) ，
它在 kotlin 里提示是
setContentView(view: View!)，
无论哪一种，正常逻辑都跟 Java 里调用是一样的流程（ Java 用的 if 逻辑 kotlin 也能用，kotlin 的 ? 逻辑 Java 不能用，这一条显然是 Java 更麻烦 ），非正常逻辑下区别是调用 onSupportActionModeFinished(null) 在 Java 里可以正常编译等运行时报空指针，Java 里的 onCreate 里面可以直接用 savedInstanceState 而不需要判断非空等第一次打开 Activity 报空指针。我觉得这个能力真是毫无用处。

第一点，就按你的需求来，在 Java 中，如果你要看 setXXX 内部逻辑，你要看到一个 setXXX 就点进去看看；在 kotlin 中，同样的需求，你可以看到一个等号就点进去看看；如果 Java 里这个 setXXX 是 Lombok 生成的，甚至点进去看的时候都同样跳转到声明处。我没感觉出来区别。

[GoodRainChen]

@icris

就以 setContentView(view: View!)为例
假设这个 setContentView 是我写的，我明确知道 view 逻辑上根本不可能为 null，但是在这里被转换成了 View!类型，是不能和 View 通用的，我得加一步转换，否则每处用到这个 view 的地方都要加"？"来处理。

而在原本的 java 里，我这里不需要任何额外操作

[icris]

@GoodRainChen #36
首先，你这个逻辑是错的。setContentView 是你写的，那是谁在调用 setContentView ？你自己调用你知道，团队成员调用你也知道？他们调用传个 null 进来，你是不是要崩？
而此时如果你们用 kotlin，这个方法就可以是 setContentView(view: View) ，谁也不会传 null 进来。

其次，这个方法不是你写的，它本来就可以给个 null，如果你重写方法并不处理 null，总有第三方库会让它出错。

[GoodRainChen]

@icris
由外部保证参数的合法性，否则直接崩溃反而比较好。就像有些方法判断参数合法性，不合法直接扔一个参数不合法的异常出来，直接崩了。这是很常见的一种模式。
那我再换个，不是入参，是返回值，比如 xxx.toString() 从 Java 拿过来 String!，明明可以确认这玩意儿不可能为空，还是要判空，不是给人添麻烦吗？

[icris]

@GoodRainChen #36
等等，你好像挖了个坑给我，标注 ! 的东西作为方法返回值类型时在 kotlin 里根本不需要判断非空也不需要加 ? 调用，作为参数重写的时候可以自己选择加不加可空，你说的不能和非空类型通用的是 savedInstanceState 这样的 Nullable 的 东西

[theworldsong]

公司项目使用。全线在用。