1. 题外话那段挺感兴趣的,一直很好奇别人做一个有趣的库的思考路径,还有陷入困境时是怎么走出来的,博主有空的话分享一下呗?感激不尽

  2. 楼主你好,看完代码,感觉部分地方还可以再优化一下,类似Provider的设置,是不是可以直接由data来提供。前段时间写了一个ListView和RecyclerView兼容的Adapter框架,希望能有机会多交流一下https://github.com/wangsai-silence/EasyAdapter

  3. 楼主的想法跟AdapterDelegates的思想大同小异,github:https://github.com/sockeqwe/AdapterDelegates

    • 我没仔细看这个库,但扫了一眼,是很大不一样的,用法完全不一样,我觉得它搞得很乱。定位也完全不一样,我的定位并不是要取代 RecyclerView Adapter 什么的,而是 Multiple types for page,不是 for RV or its Adapter

      • 我说的思想大同小异是指每个Item的provider只要写一次就可以了,每次组装一个page的时候只需将数据源组装好,adapter就会根据数据源来找到对应的provider来展现和控制UI了。你这里的multiple types for page,无非就是指多个page,多个RV。这种“组合优于继承”的理念,我觉得跟我上面发的库是一个理念的,所以提出来探讨下。我觉得最大的差异就是你是用一个静态pool来管理这些provider,然后一个MultiTypeAdapter作为通用Adapter,而上面那个库是用delegateManager来管理它的delegate,然后每个RV需要定义一个Adapter来实现delegateManager注册delegate。我的理解是,你是统一了注册入口,静态注册。而他的做法是开放注册入口,每个Adapter去动态注册。

  4. 看了下楼主的库,觉得这种分离的想法真的太好了-V- 我在仿写票圈项目时在简书也写过,adapter应该作为数据分发和视图连接,具体渲染,操作反馈等逻辑应该交给viewholder。。。(不知道想的对不对orz)近期重构那个项目,也是采用了之前listview的经验,用rv来干,,不过跟楼主不同的是,我采用的是反射创建orz…..我的想法是一般情况下itemType到10就已经是很牛逼了,虽说反射不太好,但我还是选择了反射- -(因为只有几个type…)这是我最近在干的。。。https://github.com/razerdp/FriendCircle/blob/main-dev/app/src/main/java/razerdp/friendcircle/ui/adapter/CircleMomentsAdapter.java对于外部而言采用的builder,所以我的写法是这样的:主要逻辑集中在vh里面。最近想着优化一下这个东东,于是就看到楼主的库了-V- 前来观摩

  5. Pingback: Android 复杂的列表视图新写法: MultiType 详解篇 | Drakeet的个人博客

  6. Pingback: Android 复杂的列表视图新写法: MultiType 详解篇 - 爱好博客

  7. 如果我是同一个对象通过int类型的type进行区分不同的view视图,该如何改呢?是不是要覆盖父类里面的getItemViewType,岂不是又回到了原点?

  8. 博主,有个问题想不太明白,请教一下 MultiTypeAdapter.applyGlobalMultiTypePool的时候是把全局类型池中的类型注册给了局部的,但是有时候只会使用部分的全局类型,这样全部注册一遍,是不是有点浪费,觉得加个unregister方法