BGABaseAdapter-Android shares one Adapter pattern across ListView and RecyclerView

Two list widgets, one set of helpers

Android has two eras of list UI and the code for them is almost identical but not quite. BGABaseAdapter-Android exists to smooth over that, and the description says it plainly: it provides a common Adapter and ViewHolder for AdapterView and RecyclerView.

The library is built from a small number of named pieces. BGAAdapterViewAdapter and BGAViewHolderHelper simplify writing adapters for AdapterView subclasses such as ListView and GridView. BGARecyclerViewAdapter and its helper cover the RecyclerView case. BGABindingRecyclerViewAdapter and BGABindingViewHolder are the same idea for RecyclerView used with DataBinding. BGADivider handles item decoration, and BGARVVerticalScrollHelper scrolls a RecyclerView to a given position.

The class names carry the design. There is one adapter base per widget family, one helper per family, and a separate binding pair for the DataBinding case, which keeps the data binding concerns from leaking into the plain ViewHolder version.

For the audience, that means an Android developer whose codebase still has ListView and GridView screens next to newer RecyclerView screens, and who does not want to maintain two adapter idioms. The library is published to Maven Central under the artifact cn.bingoogolapple/bga-baseadapter, so it is consumed as a normal Gradle dependency rather than by copying source.

The README's own guidance on where to learn the API is worth repeating: it points at the demo project rather than at a prose tutorial, with the comment that code is the best teacher. The demo contains separate example files for each capability, which is the fastest way to see how the pieces fit.

Header and footer index arithmetic handled inside the library

The detail that most distinguishes this library from a plain adapter base class is what happens to the position indexes in callbacks.

When a RecyclerView has headers and footers attached, the position reported to item click listeners, long click listeners and the data set accessors is offset by the number of headers. The usual result is that every consumer writes the same subtraction, and gets it subtly wrong whenever the header count changes. The README states that the index positions in the callback interfaces are already handled inside the library and that the developer does not need to subtract the number of headers themselves.

That is a small decision with a large effect on the code around it. A callback that receives a business-level index can be passed straight to a repository or a view model, and a change in the number of headers does not silently break every listener in the app. The same support is described for the DataBinding variant, so the two are consistent.

The capability itself comes from a credited source. The acknowledgements section states that the header and footer support for RecyclerView was modelled on the hongyangAndroid/baseAdapter project, and the drag-to-reorder feature was modelled on iPaulPro's Android-ItemTouchHelper-Demo. Both credits are about behaviour that Android's own RecyclerView does not provide out of the box, which is the gap this library is filling.

Multi item type support is listed for the RecyclerView adapters as well, so a list can mix row layouts under one adapter, and the library handles the type dispatch rather than leaving a chain of instanceof checks in the view holder.

Dividers, sticky headers and the two-list linkage demo

BGADivider is the piece that goes beyond adapter plumbing. It is used to simplify writing RecyclerView dividers, and it is also the mechanism behind a sticky category index, the effect where a category header floats above the list as you scroll.

The README shows that in a set of animated demonstrations. There is a pair of gifs for the AdapterView case, one showing a simplified GridView and ListView adapter, and one showing RecyclerView with headers, footers and drag sorting. Separate gifs cover RecyclerView with multiple item types and the sticky category index, and a fifth shows a left and right cascading layout in the style of a food delivery ordering screen, where choosing an item on one side updates the other.

That cascade example is worth noting because it is a recognisable product pattern rather than a library feature, and the repository points at the corresponding demo file, RvCascadeFragment, so the implementation can be read. The point of listing it is that the demo is the documentation: the prose section of the README is short and links out to the sample files for every capability, including the plain RecyclerView adapter, the DataBinding fragment, the sticky divider fragment and the cascade fragment.

The sticky index also has a practical constraint worth remembering. It depends on the divider knowing where the category boundaries are, so the item data has to carry that grouping information. It is a decoration, not a data source, and the library is not going to infer categories for you.

Drag ordering and scrolling to a position

Two smaller capabilities round out the RecyclerView side, and both address things that look simple and are annoying to get right.

Drag and drop reordering is included, with the README crediting the ItemTouchHelper demo project as the reference. ItemTouchHelper is the framework class that makes drag gestures work in a RecyclerView, and what is borrowed from the referenced project is the behaviour of letting a row be picked up and moved. For a list of items the user can reorder, such as a playlist or a set of pinned entries, this is the part of the adapter that has to cooperate with the gesture handling, and having it in the base adapter means the subclass does not have to reimplement the same movement logic per screen.

BGARVVerticalScrollHelper is for the other problem, scrolling a RecyclerView to a specified position. The need appears whenever a list has to be opened at a particular item rather than at the top, for example when a user returns to a screen and expects to be where they left off, or when an item is selected elsewhere and the list has to bring it into view. Doing that by hand involves finding the layout manager's current scroll offset and adjusting for the item's position, which is exactly the sort of code that is copied between projects and rarely documented.

Neither capability is dramatic on its own, and both are the kind of thing that makes a screen take a day longer than planned when it is written from scratch.

Adding the dependency and the AndroidX requirement

The dependency is a single Gradle line, and the README notes that the library has migrated to AndroidX with a minimum SDK of 21, and that the consuming project has to enable AndroidX with the setting android.useAndroidX=true.

implementation 'cn.bingoogolapple:bga-adapter:latestVersion'

The example uses the placeholder latestVersion, and the Maven Central badge points at the artifact page for cn.bingoogolapple/bga-baseadapter, which is where a real version number would go. That distinction matters for a production build: a floating version tag means the resolved code can change without any change in your repository, so pinning a specific version is the safer habit even though the documentation shows the convenient form.

The AndroidX note is the other practical point. A library that has moved to AndroidX cannot be consumed by a project that has not enabled it, and the error surfaces as a build failure rather than a runtime issue. The minimum SDK of 21 also sets a floor: the library cannot be used in an application that supports older devices than that, which in practice means API 21 and above.

For evaluation, the README offers a demo application, BGABaseAdapterDemo.apk, available for download and install by scanning a QR code. That is a quick way to see the sticky index, the drag sorting and the cascade layout on a device before writing any code.

Licence, the implementation notes and the state of the repository

The README carries an Apache 2.0 badge and the full licence text in its licence section, with the copyright line naming bingoogolapple and the year 2015. That is the permissive licence most Android libraries use, with attribution and a patent grant and no copyleft obligation on your application code. One caveat: the licence classification recorded for the repository itself is unresolved, and the licence text lives in the README rather than in a separate LICENSE file, so a licence scanner pointed at the repository root may report nothing while a human reading the README sees clear terms.

The repository root is small and has one file that deserves attention. Alongside the usual Gradle files, the library source directory, the demo directory and the images used by the README, there is a document whose name, written in Chinese, refers to implementation principles, and it is the only prose file at the root of the repository. For a library whose main value is index bookkeeping inside a RecyclerView, an explanation of how that works is exactly the file to read before adopting it, and its presence suggests the author expected questions about the approach.

The last push to the repository was on 2026-07-27, and the project publishes no GitHub releases, so the version history lives in Maven Central rather than in the repository. The demo directory carries its own build.gradle and ProGuard rules, and the root has a settings.gradle, gradle.properties and a Gradle wrapper, so the project builds from a clone with the wrapper included.

One thing the README is candid about is the project's origin in other people's work. The header and footer support and the drag sorting both have their reference projects named in the acknowledgements, which is the correct way to signal that a library built on community patterns is not claiming to have invented them.

Editorial conclusion

BGABaseAdapter-Android fits an Android team that still maintains ListView and GridView screens alongside RecyclerView ones, or that wants headers, footers and mixed item types without hand-maintaining the index arithmetic in every callback. It is the wrong choice for a greenfield app that will only ever use RecyclerView with a single item type, where the platform adapters and a DiffUtil are enough, and it is the wrong choice if you need a maintained dependency trail, since the repository publishes no releases and the last push was on 2026-07-27. Before adopting it, read the implementation notes document in the repository root, whose file name is in Chinese, to understand the index handling, and pin a specific Maven Central version of cn.bingoogolapple:bga-baseadapter rather than tracking latestVersion in production builds.

Frequently asked questions

Official sources

1. bingoogolapple/BGABaseAdapter-Android on GitHub
2. Issues
3. README