Clean Architecture in Android: Practical Guide.
A couple of weeks ago I attended an awesome talk given by Ahmed Adel and organized by the nice people at Tafra. It was about the clean architecture in Android and how to organize your codebase more efficiently.
Being the architecture fan I am, I decided to play around for a bit aiming to build a sample illustrating some of the main concepts we talked about in this talk.
And what came out of this attempt is this lovely small — yet organized :D — repo.
This repo represents an RSS-feeds app, that gives you the ability to add some your favorite feeds and enjoy reading articles provided by those feeds. For now, it only supports adding the feeds URL and removing them.
The purpose of this article is to go over the repo very quickly and touch on a couple of its different aspects and in each aspect, I’ll provide the main resources that help out during my work. I guess you can consider this article as some un-official documentation for the repo so far.
So without further ado, let’s dive in.
Clean architecture pattern
So this is not my first attempt to go for clean architecture, but what made this time kinda special is that I got the exchange some ideas about it with other fellow Androidguys, leading to more synthetic ideas about the famous architecture pattern. But it’s my first time attempting a separate module-per-layer and I got to say, it was something else. I really liked how each separate module represented a separate layer of the app. And the main source of attraction was the fact that the domain layer was completely Android-free in order to ensure that this layer would care about nothing other than the business logic for the app. That’s also why I created it as Kotlin-module, not Android module.
The main resource was this series of articles by five agency. Also, I love this medium story which talks about how the communication between the layers should go despite the fact that the outer layers should know about the inner layers but not vice-versa, it was a really nice way to describe it.
And finally, This repo — which was provided by Ahmed to illustrate what he was talking about — was nice to get some inspiration from.
RxJava
This repo was also a nice chance for me to test out the Reactive programming using RxJava for the first time in a practical project, I used this series to give me a jump start in the RxJava world. Can’t say I know much of it as of now, but for the very least I’m comfortable using it to connect the layers together up until the presentation layer was the liveData will take over.
View Model & LiveData combo
For the presentation/ui modules, I’ve used ViewModel to help out with the app maintain its states over configuration changes. Also, LiveData provides nice auto-unsubscription when its lifeCycleOwner goes off the active state. And of course, we should dispose of any subscription in the ViewModel onCleared methods. If you want to know a bit more about LiveData and ViewModel history I’ve written a piece about that a while ago.
Androidx
As most of you probably know by now, Google will stop updating the support libs after Android 9, and we’re now recommended to switch over to the unified Androidx packages, as use it for any new projects. So I did in this small repo.
The main thing to remember here is not to mix your dependencies and your XML tags, ex: using the Androidx dependency but still using the old support packages for the XML.
Material design
If you have used the Material Components for Android before, you probably know that they can be accessed using Android design support libs, but this is not the case anymore. If you’re using Androidx and want to use the Material Components then you should access them from Google’s Maven repository using “com.google.android.material” artifact.
As it was the case for the Androidx packages, make sure not to mix the packages of the old design lib and the new “com.google.android.material” libs, I found this article to be useful in this process.
ListAdapter
This ListAdapter adapter allows you to compute the difference between two data sets off the main thread, and It will automatically dispatch the corresponding actions (notifyItemChanged, notifyItemInserted, notifyItemRemoved) instead of calling notifyDataSetChanged and rebinding the whole recycler view. That will give some nice animations for free, aside from the fact that it’s super important from a performance point of view.
I’m not gonna talk about it much because I’m planning on writing about this adapter a stand-alone article soon, so stay tuned. :)
Now what?
My next move would be to add some test coverage to the app. Also to replace the current dependency injections static classes with Dagger 2, I’ve never tried Dagger 2 in a multi-module app setup.
Enjoy! :)
