这不是一个问题

[uni-cstar]

这不是一个问题，而是对于一些框架设计希望能够跟作者做一次交流；

作者说这个框架是比brvah更简单的框架，个人理解的这个简单是使用简单，功能全面，但其实比较繁杂。所以我有更好的封装建议想与作者进行一次沟通 引用之前在群里说过的话： 也就是你抛开一个数据适配器以外的东西，才是扩展能力，任何一个数据适配器应该是独立的，所以我是觉得从两方面去考虑能力的实现， 第一个问题是如何快速构建数据适配器：基于用户业务场景的数据实现的适配器：常规适配器、分组适配、树状适配器等

第二个问题是如何为数据适配器或者现有的数据适配器赋能：提供开放能力，比如增加header、footer、loadmore、itemAnimation等

期待作者回复，本人qq号：862638161

[liangjingkanji]

我提到的更加简单是指的 使用方式(三行代码创建列表), 源码结构(没有那么多接口实现), demo示例代码(50行代码作用) 更加简单

1. 功能是可以组合的, 不存在需要区分适配器实现类, 例如分组功能难道不能和树状一起使用吗?

2. 你提到的功能都支持, 至于loadMore这个完全交由更加强大的SmartRefreshLayout实现

我不太清楚你要改进或者建议的问题是什么? 希望根据功能不同拆分适配器?

[uni-cstar]

我不是说功能上存在什么缺陷，而是说结构上可以进一步优化； 举个例子，假如我们使用concatAdapter来封装会是什么效果，也就是说如果我把bindingAdapter变成一个concatAdapter，那么像header、footer、loadmore、以及empty、loading之类的功能实现都会变成独立的实现，而不是糅杂在一个bindingAdapter中。而用户的数据adapter具体是什么样子，与这部分逻辑就无关联了

[uni-cstar]

再举个实际例子，对于历史项目，或者java项目，现在业务已经写完了，现在想要接入一个header、footer或者其他功能，是不是得改历史的数据adapter？如果要使用brv这个库，是不是得换实现改父类？那有没有办法在现有情况下为已经存在的adapter赋予这些能力呢？那么也就是concatadapter实现的。其实我是很久没接触brvah之类的库，最近在自己封装一个，大体结构已成，恰好群里有群友提到你这个库，我因此做了对比，思考了一些问题，所以我是觉得如果您这边可以做交流，那么无论是我或者您对库做调整可能都会让他更趋近于“产品级”的思维。

[liangjingkanji]

加入ConcatAdapter来实现这个问题我也考虑过, 本身BindingAdapter就支持Concat但是没有更好的优化, 而且后面因为有点忙或者本身工作量有点大不了了之了(我不止维护一个仓库)

不过我也认为会更好, 欢迎一起讨论研究, 本项目一直会保持开源社区精神

[uni-cstar]

就是这个意思，其实我目前已经做了一个大的架子，感觉还不错，恰好群友提到你这个库时，我分析了下你的实现结构，但是也确实觉得你这个库的功能已经足够全面了，我这边目前只是没有重点提供更为快速的构造数据item那部分的逻辑：就是您这边通过数据类型转换成viewholder的这部分逻辑，因为目前我考虑的是要为历史的adapter“赋能”，在此之后再提供更为快捷的方式创在用户使用的“数据适配器”；方便发我一个您的联系方式么？我可以给你看下目前我这边封装觉得比较好的点

[liangjingkanji]

README有QQ群, 大家一起讨论更好