Chapters

Hide chapters

Advanced Android App Architecture

First Edition · Android 9 · Kotlin 1.3 · Android Studio 3.2

Before You Begin

Section 0: 3 chapters
Show chapters Hide chapters

14. VIPER Theory
Written by Aldo Olivares

Heads up... You're reading this book for free, with parts of this chapter shown beyond this point as scrambled text.

After making it to this point in the book, you should already know that there are many options to structure your applications.

In this chapter, you will learn about VIPER, an architecture pattern closely related to the MVP architecture. By the end of the chapter you should know:

  • The theory behind VIPER, why it is useful and how it fits into the Android framework.
  • Each of VIPER’s components, their roles and their responsibilities.
  • The advantages and disadvantages of VIPER.

What is VIPER?

VIPER stands for View, Interactor, Presenter, Entity and Router. In case you haven’t noticed, all the previous patterns have relied on three layers of abstraction, while VIPER relies on five. This five-layer structure aims to balance the workload between the different entities to provide the maximum level of modularity.

The role of each of the Entities are as follows:

  • The View displays the UI and informs the Presenter of user actions.
  • The Interactor performs any action and logic related to the entities.
  • The Presenter acts as a Head of Department. It tells the View what to display, tells the router to navigate to other screens and tells the Interactor about any necessary updates.
  • The Entity represents your app’s data.
  • The Router handles the navigation in your app.

Like other architecture patterns, VIPER’s aims to create a cleaner and more modular structure to isolate your app’s dependencies, improving maintainability and testability.

The interaction between the layers can be illustrated by the following diagram:

Each entity corresponds to an object that performs a task and the connections represent how they interact with each other. The communication between each layer is usually handled in Android with interfaces, as you will see in the next chapter.

Let’s walk through a real-world example to further illustrate these concepts.

Imagine that you are going on a trip to the mountains and you need to know the weather for the week to ensure that you don’t get trapped in a storm.

Normally, you open the weather app on your phone and choose the best day for your journey. When you tap the Refresh button to retrieve the latest weather data, the interaction between the VIPER layers would look like the following:

  1. The View receives the refresh action from the user and sends it to the Presenter. Whenever you do something in the user interface (like tapping the Refresh button) the View immediately reports to the presenter what you did. It’s not the View’s job to handle the action directly.
  2. The Presenter asks the Interactor to request new weather data. Whenever you need to interact with the backend of your app, such as a weather API, the presenter delegates the task to the Interactor.
  3. The Interactor calls your Weather API and handles the response. If the call fails, the Interactor immediately returns a fail response to the Presenter so that it can be handled appropriately. If the response succeeds, the Interactor converts the data into one or more Entities and sends them back to the Presenter.
  4. The Presenter receives weather data from your Interactor. If the data needs further processing, the Presenter will call the appropriate functions. If the data is ready to be displayed, the Presenter will send it to the Views along with instructions on how it should be displayed to the User.
  5. The View displays weather information to the user. The last step of the process is to display new information to the user according to the instructions supplied by the Presenter.

And now you are ready to take your long awaited trip to the mountains! Yay!

Now that you have an overview of how each layer interacts with each other. how you’ll explore them one by one.

The View

As the name implies, the View is in charge of displaying the User Interface (UI) and it is the only thing that the user really interacts with.

The Interactor

The Interactor takes care of performing any actions that the Presenter requests and handles the interaction with your backend modules, such as web services or local databases. Similar to the ViewModel from the MVVM architecture pattern, the Interactor should be completely independent from your Views.

The Presenter

As you can see in the previous diagram, the Presenter acts as a bridge between the main entities of your VIPER implementation.

class MainPresenter()
    : MainContract.Presenter, MainContract.InteractorOutput {   // 1

  private var interactor: MainContract.Interactor? = MainInteractor()   // 2

  override fun onViewCreated() {   // 3
  }

  override fun onQuerySuccess(data: List<Item>) {   // 4
  }
}

The Entity

The Entity corresponds to the Model in other architecture patterns such as MVP or MVVM. Its main responsibility is to expose relevant data to your Interactors using properties or methods.

data class Movie(
  var voteCount: Int? = null,
  var id: Int? = null,
  var video: Boolean? = null,
  var voteAverage: Float? = null,
  var title: String? = null,
  var popularity: Float? = null,
  var posterPath: String? = null,
  var originalLanguage: String? = null,
  var originalTitle: String? = null,
  var genreIds: List<Int>? = null,
  var backdropPath: String? = null,
  var adult: Boolean? = null,
  var overview: String? = null,
  var releaseDate: String? = null,
  var watched: Boolean = false
)

The Router

The last component of the VIPER Architecture pattern is the Router. The Router handles the navigation in your app and tells the Views how they should be presented to the user.

VIPER Advantages and Concerns

VIPER is a great architecture pattern focused on providing each class in your App a unique responsibility. It provides the maximum level of abstraction amongst the patterns that we have seen until now such as MVC, MVP or MVVM.

When should you use VIPER?

  • You expect your code base to increase dramatically over a short period of time.
  • You need an architecture pattern that makes adding new features easier and faster.
  • You need to write Unit Tests consistently during your development.
  • You often find yourself debugging big classes with even bigger methods.

When should you not use VIPER?

As you learned in previous chapters, there is not a single solution to every problem.

Questions you didn’t think to ask

Q. VIPER looks very similar to MVP… are they the same?

Key points

  • VIPER stands for View, Interactor, Presenter, Entity and Router.
  • The View displays the User Interface.
  • The Interactor performs actions related to the Entities.
  • The Presenter acts as a command center to manage your Views, Interactors and Routers.
  • The Entity represents data in your app.
  • The Router handles the navigation between your Views.
  • VIPER is a great architecture pattern for projects that are expected to scale fast but might be overkill for simple apps.

Where to go from here?

In this chapter, you have learned the building blocks of a completely new architecture pattern: VIPER.

Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2024 Kodeco Inc.

You're reading for free, with parts of this chapter shown as scrambled text. Unlock this book, and our entire catalogue of books and videos, with a Kodeco Personal Plan.

Unlock now