# CymChad/BaseRecyclerViewAdapterHelper: a RecyclerView adapter for multi-type lists > BRVAH wraps Android's RecyclerView.Adapter with a BaseQuickAdapter that handles multiple item types, load-more and item animations. It is aimed at Android teams that keep rewriting adapter boilerplate, and the 4.x line is built around ConcatAdapter compatibility. **CymChad/BaseRecyclerViewAdapterHelper** — BRVAH:Powerful and flexible RecyclerAdapter - Repository: https://github.com/CymChad/BaseRecyclerViewAdapterHelper - Website: http://www.recyclerview.org/ - Stars: 24,577 · Forks: 5,169 - Language: Kotlin - License: MIT - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/cymchad-baserecyclerviewadapterhelper ## The adapter boilerplate BRVAH removes RecyclerView gives you a clean, low-level contract: an adapter, a view holder, a view type integer and a bind method. It also makes you write the same scaffolding every time. A screen with a header, a few content rows, a section divider and a footer has four view types, a getItemViewType switch, a createViewHolder switch, and a bind method that casts the holder back to the right subclass. Add a loading footer and the type count grows again. Add a swipe-to-delete animation and you are writing ItemAnimator or ItemTouchHelper code on top. BRVAH, short for BaseRecyclerViewAdapterHelper, exists to absorb that scaffolding. The README calls it a "Powerful and flexible RecyclerView Adapter" and describes the 4.x line as splitting functionality into modules so that BaseAdapter itself stays simpler, with multi-type layouts made more flexible and up and down loading "greatly strengthened". The target user is an Android developer who already knows RecyclerView and does not want a framework that hides it. The library is Kotlin, MIT licensed, and the badge in the README states API 16 and above. ## How the 4.x module split and ConcatAdapter support work The most consequential design decision in 4.x is stated plainly in the README: it is "perfectly compatible with ConcatAdapter". ConcatAdapter is Android's own way of concatenating several adapters into one stream. If BRVAH adapters are ordinary RecyclerView.Adapter implementations underneath, you can compose a header adapter, a BaseQuickAdapter for the list body, and a footer adapter, each owning its own view types and its own diffing, instead of teaching one adapter to know about every row shape on the screen. That is the direction the 4.x rewrite took. Rather than one class with a large surface area, the README says functionality was split into modules, leaving BaseAdapter leaner. For adopters this changes the mental model: you stop asking "how do I make one adapter handle everything" and start asking "which adapters do I concatenate". The trade-off is that the composition lives in your Activity or Fragment rather than inside the library, so you need to be comfortable wiring ConcatAdapter yourself. The README does not document the individual module boundaries, so the practical way to see them is the repository layout, where library/ and demo/ sit side by side and the demo module is linked as the working reference. ## Installing BRVAH 4.4.1 from Maven Central The README states that v4 is published to Maven Central, so no third-party repository configuration is needed. The dependency line given in the README is the whole installation story: ```kotlin implementation("io.github.cymchad:BaseRecyclerViewAdapterHelper4:4.4.1") ``` Add it to the module that contains your list screens. 4.4.1 is the current release listed in the repository, published on 2026-06-26. The artifact group is io.github.cymchad and the artifact name carries the 4 suffix, which matters if you have an older BRVAH coordinate in the same build file: the 4.x line is a different artifact from the 2.x and 3.x versions, and the README keeps links to both older branches for projects that stay on them. No ProGuard configuration is required. The README says the library ships its own proguard-rules.pro, that the rules are imported automatically, and that normally you do not need to import them by hand. It also links the file in library/proguard-rules.pro if you want to read what is being kept. If you have a custom rules file that strips generic signatures or reflection targets, compare it against that file rather than assuming the defaults cover you. ## A first adapter and where the demo fits The README does not walk through writing an adapter. Its documentation section says "English Writing ..." and points 4.0 users at the project wiki, so the honest first step is to open the wiki page for the version you pinned and read it alongside the demo module. The demo is linked from the README as demo, and the repository ships demo/app-release.apk, so you can install the sample on a device and see the behaviours before writing any code. The README gives no adapter code, so there is no signature here to copy. The documented entry point is the dependency line above plus the wiki; the demo module is the working reference. What you should expect after wiring an adapter up is that view-type dispatch, holder creation and the loading footer are handled by the base class, and that your code is limited to the bind body plus whatever click or animation behaviour you attach. Because the README only gives the dependency line and links, treat any signature you find in a blog post as unverified until it matches the wiki or the demo for your version. ## Where BRVAH is the wrong choice The library assumes you are using RecyclerView and are willing to inherit from its base classes. If your list is a Compose LazyColumn, none of this applies: BRVAH is a View-system library, and the README says nothing about Compose interop. Migrating a screen to Compose means dropping BRVAH from that screen entirely, not wrapping it. The second constraint is documentation language. The README is bilingual in places, but the 4.0 documentation link is the Chinese wiki, and the English section is a placeholder reading "English Writing ...". A team without Chinese readers will be working from the demo source and the API surface. That is workable for a small adapter library, but it is a real cost when you hit an edge case in load-more behaviour or animation, because there is no English prose to fall back on. The third is version fragmentation. The repository still maintains 2.x and 3.x branches with their own documentation, and the 4.x API is a rewrite rather than an extension. If you inherit a codebase on 3.x, upgrading is a migration, not a version bump, and the README does not offer a migration guide. Staying on 3.x is a legitimate choice; the README explicitly says you can continue to use it. ## BRVAH against FastAdapter and plain RecyclerView FastAdapter, which appears in the related searches alongside BRVAH, takes a different route to the same problem. Its model is an item-level one: you define item classes that implement its item interface, register type adapters for them, and the adapter is assembled from the items themselves. BRVAH keeps the classic shape instead, one adapter subclass with a layout resource and a bind method, and leans on ConcatAdapter for composition. If you like your list logic expressed as a set of self-describing item types, FastAdapter's approach fits better; if you prefer the adapter to stay a thin subclass next to your existing ViewHolder code, BRVAH is the smaller conceptual step. The third option is no library at all. A hand-written adapter with a view-type switch is maybe a hundred lines for a three-type list, and it has zero dependency risk, zero version migration and no documentation gap. BRVAH pays off when the list has many types, when you need the loading footer and empty view handled consistently across screens, or when item animations appear in several places. For a single static list, the library is overhead you will not recover. ## Maintenance, licensing and upgrade cost The repository is not archived. Its last push was on 2026-06-26, which is under six months before today's date, and the most recent release, 4.4.1, carries the same date. Before that, 4.4.0 landed on 2026-05-15 and 4.3.4 on 2026-02-27, so the 4.x line has seen three releases across roughly four months. That is a steady cadence for a library of this size, though the README itself notes that project members are busy and asks for patience, which is worth reading as a statement about response time rather than about release frequency. Upgrade cost is concentrated in the major versions. Patch releases within 4.x should be dependency-line changes, but the 3.x to 4.x step is the one to budget for, given the module split and the ConcatAdapter model. The README offers no migration notes, so a 3.x project should read the 4.x wiki before deciding. The licence is MIT, which permits commercial and closed-source use with the copyright notice and permission notice retained. That is the standard reading, not legal advice; check the LICENSE file in the repository for the exact text and confirm it against your organisation's policy. ## Conclusion Adopt BRVAH if your screens are full of hand-written RecyclerView.Adapter subclasses with view-type switches, footer loading states and animation code, and you are on API 16 or above. Do not adopt it if you want an adapter that owns its own data layer or if you need English documentation, because the README points to a Chinese wiki for 4.x. Before committing, verify the 4.4.1 artifact resolves from Maven Central in your build and confirm that the 4.x API surface matches the wiki page for the version you pin, since the README itself documents almost nothing beyond the dependency line. ## FAQ ### What is BaseRecyclerViewAdapterHelper used for in Android? It is a RecyclerView adapter library. The README describes it as a powerful and flexible RecyclerView Adapter, and the 4.x line adds compatibility with ConcatAdapter plus multi-type layout support and up and down loading. ### How do I install BaseRecyclerViewAdapterHelper in a Gradle project? Add the dependency implementation("io.github.cymchad:BaseRecyclerViewAdapterHelper4:4.4.1") to your module. The README states that v4 is on Maven Central, so no third-party repository configuration is needed, and that ProGuard rules are imported automatically. ### Does BaseRecyclerViewAdapterHelper require manual ProGuard rules? No. The README says the library comes with proguard-rules.pro rules that are automatically imported, and that normally no manual import is required. The rules file is also viewable at library/proguard-rules.pro. ### Can I still use BRVAH 2.x or 3.x instead of 4.x? Yes. The README says you can continue to use the 2.x version and links the 3.x documentation as well. The 4.x line is a separate artifact on Maven Central, and the README does not provide a migration guide between the major versions. ## Sources - [CymChad/BaseRecyclerViewAdapterHelper on GitHub](https://github.com/CymChad/BaseRecyclerViewAdapterHelper) - [License: MIT](https://github.com/CymChad/BaseRecyclerViewAdapterHelper/blob/master/LICENSE) - [Project website](http://www.recyclerview.org/) - [README](https://github.com/CymChad/BaseRecyclerViewAdapterHelper/blob/master/README.md) - [Releases](https://github.com/CymChad/BaseRecyclerViewAdapterHelper/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cymchad-baserecyclerviewadapterhelper