[Mateusz Herych] The ultimate guide to MVP pattern on Android

Presentation from GDG DevFest Ukraine 2016.
Learn more at: https://devfest.gdg.org.ua

Transcript

1. #dfua
2. #dfua The ultimate guide to MVP on Android
3. #dfua The ultimate guide to MVP on Android
4. #dfua The one random team’s guide to MVP on Android that may work for your project
5. #dfua The one random team’s guide to MVP on Android that may work for your project or not.
6. #dfua Hey, I am Mateusz Mateusz Herych Android guy @ IG Google Developer Expert Android Google Developers Group Kraków co-org
7. #dfua
8. #dfua Model-View-Presenter
9. #dfua Why
10. #dfua Why - Many classes, interfaces
11. #dfua Why - Many classes, interfaces - I have a small freelance project, won’t help me much
12. #dfua Why - Many classes, interfaces - I have a small freelance project, won’t help me much - Won’t make my life any easier
13. #dfua
14. #dfua
15. #dfua Himalayas Kanchenjunga - 8586
16. #dfua Himalayas Kanchenjunga - 8586 Mount Everest - 8848
17. #dfua Himalayas Kanchenjunga - 8586 Mount Everest - 8848 MessageViewFragmentBase - 9112
18. #dfua Shame on you, Himalayas.
19. #dfua Why - Huge Activities and Fragments are hard to test
20. #dfua Why - Huge Activities and Fragments are hard to test - Huge Activities and Fragments are impossible to unit test
21. #dfua Why - Huge Activities and Fragments are hard to test - Huge Activities and Fragments are impossible to unit test - People start to not test anything at all, because vast amount of logic belongs to Activities / Fragments anyways
22. #dfua Why - Huge Activities and Fragments are hard to test - Huge Activities and Fragments are impossible to unit test - People start to not test anything at all, because vast amount of logic belongs to Activities / Fragments anyways - Multiple responsibilities - same class is doing complex animations and converting data from DB / REST format to the Adapter
23. #dfua Word about Mosby
24. #dfua Why we don’t use it? - Fact (positive one): Mosby is a library, not a framework
25. #dfua Why we don’t use it? - Fact (positive one): Mosby is a library, not a framework - Still, it influences your design a little bit, we wanted to avoid that
26. #dfua Why we don’t use it? - Fact (positive one): Mosby is a library, not a framework - Still, it influences your design a little bit, we wanted to avoid that - Some problems that already have ready solutions in Mosby, we wanted to solve in a different way (like retaining presenters)
27. #dfua Stuff we use RxJava
28. #dfua Stuff we use RxJava Dagger2
29. #dfua Stuff we use RxJava Dagger2 Obviously, tons of other libraries as well, however they’re not influencing our MVP.
30. #dfua View As dumb as possible
31. #dfua View As dumb as possible
32. #dfua View As dumb as possible View delegates user’s behavior to Presenter operating on raw data - like row ids in terms of clicking on a List
33. #dfua View As dumb as possible View delegates user’s behavior to Presenter operating on raw data - like row ids in terms of clicking on a List View is responsible for performing Animations
34. #dfua View As dumb as possible View delegates user’s behavior to Presenter operating on raw data - like row ids in terms of clicking on a List View is responsible for performing Animations Implements an interface
35. #dfua View As dumb as possible View delegates user’s behavior to Presenter operating on raw data - like row ids in terms of clicking on a List View is responsible for performing Animations Implements an interface Activity / Fragment / Custom View
36. #dfua
37. #dfua We try not to have to unit test our Views.
38. #dfua What we want to achieve is to make such tests useless.
39. #dfua
40. #dfua Presenter - Glue code between View and the rest of the code
41. #dfua Presenter - Glue code between View and the rest of the code. - Converts Model’s data to be easily displayed on a View.
42. #dfua Presenter - Glue code between View and the rest of the code. - Converts Model’s data to be easily displayed on a View. - Is retained between configuration changes, like orientation changes (more about that few slides further!)
43. #dfua Presenter - Glue code between View and the rest of the code. - Converts Model’s data to be easily displayed on a View. - Is retained between configuration changes, like orientation changes (more about that few slides further!) - In a nutshell, everything that stayed in a Fragment in our non-MVP architecture, but wasn’t strictly UI related.
44. #dfua Presenter - Glue code between View and the rest of the code. - Converts Model’s data to be easily displayed on a View. - Is retained between configuration changes, like orientation changes (more about that few slides further!) - In a nutshell, everything that stayed in a Fragment in our non-MVP architecture, but wasn’t strictly UI related. - Doesn’t implement an interface
45. #dfua Interfaces for presenters - We use Dagger.
46. #dfua Interfaces for presenters - We use Dagger. - Using interfaces will force you to explicitly map your Interfaces to Concrete implementation
47. #dfua Interfaces for presenters - We use Dagger. - Using interfaces will force you to explicitly map your Interfaces to Concrete implementation - It doesn’t change anything from the unit tests perspective - you can still stub your concrete classes
48. #dfua Interfaces for presenters - We use Dagger. - Using interfaces will force you to explicitly map your Interfaces to Concrete implementation - It doesn’t change anything from the unit tests perspective - you can still stub your concrete classes https://medium.com/@mherych/do-i-need-to-create-interfaces-for-my-pres enters-9abe0897f873#.896w7lyt7
49. #dfua Presenters vs Android SDK
50. #dfua Presenters vs Android SDK - Some people claim that Presenters shouldn’t be using Android components.
51. #dfua Presenters vs Android SDK - Some people claim that Presenters shouldn’t be using Android components. - We do not.
52. #dfua Presenters vs Android SDK - Some people claim that Presenters shouldn’t be using Android components. - We do not. - Sometimes you need to delegate lifecycle methods (onPause(), onStart(), …)
53. #dfua Presenters vs Android SDK - Some people claim that Presenters shouldn’t be using Android components. - We do not. - Sometimes you need to delegate lifecycle methods (onPause(), onStart(), …) - Presenter is in fact still a presentation layer
54. #dfua Presenters vs Android SDK - Some people claim that Presenters shouldn’t be using Android components. - We do not. - Sometimes you need to delegate lifecycle methods (onPause(), onStart(), …) - Presenter is in fact still a presentation layer - No real benefits (?)
55. #dfua Model - Business data gathered from an application/data layer
56. #dfua Model - Business data gathered from an Application/data layer - The REAL stuff happens here
57. #dfua Model - Business data gathered from an Application/data layer - The REAL stuff happens here - Not related to Android, no Android SDK is being used
58. #dfua Model - Business data gathered from an Application/data layer - The REAL stuff happens here - Not related to Android, no Android SDK is being used - Basically it starts with some interface that reflects some business process...
59. #dfua Model - Business data gathered from an Application/data layer - The REAL stuff happens here - Not related to Android, no Android SDK is being used - Basically it starts with some interface that reflects some business process… - … and then consists from various classes that are splitted by their responsibilities
60. #dfua Model - Business data gathered from an Application/data layer - The REAL stuff happens here - Not related to Android, no Android SDK is being used - Basically it starts with some interface that reflects some business process… - … and then consists from various classes that are splitted by their responsibilities (db repositories, retrofit services, actual business logic, etc.)
61. #dfua V P Stuff
62. #dfua SVP
63. #dfua V P Stuff onItemSelected()
64. #dfua V P Stuff onItemSelected() setItemSelected(int)
65. #dfua V P Stuff onItemSelected() setItemSelected(int) onMarketChanged()
66. #dfua V P Stuff onItemSelected() setItemSelected(int) onMarketChanged() Events (Rx)
67. #dfua Lifecycle How many of you block orientation change in your app?
68. #dfua Lifecycle Oh, did I mention Nougat?
69. #dfua Dagger Scopes
70. #dfua Dagger Scopes Scopes are local singletons (local in a single component/subcomponent)
71. #dfua Dagger Scopes Scopes are local singletons (local in a single component/subcomponent) One default scope in Dagger2: @Singleton
72. #dfua Dagger Scopes AppComponent - @AppScope
73. #dfua Dagger Scopes AppComponent - @AppScope SessionComponent - @SessionScope
74. #dfua Dagger Scopes AppComponent - @AppScope SessionComponent - @SessionScope (logout/switch environment is basically recreation of this component)
75. #dfua Dagger Scopes AppComponent - @AppScope SessionComponent - @SessionScope (logout/switch environment is basically recreation of this component) NonConfigurationComponent
76. #dfua Dagger Scopes AppComponent - @AppScope SessionComponent - @SessionScope (logout/switch environment is basically recreation of this component) NonConfigurationComponent ActivityComponent
77. #dfua @NonConfiguration Scope
78. #dfua getLastNonConfigurationScope() Deprecated for years - documentation tells you to use retained Fragments (meh)
79. #dfua getLastNonConfigurationScope() Deprecated for years - documentation tells you to use retained Fragments (meh) Deprected so you won’t break LoaderManager and FragmentManager, not because it’ll be removed anytime soon
80. #dfua getLastNonConfigurationScope() Deprecated for years - documentation tells you to use retained Fragments (meh) Deprected so you won’t break LoaderManager and FragmentManager, not because it’ll be removed anytime soon Yep, we use the exact same mechanism Android is using for retaining FragmentManager and LoaderManager
81. #dfua getLastNonConfigurationScope() Deprecated for years - documentation tells you to use retained Fragments (meh) Deprected so you won’t break LoaderManager and FragmentManager, not because it’ll be removed anytime soon Yep, we use the exact same mechanism Android is using for retaining FragmentManager and LoaderManager Finally, getLastCustomNonConfiguration(), not deprecated, in AppCompatActivity.
82. #dfua How does your onSaveInstanceState() look like?
83. #dfua We killed it.
84. #dfua We killed it. (almost)
85. #dfua if (isFinishing()) { presenter.die(); }
86. #dfua if (!isChangingConfigurations()) { presenter.die(); }
87. #dfua Don’t keep Activities
88. #dfua Memory restrictions
89. #dfua Code or didn’t happen.
90. #dfua The truth is…
91. #dfua … you will fail.
92. #dfua Do not overcomplicate.
93. #dfua MVP won’t make your hacks to make Toolbar work as you wish any easier.
94. #dfua It won’t remove that EditText memory leak either.
95. #dfua Neither it will resolve all the problems you have with WebViews.
96. #dfua Architecture has only one job.
97. #dfua Architecture needs to answer questions.
98. #dfua If I am adding a new stuff, where to add it?
99. #dfua Make it FIT your needs.
100. #dfua Iterate, pair program, discuss
101. #dfua Find your way!
102. #dfua Questions?