Mateusz Herych. Android Tech Lead at IG, Google Developer Expert (GDE), Poland.

2. The day your presenters
went too big.
UA Mobile 2017, Kiev

3. Mateusz Herych
- Android Tech Lead, IG
- Google Developer Expert, Android
- GDG Kraków co-organizer

4. Agenda for today

5. Agenda for today
How can you make your Presenters thinner?

6. Agenda for today
How can you make your Presenters thinner?
Some livecoding

7. Story of one screen

9. Pretty simple screen, eh?

10. List of
your
accounts

11. List of
your
accounts
Categories

12. List of
your
accounts
Categories
Current
account’s
indicator

13. List of
your
accounts
Categories
Current
account’s
indicator
Commsbar

14. List of
your
accounts
Categories
Current
account’s
indicator
Commsbar
Oh, tabs there

15. List of
your
accounts
Categories
Current
account’s
indicator
Commsbar
Oh, tabs there
Set as default &
rename

16. Also
- Figures displayed are first taken from REST, then refreshed using a
WebSocket

17. Also
- Figures displayed are first taken from REST, then refreshed using a
WebSocket
- Tapping on an item makes it expanded

18. Also
- Figures displayed are first taken from REST, then refreshed using a
WebSocket
- Tapping on an item makes it expanded
- Switching account
- Rename

19. Almost forgot… empty states!

21. I agree it’s still a fairly simple screen.

22. General architecture

23. View -> Presenter
Interactor1
Interactor2
Interactor3

24. Issue is...

25. Issue is...
- GetAccountsListInteractor

26. Issue is...
- GetAccountsListInteractor
- SetAccountNameInteractor

27. Issue is...
- GetAccountsListInteractor
- SetAccountNameInteractor
- SetAccountAsDefaultInteractor

28. Issue is...
- GetAccountsListInteractor
- SetAccountNameInteractor
- SetAccountAsDefaultInteractor
- … GetUserCommunicationsInteractor, SwitchAccountInteractor,
WhatNotInteractor
Each of them have some way of communicating the progress, success, errors.

29. What you get is AccountsPresenter.java
with over 700 LOC

30. (or AccountsPresenter.kt with under 350
LOC which still doesn’t really help in
terms of its complexity)

31. And 50 unit tests around a single class.

32. How do I know I am going into
a rabbit hole?

33. “Make sure your classes follow Single
Responsibility Principle”

34. Does my Presenter do one thing and one
thing only?

35. Sure it does, it renders things just for this
ONE screen, lol.

36. SRP tends to be subjective.

37. It’s easy to justify that in fact it’s “still just
a one responsibility”.

38. “Hard” warning signs of SRP violation

39. “Hard” warning signs of SRP violation
- Big number of dependencies injected to the constructor (> 5? Maybe > 3?)

40. “Hard” warning signs of SRP violation
- Big number of dependencies injected to the constructor (> 5? Maybe > 3?)
- To state the obvious: LOC

41. “Hard” warning signs of SRP violation
- Big number of dependencies injected to the constructor (> 5? Maybe > 3?)
- To state the obvious: LOC
- Not that obvious: big number of tests for a single unit

42. “Hard” warning signs of SRP violation
- Big number of dependencies injected to the constructor (> 5? Maybe > 3?)
- To state the obvious: LOC
- Not that obvious: big number of tests for a single unit
- Many methods on the View’s interface

43. Initial implementation broke all of those.

45. CommsBarView
AccountsListView
AccountsView

46. EmptyDemoAccountsView

47. ConnectionErrorView

48. You get the drill.

49. Each of those Views has their own
Presenter.

50. How do they communicate?

51. Ok, talk is cheap. Let’s see some code.