VAMPIRE Architecture

This idea is one that has its roots starting years ago when I started building the new Hinge Android app. Since I had a clear slate I decided to start with the best ideas I could find, including what the Hinge iOS team had already adopted as its architecture. If you're curious about what that was like the iOS lead at the time did a talk about it. I want to talk about my reasoning and how things have evolved in the years since.

When deciding on the reasons to try this I could share ideas and practices about where code exists and eventually have some cross team code review (especially since I've been a team of 1). While honestly the cross team code review hasn't manifested, I have been able to talk about and reason with the iOS devs at Hinge. Also the benefits such as clear layers of responsibility and being able to unit test them has been a major help.

A big difference between VIPER and the other MV* architectures is denoting a Router interface to be able to navigate between screens. This made building the app to be multi-module (currently at 58) in the first place quite easy and our transition from many Activities to a single Activity with Navigation Component handling Fragments much easier than it otherwise would have been.

Our Presenters are backed by AndroidX ViewModel. We have used RxJava for years, so it didn't really make sense to switch to LiveData, especially since subscribing to Room queries is so easy and straightforward. We eventually decided it was easier to onboard new employees by calling these ViewModels and adapting our architecture documentation to fit rather than keep a neat sounding acronym.

Lastly, I would say that I have borrowed some of MVI in the sense of having a uni-directional flows of data that populate the app's UI and drive the view. This eventually evolved into adopting UseCases and splitting up our gigantic ViewModels and Interactors.