Migration to MVVM @ Pepperfry iOS App- Part III(Conclusion)
This is the third and last part of the series, Migration to MVVM @ Pepperfry iOS App. In this part, we are gonna conclude the migration process.
Before moving ahead, if you have not read the previous parts in this series, I suggest that you read it first. It talks about initial Pepperfry iOS architecture and how we migrated it to MVVM architecture.
In this part, we will look at :
- Test Cases
- Learnings
- Future Plan
Test Cases :
Our basic motivation behind MVVM migration was to write code that is easy to test and the migration really helped us achieve it.
Writing unit test cases is one of the most crucial aspects of any project. Along with moving all business logic into ViewModel objects, we took the first step to writing testable code. While creating ViewModel, we followed some rules like:
- Each UIViewController should depend on only one ViewModel.
- Each ViewModel should depend on a Model.
- Each View should bind to a depended ViewModel only.
Dependency Injection is used in creating ViewModel, as ViewModel depends on a Model. We can read more about Dependency Injection here.
Below is the actual code from the Wallet module in our app, which shows the ViewModel creation through Dependency Injection.
This creation of ViewModel, helps us to easily mock it’s dependencies and test it. Below is a code snippet for XCTest in our app for above ViewModel.
As we can see, we depend on XCTest for writing unit test cases and mocking is done manually by having a separate utility function.
Learnings :
- We believe MVVM is a good architecture, especially if you come from MVC background. It is much more than an extension of MVC.
- MVVM creates modular, decoupled code that is easy to debug.
- It helps to produce code that is easy to test and mocking of dependency is also not a tedious task.
- MVVM allows you to reuse code across many view controllers much easier than traditional MVC.
- It does need some extra setup before you can start using your objects in MVVM. This means that for very simple projects it can be seen as overkill.
We knew the theory of MVVM architecture, but practical implementation was definitely not an easy task for us; we had lots of discussion about the implementation of the architecture. Everyone added their perspective to this architecture, but the ultimate goal was to create a well-architected code.
Future Plan :
We are constantly researching more about MVVM and feel there is scope for improvement in this architecture. We are planning to implement Reactive Programming through RxSwift in MVVM, that will help us in reactive bindings between View and ViewModel.
Summary :
Experience with migration was great. We have written new modules in MVVM and planning to move old modules to MVVM progressively. We are continuing with MVVM for upcoming modules.
In brief, this migration really helped us write modular, decoupled code which is easy to debug and test.
