Android Architecture Sandbox #1

Around May of last year Android introduced a bunch of new classes around organising code better. Till then Android team never really took a stand to tell the community how to organise their codebases. What I observed was activities started developing unwieldy View classes (Activities and Fragments) that did everything from spawning new threads, making network calls, performing disk writes to anything and everything you could require the application to do.

An approach like that would introduce a lot of obvious problems

• Maintainability
• Readability
• Reusability
• Testability

Android problems

• Memory leaks
• Lifecycle management

This is something that was driven into my head by Rich Hickey

Simple doesn’t mean easy

The solution for the problem would be to break down these monolithic classes into separate classes, i.e. Separation of concerns. This would enable the logic related to rendering of the screen itself be consolidated in one place whereas the business logic would be moved to another class. The assumption here is that we have done a good job to abstract the logic that is not relevant to either of the classes (API clients, Queries,…), the next question is how these two classes interact. As you may have already, this not an exclusive problem for Android but for most software user interface systems.

So the available solutions for us are:
Model-View-Controller, Model-View-Presenter, Model-View-ViewModel

I was introduced to The Clean Architecture when we started working on building a new application from scratch and we had to decide which solution suited us the best. The primary cornerstone being Dependency Rule: The dependencies only point inward i.e. the dependencies are unidirectional. This helps the codebase retain independency between the layers of seperation.

The introduction of Databinding Library enabled us to implement an MVVM. But as the codebase aged it was soon realised the implementation was not ideal with the highlighted problem being a lack of proper life-cycle awareness and leaky abstractions.

This makes me want to revisit the MVVM pattern in Android using these libraries and on the way explore the latest methods to writing a simple android application using ViewModel, Room, RxJava2