Decoupling Complex RecyclerView Adapters in Android Using Sealed Classes and Kotlin Reflection

RecyclerView is a widely used Android UI component, but when an adapter must handle many different item types (e.g., text, image, tip, unsupported), the code in onBindViewHolder and onCreateViewHolder quickly becomes tangled and hard to maintain.

The author first presents a straightforward implementation that manually creates each ViewHolder type inside the adapter, showing the full Kotlin source code for the activity, the adapter, and the individual ViewHolder classes ( TextVH , ImageVH , TipsVH , NoMatchVH ).

To improve modularity, the code is refactored so that each ViewHolder inherits from an abstract BaseVH class that defines an abstract setData method. A viewHolderMap (type → constructor) is introduced, and the adapter’s onCreateViewHolder simply looks up the appropriate constructor, dramatically reducing adapter boilerplate.

However, manually populating viewHolderMap still requires updates whenever a new ViewHolder subclass is added. The solution leverages Kotlin reflection: by making BaseVH a sealed class , the companion object iterates over BaseVH::class.sealedSubclasses , obtains each subclass’s constructor, creates a temporary instance to read its type , and registers it automatically in the map.

The article also shows how to add the Kotlin reflection dependency ( implementation "org.jetbrains.kotlin:kotlin-reflect:$kotlinVersion" ) and provides the complete updated source code, including the sealed BaseVH definition with an abstract type property.

Finally, an alternative implementation using Jetpack Compose is presented. Instead of a traditional RecyclerView, a LazyColumn iterates over the same data list, and a map of composable functions ( itemFunctionMap ) selects the appropriate UI based on the item type. The Compose version demonstrates how the same decoupling idea can be applied in a declarative UI framework.

Overall, the article offers a practical pattern for keeping RecyclerView adapters clean, extensible, and less error‑prone, while also hinting at future‑proof Compose‑based solutions.