MVP pattern

A lightning talk about the need for such a pattern to develop an Android app.

Transcript

1. MVP Lightning talk
2. The need for a design pattern Clean code alert Common Android code
3. Code smells Testing Mocking static methods is a pain Testing business rules requires emulation SRP violation View is aware of business rules Regression prone, not modular You don’t want to write the tests for this
4. How to proceed Start from the view: what are its responsibilities? (use case: user login) boolean userIsValid(User user); void connect(User user); void saveUser(); String[] getUserInputs(); void displayAuthError(String error); void continueFlow(); void prefillFields(String username, String fakePassword);
5. How to proceed String[] getUserInputs(); void displayAuthError(String error); void continueFlow(); void prefillFields(String username, String fakePassword); UserView.java interface Every view handling user login should implement this contract
6. How to proceed UserInteractor.java interface Business logic classes handling user auth should implement this contract boolean userIsValid(User user); void connect(User user); void saveUser();
7. How to proceed UserInteractor.java boolean userIsValid(User user); void connect(User user); void saveUser(); String[] getUserInputs(); void displayAuthError(String error); void continueFlow(); void prefillFields(String username, String fakePassword); UserView.java How to tie it all together? Recap:
8. How to proceed UserInteractor UserView continueFlow(); getUserInputs(); displayAuthError(); prefillFields(); saveUser(); connect(); userIsValid(); onUserConnectSuccess(); onUserConnectError(); ? Remember to conserve SRP
9. How to proceed onLoginRequested(); Some event userIsValid(); false true displayAuthError(); getUserInputs(); connect(); . . . UserView UserInteractor
10. How to proceed onLoginRequested(); onUserConnectSuccess(); onUserConnectError(); UserPresenter.java interface
11. The big reveal UserPresenter.java UserInteractor.java UserView.java Model View Presenter
12. The big reveal Business concerns are clearly separated Business rules are unit-testable Swappable implementations Loose coupling TDD is possible ✅ ⚠ Added complexity
13. Dojo?
14. Thank you very much