The Cognitive Appeal of the Clean and the New Android Architectures

Android's new architecture component is now official and solidified. There is no doubt that the architecture components, like View Models and LiveData, will make the life of newcomers in the Android development world much more painless.

But to a seasoned developer, the question will inevitably arise about how and where the new architecture components sit with the concepts of clean architecture, as promoted by Uncle Bob.

You may ask why should we worry about clean architecture? The answer is simple — clean architecture is based on how humans relate to the software development cycle, meaning that it comes down to a simple and single principle of "Separation Of Concern." Clean architecture is not limited to a particular platform solution, as are the concepts of Android Lifecycle and the solutions around it.

With that question in mind, I wanted to see how one of the recent samples from Google, using their architecture components, fits with the fundamental concept of clean architecture. The core concept of clean architecture is summarized in the picture and is very familiar to anyone aware of clean architecture as proposed here:

Core Principle in the Clean Architecture

"Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in an inner circle. That includes functions, classes, variables, or any other named software entity."

The sample I took is the "Room with a View" sample from Google code lab.

Although there are a number of implementations of clean architecture using approaches, like MVP, MVVM, etc., which gives a viable solution on the Android space, my question here is, if we can maintain the core concept of clean architecture namely : "the name of something declared in an outer circle must not be mentioned by the code in an inner circle" without bringing any framework, by just using the Android Architecture Components.

The "Room With A View" is a simple application that lists the words in a database and allows you to add new words.

There are eight classes in the app:

1.  MainActivity 
   
2.  NewWordActivity 
   
3.  Word 
   
4.  WordDao 
   
5.  WordListAdapter 
   
6.  WordRepository 
   
7.  WordRoomDatabase 
   
8.  WordViewModel 
   

Without much difficulty, I could achieve the desired organization with about 90 percent success:

A Few Concerns

The LiveData as an element does not appear anywhere in the organization. While it is true that LiveData is a facility/mechanism, it is not an entity in the policy sense.

The clean architecture says, "The outer circles are mechanisms. The inner circles are policies." On that basis, it puts the DB at the very outer most layer. However, I could not put the DB in the outer circle without breaking the core principle.

I understand this is more of a sign of how DB in the current technology has become more of a wide al encompassing concept rather than an implementation detail.

The only other concern I had was with the sense of the separation of concern detail when the ViewModel  sits in the UI controller, whereas the ListAdapter is supposed to take care of data that is on display. The adapter is capable of observing the view model of any change. If we do that, then we can say the adapter pretty much decides what data to display from the repository side. UI is responsible for maintaining the correct UI look and feel of components. With that in mind, I moved the view models in the adapter, which exposes an extra method "insert (..)" to the UI. The modified code is here: Room for A ViewModel.

By doing that, I get a more comfortable picture of the clean architecture circles where the LiveData is an internal tool for the repository to use in its favor:

Conclusion

Android clean architecture is a goal that can be achieved without a great deal of framework, as long we focus on the cognitive separation of concern, along with the testing facility, which is becoming much more language-driven as they are in Kotlin, without bothering about the nature of the tool and facility. We can always adhere to the principle: "In general, the further in you go, the higher level the software becomes." Higher level simply means more encompassing, like the DB implementation is nowadays. We do not care anymore what kind of DB it is, as long as it maintains the exposed interfaces intact. Thanks to the energy in open source, we can afford to see today's tools through a cognitive lens rather than tying our hands and minds to it. This, in turn, makes open source move faster as well.