In this short blog, I’ll speak about how PayU migrated its Apps & SDKs to MVVM architecture to improve code testability, scalability & readability. In the past few years, we’ve done several iterations of UI revamps while our core business logic would largely remain the same (barring the new features). With our existing architecture, it was becoming difficult to deliver these changes at a pace at which our business required them to be delivered. So, we’ve heavily focused on redesigning our underlying architecture to make the code more readable, scalable & at the same time more testable by leveraging the MVVM architecture.

What were we doing?

Till now, we were following MVC pattern. Now, theoretically, it seemed a good pattern to us but as the code base increased and more and more UI revamps were introduced we realized that the codebase was becoming unmanageable for two reasons:

    1. With each UI iteration, we were changing not just the UI code, but also the business logic. Which directly pointed out that somewhere our UI was not separated from the business logic.
  1. As the codebase increased our unit-testable code was reducing — meaning we were relying more on end-to-end testing. This in itself was a bad sign as our testing pyramid was inverted.
We were moving from left to right (wrong) direction

MVC Structure

MVVM as a savior

We started our lookout for better architecture and this is when MVVM came in as a savior. Even, Google ❤ MVVM.

MVVM architecture removes the tight coupling between each component. The children don’t have a direct reference to the parent, they only have the reference by observables. Notice that each component depends only on the component one level below it. This design creates a consistent and pleasant user experience.

MVVM architecture removes the tight coupling between each component. The children don’t have a direct reference to the parent, they only have the reference by observables. Notice that each component depends only on the component one level below it. This design creates a consistent and pleasant user experience.

Advantages

  1. Separation of concerns: It’s a common mistake to write all your code in an Activity or a Fragment. The UI-based classes should only contain logic that handles UI and operating system interactions. By keeping these classes as lean as possible, you can avoid many lifecycle-related problems. MVVM lets you ensure that each type of class is responsible for only one type of task.
  2. Testability: User interface and interactions can be tested using instrumentation test cases (Espresso Library). ViewModels & Repository can be tested using the JUnit test.
  3. Scalability: You can easily introduce UI revamps. New features can be added without the need to refactor or change much of the existing codebase. We can plug and unplug the components with much more ease.
  4. Manageability: The codebase is much more manageable – All your UI logic is in one place, your business logic & your data logic at another place.

Disadvantages

    1. Getting started with MVVM & adding new features may require some experience with the pattern. There is a steep learning curve, relatively.
  1. Following the MVVM pattern, you might end up creating more Java classes.

Final words

While building any application it’s important to pick the right architectural pattern — there are no fixed “fits all” patterns.

36