Upgrade to Pro — share decks privately, control downloads, hide ads and more …

VIPER: Sexy Architecting or MVP on Steroids

VIPER: Sexy Architecting or MVP on Steroids

This talk was presented at TechTalks@Lohika - Android, Kyiv, UA
* How to build scalable, flexible and robust system;
* Why MVC/MVP/MVVM is not an architecture;
* What is Clean Architecture;
* Considering VIPER architecture as an adaptation of Bob Martin's CA for mobile projects: main components, principles, pros & cons;
* Explanation of many buzzwords: SRP, Flow of Control, Business Rules, Massive View Controllers etc.

Dmytro Zaitsev

October 22, 2016

More Decks by Dmytro Zaitsev

Other Decks in Programming


  1. Sexy Architecting VIPER: MVP on steroids Dmytro Zaitsev Mobile Team

  2. None
  3. None
  4. None
  5. None
  6. None
  7. None
  8. MVP/MVC/MVVM is NOT an Architecture! It’s only responsible for the

    presentation layer delivery mechanism
  9. Real-world Android app • Hard to understand • Hard to

    maintain • The business logic is mixed in Activity/Fragment • High coupled components • MVC -> Massive View Controllers • Hard and often impossible to test
  10. None
  11. Clean Architecture • Independent of Frameworks • Testable • Independent

    of Database • Independent of any external agency • Independent of UI
  12. None
  13. None
  14. None
  15. What is VIPER? • A way of architecting applications which

    takes heavy inspiration from the Clean Architecture • Divides an app’s logical structure into distinct layers of responsibility • Makes it easier to isolate dependencies • Makes it easier test the interactions at the boundaries between layers • Eliminates Massive View Controllers
  16. Main parts of VIPER • View • Interactor • Presenter

    • Entity • Router
  17. None
  18. View Displays what it is told to by the Presenter

    and relays user input back to the Presenter
  19. View • Is passive • Waits for the Presenter to

    give it content to display • Never asks the Presenter for data • Determines how the content is displayed • Handles user interaction and input • Simply delegates user’s actions to the Presenter • Awaits for a response telling it what should be displayed next
  20. Example of View

  21. None
  22. Example of View

  23. Presenter Contains view logic for preparing content for display (as

    received from the Interactor) and for reacting to user inputs (by requesting new data from the Interactor)
  24. Presenter • Knows about the content it maintains and when

    it should be displayed • Receives input events coming from the View • Applies view logic over this data to prepare the content • Tells the View what to display • Sends requests to an Interactor • Works like a bridge between the main parts of a VIPER module • Receives the data structures coming from the Interactor • Knows when to navigate to another screen, and which screen to navigate to
  25. с с Example of Presenter

  26. Interactor Contains the business logic as specified by a use

  27. Interactor • Represents use cases • Regular Java object •

    No Android framework dependency • Encapsulates application specific business rules
  28. с с Example of Interactor

  29. Entity Contains basic model objects used by the Interactor

  30. Entity • POJOs • Encapsulates different types of data •

    Model objects manipulated by an Interactor
  31. Example of Entity

  32. Router Contains navigation logic for describing which screens are shown

    in which order
  33. None
  34. None
  35. Router • Responsible for passing data between screens • Receives

    input commands from the Presenter • Responsible for the navigation logic between modules
  36. Example of Router

  37. Example of Router

  38. Why should you use VIPER? • It’s easier to track

    issues via crash reports • The source code will be cleaner, more compact and reusable • Adding new features is easier • There are less conflicts with the rest of the development team • It’s easier to write automated tests
  39. When should you NOT use VIPER? • It’s an overkill

    for small projects • Causes an overhead when starting new projects • MVP/MVC/MVVM-VIPER mix can cause headaches • Lots of code all over the project
  40. Testing • Presentation layer ◦ Espresso, Robolectric • Domain layer

    ◦ JUnit, TestNG, Mockito, PowerMock • Data layer ◦ Robolectric, JUnit, TestNG, Mockito, PowerMock
  41. References • http://mutualmobile.github.io/blog/2013/12/04/viper-introduction/ • http://www.mttnow.com/blog/architecting-mobile-apps-with-bviper-modules • http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/ • http://fernandocejas.com/2015/07/18/architecting-android-the-evolution/ •

    https://www.objc.io/issues/13-architecture/viper/ • https://github.com/RxViper/RxViper • https://www.ckl.io/blog/ios-project-architecture-using-viper/ • http://luboganev.github.io/post/clean-architecture-pt2/
  42. Thank you! Questions? Dmytro Zaitsev @DmitriyZaitsev