Last Puzzle Piece on Architecting Android Application

“person holding red jigsaw puzzle” by Ryoji Iwata on Unsplash

If you haven’t read my previous post, you might want to spare some of your time to read it first here to gather a clear overview of what I’m going to talk about in this article.

The Pursuit of Perfection 🌠

A mediocre software will certainly abandon unit testing. The utmost reason is convenience; writing a software without tests is blazingly fast. In a blink of an eye, there you have it, a working software. Wait for bugs emerging from those hidden paths, then you’ll regret abandoning tests.

A highly testable software is one of developer’s delight, it helps a lot to ease the pain on refactoring. We know for sure that refactoring requires some time. It needs patience and hard work. And all of this for the sake of testatibily. As we know, if it is easy to be tested, then it is a high quality software.

Clean architecture were introduced and implemented on many platforms. Android included. Google has introduced its Android Jetpack, providing confused developer a fresh air who have been searching for years, for the best architecture in Android application development.

The Pinnacle of Navigation in Android 🚀

The Navigation Architecture Component is introduced, to help developer designs their app’s navigation. Navigation between Fragments made simpler, and it’s lifecycle aware! We don’t need to worry about this kind of error anymore!

IllegalStateException: Can not perform this action after onSaveInstanceState

But sadly (for now), it’s not too flexible. Sending data forward is quite easy. But having to listen on fragments’ events take too much manual labour. There has to be another way to make navigation between Activities and Fragments easier.

Why bother to find other options as Intent and fragmentManager is enough? Never enough.

We need to make our app testable. We need to make our app clean. We need to make our app really clean. Separation of concerns. That’s the word. A View should always stay as a View. Navigation is not its job.

Therefore, there should be another object that has the responsibility to navigate between Android’s view. I’ve been considering Flutter’s navigation. But as lazy as I am 😆 there has to be another option.

Introducing: Cicerone 🌅

Cicerone fulfill my goals. It’s (almost) separated from the View. It’s testable. And its purpose is only for navigation within the app. Take a look at its author’s article to get a grasp on how it works.

As it’s not a framework, Cicerone can be implemented directly on an existing project. May it be implemented by refactoring, or on newly added modules, it’s your choice.

And it’s testable. Consider mockito, and your unit testing life will be better.

At This Point 💡

So far, these are the elements that I consider should be existed in a clean architecture “of my own”. I hypothesize that this architecture can be implemented on (almost) any front end application:

  • ViewLogic: this is the dumb view. It’s dumb, but it has logic.
  • ViewDescriptor: this part describes how the view will be rendered on the screen. Mostly it contains layouts and widgets.
  • BusinessLogic: here’s where the magic happens. This part should be made into libraries, in order to be used in on every platform that needs it.
  • Repository: describes how to manage data to and from BusinessLogic.
  • Service: provider for Repository. It describes how the data is fetched or posted.
  • Router: this is the missing piece. It must not understand anything about the view. It only needs to communicate with BusinessLogic.

I’ll try to post a working boilerplate on my next article. Please show me your love and support by clapping. A follow would be better. Thank you 😄