$30 off During Our Annual Pro Sale. View Details »

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
Tweet

More Decks by Dmytro Zaitsev

Other Decks in Programming

Transcript

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

    View Slide

  2. View Slide

  3. View Slide

  4. View Slide

  5. View Slide

  6. View Slide

  7. View Slide

  8. MVP/MVC/MVVM is NOT an
    Architecture!
    It’s only responsible for the presentation layer delivery mechanism

    View Slide

  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

    View Slide

  10. View Slide

  11. Clean Architecture
    ● Independent of Frameworks
    ● Testable
    ● Independent of Database
    ● Independent of any external agency
    ● Independent of UI

    View Slide

  12. View Slide

  13. View Slide

  14. View Slide

  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

    View Slide

  16. Main parts of VIPER
    ● View
    ● Interactor
    ● Presenter
    ● Entity
    ● Router

    View Slide

  17. View Slide

  18. View
    Displays what it is told to by the Presenter and relays user input back
    to the Presenter

    View Slide

  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

    View Slide

  20. Example of View

    View Slide

  21. View Slide

  22. Example of View

    View Slide

  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)

    View Slide

  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

    View Slide

  25. с
    с
    Example of Presenter

    View Slide

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

    View Slide

  27. Interactor
    ● Represents use cases
    ● Regular Java object
    ● No Android framework dependency
    ● Encapsulates application specific business rules

    View Slide

  28. с
    с
    Example of Interactor

    View Slide

  29. Entity
    Contains basic model objects used by the Interactor

    View Slide

  30. Entity
    ● POJOs
    ● Encapsulates different types of data
    ● Model objects manipulated by an Interactor

    View Slide

  31. Example of Entity

    View Slide

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

    View Slide

  33. View Slide

  34. View Slide

  35. Router
    ● Responsible for passing data between screens
    ● Receives input commands from the Presenter
    ● Responsible for the navigation logic between modules

    View Slide

  36. Example of Router

    View Slide

  37. Example of Router

    View Slide

  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

    View Slide

  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

    View Slide

  40. Testing
    ● Presentation layer
    ○ Espresso, Robolectric
    ● Domain layer
    ○ JUnit, TestNG, Mockito, PowerMock
    ● Data layer
    ○ Robolectric, JUnit, TestNG, Mockito, PowerMock

    View Slide

  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/

    View Slide

  42. Thank you!
    Questions?
    Dmytro Zaitsev
    @DmitriyZaitsev

    View Slide