Closed Reginer closed 11 months ago
尝试修改的过程中,发现了很多问题,例如 BaseSingleItemAdapter
这种类型的,items 是一个空数组,onBindViewHolder
中获取 item 必定为 null
在BaseQuickAdapter里声明的items我看是emptyList(),问题多应该是从开始设计的时候就把它设计成可空,而用到的地方又太多到导致的吧。 这是我提的建议,因为在使用的时候可空一点儿也不方便,写demo的时候也总是有警告,要不就加if (item == null) return,实际使用的时候,我都还从没遇到过显示出来的item有是null的时候。 能修改的话尽量修改一下呀
我在修改为非空的时候,发现先改BaseQuickAdapter类之后,再改 BaseSingleItemAdapter就容易很多
定义成非空,会丧失灵活性,还是用 BaseSingleItemAdapter
举例,对于此Adapter就是一个空数组,但是有 item 数量。这种情况下 BaseQuickAdapter 如果直接 items[position]
会造成问题。
除非 items 中的数据和 item 数量是对应的,也就是说 items 必须是有意义的。但是对于某些自定义 Adapter, items 就是无意义的,你可能有不同的内容要手动实现
这个不是修改困不困难的问题,而是考虑到更多场景的通用问题
实际使用过程中,RecyclerView的item也不会为null的吧,为null直接崩溃这也无所谓吧。
item为null的情况毕竟太少了或者说没有,为了这么点儿需求其他人都要写一堆多余代码不方便吧
设置数据之前,开发可以自己将null处理成实体类对象。自己可以实现null的UI表现,而不是靠item为null。
你还是没有理解我的意思啊,是自定义 Adapter
的时候,有的时候 items 就是没有意义的,根本不需要从里面取数据。
比如 position = 0
的时候是一个 header,header之下的才是 items。这个时候 position == 0
的就不需要从数组拿出有意义的数据
也就是说这个null的数据其实不是开发用的,是你用的 ?
暂时理解不了,能把onBindViewHolder回调的数据非空最好,我和大多数人没有可空的需求。
也就是说这个null的数据其实不是开发用的,是你用的 ?
不是我用,基类里 onBindViewHolder
获取 item 要么是可空,要么不可空。如果不可空, Adapter 的自定义就会问题,就像我上面说的,position == 0
的 header,你取出来是啥?是不是 null?
BaseSingleItemAdapter
就是一个最简单的例子。
这涉及到理解误差了吧,position == 0我希望获取到的肯定是我传的list的第一个数据,而不是那个header,我获取header干啥
这涉及到理解误差了吧,position == 0我希望获取到的肯定是我传的list的第一个数据,而不是那个header,我获取header干啥
在Base里,我只管去数据,至于数据是啥,我也不清楚,那是业务上的。在讨论的例子中,header 不在 items 里,那作为基类咋知道呢。那这段代码该怎么改?请赐教
final override fun onBindViewHolder(holder: RecyclerView.ViewHolder, position: Int) {
if (holder is EmptyLayoutVH) {
holder.changeEmptyView(emptyView)
return
}
onBindViewHolder(holder as VH, position, getItem(position))
}
还有个例子,Adapter 显示空布局的时候,这里也会拿到 null
我可算大概了解你说的什么了,这是设计问题吧,添加的头布局脚布局空布局怎么还能跑到这个回调里去了,这个回调是给adapter显示数据用的啊。 对,你说用ConcatAdapter重构了,但是其实在使用上我们不关心。 头Adapter回调它的onBindViewHolder和内容Adapter回调它的onBindViewHolder都是非空的,头Adapter和内容Adapter他们可以定义一个自己的类型叫AbcEntity,它们都是非空的。 头内容和尾以及空布局,它们用一个类型,而不是和内容Adapter混一起吧。
这个代码也不需要改呀,它本身就是非空的,可空的也没回调呀。这里的getItem(posttion)又不会是null
哎~你还是没明白,算了。BaseSingleItemAdapter
就是一个例子,这就是一个自定义数据的情况,使用 Base 里的 items。你琢磨琢磨吧。
这种情况下, items 里面是空的啊,取出来肯定是 null 啊,如果在 Base 里就把 null 排除掉,那子类的 onBindViewHolder 走都不会走啊。
再一个,这个本身没啥问题,使用方写一个 if (item == null) return
并不是什么不优雅的问题。空判断本身就是一个常规操作,只是 kotlin 把空指针问题放到台面上了,强制让你注意。防御性代码本身没错。
肯定不优雅啊,谁喜欢加这种本来不需要的代码,哪有人会把rv的item搞成null的,你也先别急着拒绝,之后总有办法改。
有没有明白取决于我们想不想明白,我们只是不明白你为什么把绘制item回调搞成可空。
我们不在乎你框架的限制,限制的可空那是你框架的问题,我们只想回调的时候不可空。
如果说回库的设计。如果要做到完美,那就只能用系统的 api 了
fun onBindViewHolder(holder: ViewHolder, position: Int)
只给出 position
,怎么处理数据他不管,绝对的灵活性。
此项目为了方便,提供了 list ,做了一层包装,去取出了 list 多给到了一个 item:
fun onBindViewHolder(holder: ViewHolder, position: Int, item: T?)
这种带来了某种便利,但是本身也会丧失一定灵活性。如果处理的数据不来自 list 里,那这里的封装就是多余的,提供的 item 也是无意义的,必定是 null 的
肯定不优雅啊,谁喜欢加这种本来不需要的代码,哪有人会把rv的item搞成null的,你也先别急着拒绝,之后总有办法改。
有没有明白取决于我们想不想明白,我们只是不明白你为什么把绘制item回调搞成可空。
我们不在乎你框架的限制,限制的可空那是你框架的问题,我们只想回调的时候不可空。
那你大可不必纠结,直接用系统的 fun onBindViewHolder(holder: ViewHolder, position: Int)
, 想怎么取数据就怎么取
灵活性建立在方便性之上的,它本身如果不方便的话,何谈灵活性啊。 现在这种设计就不方便,现在讨论的是你库的设计吧,推荐我们用系统的我们还用库干嘛。 先冷静冷静,你可能是陷入到自己设计的误区,觉得这样实现就必须要可空,实际我们大家都觉得没必要,我在群里问过很多人,我们都没有item可空的需求。 你也统计统计,谁的item有可空的需求,大概多少,然后我们再来确认要不要可空。毕竟实现一个库一方面是兴趣,一方面是方便,一方面希望更多人认同。最后还是看作者的实现
灵活性建立在方便性之上的,它本身如果不方便的话,何谈灵活性啊。 现在这种设计就不方便,现在讨论的是你库的设计吧,推荐我们用系统的我们还用库干嘛。 先冷静冷静,你可能是陷入到自己设计的误区,觉得这样实现就必须要可空,实际我们大家都觉得没必要,我在群里问过很多人,我们都没有item可空的需求。 你也统计统计,谁的item有可空的需求,大概多少,然后我们再来确认要不要可空。毕竟实现一个库一方面是兴趣,一方面是方便,一方面希望更多人认同。最后还是看作者的实现
兄弟 群可以拉我一下吗 新手想跟大佬们学习 我v:anihczs
提供一个还算优雅的方案,单独处理需要null的情况,同时为头内容和尾以及空布局等case提供默认item为空的 SimpleSingleItemAdapter @Reginer @limuyang2
关于其中的item参数,在4.0.0版本上变成可空了,是否可以改回非空,以前讨论过这个问题 。
https://github.com/CymChad/BaseRecyclerViewAdapterHelper/issues/3001