mikepenz/FastAdapter: a Kotlin RecyclerView adapter library with selection, drag and drop, and expandable items

What FastAdapter removes from a RecyclerView adapter

A stock RecyclerView.Adapter makes you own view type dispatch, ViewHolder creation and binding, plus every interaction you add later: row clicks, long clicks, selection state, swipe-to-dismiss, drag reordering, headers and footers. FastAdapter moves that bookkeeping into the library and leaves you the item definition. The README frames the goal directly: "Just write the logic for how your view/item should look like, and you are done."

The intended audience is an Android team already writing Kotlin against AndroidX. The repository is Kotlin-first, and the README calls out a core module that is "100% in Kotlin", with separate deprecated Java and AppCompat lines listed under older version numbers. If your project is Java-only and pinned to AppCompat, the current release is not aimed at you.

The library also covers ground that normally means pulling in several unrelated dependencies: multi-selection with an ActionModeHelper and UndoHelper, expandable items, sticky headers, endless scroll, the swipe leave-behind pattern, and Paging through the Jetpack paging library. One adapter type handles all of it rather than a stack of wrappers.

How the item, ViewHolder and adapter fit together

FastAdapter inverts the usual arrangement. Instead of the adapter deciding what a row is, each row is an item object that declares its own type, layout and ViewHolder. The README's first example extends AbstractItem and overrides three members: a type that the comment says must be unique and is "preferably an id", a layoutRes pointing at a layout resource, and getViewHolder returning a ViewHolder instance for a given View.

That type value is the multi-view-type key. Because each item carries it, the adapter can mix heterogeneous rows in one list without a manual getItemViewType switch. The README shows a ModelItem and MultiTypeModelItem pattern for splitting the view from the model, which is the option to take when your data classes should not know about layouts.

Lists are assembled by chaining. The README lists "Chain other Adapters" and points at the simple list and sticky header samples, so a header adapter, a content adapter and a footer adapter can be composed instead of merged into one list with sentinel positions. Helpers sit on top: ActionModeHelper and UndoHelper for selection flows, FastScroller as an external library, and paging through the Jetpack paging library in the PagedActivity sample. The repository root shows the split clearly: fastadapter/ for the core, then fastadapter-extensions-binding, -diff, -drag, -expandable, -paged, -scroll, -swipe, -ui and -utils as separate modules.

Installing FastAdapter and building a first item

FastAdapter ships through Gradle. The README gives the core dependency plus the two AndroidX artifacts it builds on, with the version written as a placeholder variable you substitute with the release you want:

implementation "com.mikepenz:fastadapter:${latestFastAdapterRelease}"
implementation "androidx.appcompat:appcompat:${androidX}"
implementation "androidx.recyclerview:recyclerview:${androidX}"

Add extension modules only for the features you use. Expandable support has its own artifact, and the binding, diff, drag, paged, scroll, swipe, ui and utils helpers are each separate. The README notes that the utils extension needs the expandable, drag and scroll extensions, and that the ui components and utils also require the Material library:

implementation "com.mikepenz:fastadapter-extensions-expandable:${latestFastAdapterRelease}"
implementation "com.mikepenz:fastadapter-extensions-drag:${latestFastAdapterRelease}"
implementation "com.google.android.material:material:${androidX}"

For the item itself, the README's first recipe is to extend AbstractItem and fill in the three required members. The type must be unique across the list, so an R.id constant is the conventional choice:

open class SimpleItem : AbstractItem<SimpleItem.ViewHolder>() {
    var name: String? = null
    var description: String? = null

    override val type: Int
        get() = R.id.fastadapter_sample_item_id

    override val layoutRes: Int
        get() = R.layout.sample_item

    override fun getViewHolder(v: View): ViewHolder {
        return ViewHolder(v)
    }
}

After that, the ViewHolder extends FastAdapter.ViewHolder and binds the fields. The repository's app/ module holds runnable samples for each feature, including MultiselectSampleActivity, ExpandableSampleActivity, SimpleItemListActivity for drag and drop and filtering, EndlessScrollListActivity, SwipeListActivity and PagedActivity. There is also a published sample app on Google Play, which is the fastest way to see the behaviour before wiring anything up.

Where FastAdapter is the wrong choice

The release cadence is the first thing to weigh. The most recent release listed is v5.7.0 from 2022-09-30, after v5.6.0 in 2021-11-24 and v5.5.1 in 2021-09-14. The repository's last push was on 2026-04-09, so work has continued on the develop branch, but that work has not been cut into a tagged release in the releases listed here. A team that needs an artifact published recently, or that wants the newest AndroidX and Material versions reflected in a version number, will not find one.

If your list is a plain, single-view-type list with no selection, no swipe and no drag, FastAdapter is more machinery than the problem needs. A short RecyclerView.Adapter or ListAdapter is smaller, has no extra dependency, and does not ask you to learn an item abstraction. The same applies to a screen where the list is incidental and you would rather not add modules to the build for it.

The abstraction has a cost at the boundary. Items own their type and layout, so logic that would live in the adapter now lives in item classes, and the split between item and model is a design decision you have to make early. The README points at ModelItem and MultiTypeModelItem for the separated approach but does not prescribe when to use which. The library also does not document rollback or downgrade steps in the README; the MIGRATION.md file at the repository root is where version-to-version changes are recorded.

FastAdapter compared with a plain ListAdapter

The closest baseline is AndroidX's own ListAdapter, built on DiffUtil. It handles list diffing and item animation well and is maintained as part of AndroidX, so it tracks RecyclerView changes with no third party in the path. What it does not give you is selection state, an ActionModeHelper, an UndoHelper, drag and drop, expandable rows, sticky headers or endless scroll. You write those yourself or assemble them from separate libraries.

FastAdapter's answer is to bundle them behind one item interface and split the optional parts into extension artifacts. Its diff support arrives as fastadapter-extensions-diff rather than being the foundation, so diffing is one capability among several instead of the organising idea. That is the real difference in approach: ListAdapter is a small, diff-first adapter you extend, while FastAdapter is an item-and-adapter framework you configure, with the trade-off that you take on more API surface and more modules in exchange for not writing interaction code.

If your screen is a static list that occasionally changes, ListAdapter is the lighter answer. If your screen is a selectable, reorderable, paginated list with headers and swipe actions, FastAdapter is doing work you would otherwise write and maintain. The repository's sample activities are the practical way to judge which side you are on.

Licence, maintenance and upgrade cost

FastAdapter is licensed under Apache-2.0. That is a permissive licence, so it can be used in closed-source applications, but it carries notice and attribution obligations, and the repository includes a LICENSE file and a CONTRIBUTORS.md. Treat the exact terms as something your own legal review reads, not something to infer from the licence name.

The maintenance picture is mixed. The repository is not archived and the last push was on 2026-04-09, so commits are landing on the develop branch. The release list, however, stops at v5.7.0 from 2022-09-30. Anyone depending on published artifacts is on that version until a newer one is tagged, and the gap between the develop branch and the newest release is where upgrade risk sits.

Upgrade cost is real because the project ships a MIGRATION.md at the repository root, which means API changes between versions have been frequent enough to document. Budget time for that file on any major bump, and pin the version variable rather than letting it float. The extension modules also version together, so a partial upgrade that moves the core but leaves an extension behind is a failure mode worth avoiding in your dependency declarations.

Editorial conclusion

Adopt FastAdapter if your app is Kotlin and AndroidX and you want selection, drag and drop, expansion and paging without writing adapter plumbing yourself. Do not adopt it if you need a recently released library or you are still on the deprecated Java and AppCompat line. Before committing, check the artifact version you resolve against v5.7.0, confirm the extension modules you need exist in that version, and read MIGRATION.md for the API changes since the release you are upgrading from.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. mikepenz/FastAdapter on GitHub
3. Project website
4. README
5. Releases