Our Way to MVVMI and Mistakes We Made When Implementing MVVM

My story on this project started with the management’s decision of refactoring it as developers had hit the wall with “God” Activities, static fields that held Context, endless memory leaks and “workarounds” in the code base and managers were tired of a flaky and bugged product in production. Therefore the best option seemed to refactor the project (or at this point rewrite it) to follow a layered architecture pattern. The choice was given to MVVM.

It is not a secret that Google positions using MVVM (Model-View-ViewModel) as the most efficient choice of Android architecture. When reading the Guide to app architecture you can see examples of Architecture Components applied to a layered architecture pattern. My team sure thing read this piece and got to implementing it in our project.

At first migrating to MVVM, indeed, increased the readability and stability of the code base. However several mistakes we made along the way created new issues that I am going to talk about next.

Mistake 1: Passing LiveData objects as params to repository and updating the value there.

Yes, we did that at first. Creating an instance of LiveData in ViewModel then passing it to repository and setting new value when a server response is received. After that, View was notified and passed this…