Not long ago, when we made the shift towards MVP, it was not an easy task. The cost of bringing the team to same level was not insignificant. Our current codebase is fine! Why do we then need to move to a new pattern? Are all our efforts gone in vain and should we start from scratch? I say no!
All of us are aware of many architectural patterns like MVC, MVP, MVVM, etc. It was not long ago when we had started applying MVP or MVVM to our projects. It was not an easy task to refactor existing code to adopt these patterns, plus the cost of bringing the whole team to the same level was not insignificant. These patterns brought along many advantages like separation of logic and better testing.
We are happy with where our codebase is at the moment and it’s test coverage. Why do we then need to move to a new pattern now? Are all our efforts gone in vain, now that we have a new pattern?
There have been multiple talks about MVI, so let’s take a different approach & instead of jumping directly into code, let’s answer the above questions first. Here’s the mind map :
- - We will learn about the main problem that this pattern solves : The State Problem,
What it is and how MVI solves it.
- We will also learn that MVI can also be applied on top of our existing patterns.
- MVPI : We need not completely change the style that we have already adopted. Instead we can modify our existing style to take the advantage of the reactive flow and achieve better state management.
- Implementation to kick off MVI on top of MVP
- MVVMI : Now that Kotlin is getting adopted widely, cross-platform developers are finding it even easier to switch tabs between Kotlin and Swift.
We will learn how MVI is not just a pattern for Android. - MVI on top of current MVVM implementation from the iOS land.