Build Better and Clean RecyclerView.Adapter With Kiel
Duplicate code is the root of all evil in software design. When a system is littered with many snippets of indentical, or nearly identical code, it is indicative of sloppiness, carelessness, and sheer unprofessionalism. It is the guilt-edged responsibility of all software developers to root out and eliminate duplication whenever they find it.
Some years ago, we had only ListView and its Adapter. It had performance issues and these issues were resolved with ViewHolder Pattern (Here also I want to send my greatest appreciation to the one who found and shared this).
If we go back and recall it in detail, it is basically wrapping some view related software entities into ViewHolder class, saving it in View’s tag and using it in. Hopefully, Google released better ListView, which is RecyclerView, for us.
As we are in the mud of Android Hell (lifecycle problems, architecture problems, UI development problems etc etc.), most of us like did not notice the adapter hell in ListView. We did not complain about it enough as we did in this ViewHolder pattern, so Google has not saved us from this hell yet.
What is Adapter Hell?
Writing/Duplicating the same RecyclerView.Adapter implementation for each Fragment/Activity which uses RecyclerView to visualize the data. Code Duplication is bad but duplicating bug or limitation is worser thing that we can do for us🤢🤢🤢.
In Twitter, there was a confession post-cycle for Android Developers and Duplicating RecyclerView.Adapter is the one of the most popular answers by Android Developers.
If there are more than one type to be visualized in RecyclerView, it means more wood in the fire of this hell 🥵.
Because it means that you will have:
- more if/when/switch statement 😥
- more casting 🤯
- more bug🤬
There are many very good solutions and articles about these issues.
One of the most popular idea is based on Delegation Pattern over RecyclerView.Adapters, which is basically we create a generic adapter, we have delegation for each type which help us to create ViewHolder and binding data to ViewHolder.
You should absolutely read Hannes Dorfmann’s Adapter Hell Escape Article. I want to say thanks to him for such a great article and AdapterDelegates library. It still helps a lot.
Another pain point is the viewtypes. It should be unique arbitrary Integer. Our data types in the adapter are unique, so we have different data type for different views. But we have to define this Integer value😢.
Should we define them as 1,2,3 or 4?
It makes me remember button1, button2, button3…
Unfortunately ,we can’t use that data types hash value because HashValue is integer. There can be collision!😳
Don’t worry there is also a solution for that, which is basically using layout resource as a viewType! It is unique, it is logically connected with both ViewHolder and data type.
You should absolutely read Danny Preusler’s article about that.
So the idea:
- Don’t copy/paste/write same adapter code for each
RecyclerView. - Use your layout resource as a
viewType.
RecyclerView.Adapter with Kiel
Kiel is designed to be easy to integrate, easy to use based on these two ideas with the help of the power of Kotlin💪.
It enables us to configure our adapter with existing vocabulary of RecyclerView.Adapter. So we don’t need to learn new concepts to implement/ handle the things related to RecyclerView.Adapters, such as binding ViewHolder, handling events like onClick ,onLongClick or something else.
So when we check how Kiel helps us:
RecyclerView.Adapter Implementation becomes:
Handling Different View Types becomes:
Diffing becomes:
Diffing with Payloads:
You can find Kiel:
You can download:
implementation 'me.ibrahimyilmaz:kiel:latestVersion'Your ideas/feedbacks/PRs/Issues are greately appreciated.
Happy Coding!
