Fighting against Android for the Right to Use Composition

Поговорим о том, что не так с MVP и его старшим братом MVC. И разберем как обойти ошибки проектирования Android и писать (хотя бы немного) повторно используемый объектно-ориентированный код.

Transcript

1. Fighting against Android for the Right to Use Composition
2. Who am I? • 2+ years Android code monkey • 1+ year JVM back-end dev javanese.online @Miha-x64 @miha_x64 @Harmonizr at @kotlin_mobile and @javanese_questions ❤️OOP, FP, composition
3. Procedural, object-oriented, functional switch-case if-else val mode: Int if (mode == MODE_X) performX(); else preformDefault(); object polymorphism val mode: Mode mode.perform() functional polymorphism val perform: () → Unit perform()
4. The most of Android code is boilerplate • Create a Fragment • Inflate a View • Show/Hide ProgressBar • Show data How many times have you done it?
5. Monolithic Fragment • View — inflate layout, find views, set adapters
6. Monolithic Fragment • View — inflate layout, find views, set adapters; • State — onSaveInstanceState, onViewStateRestored
7. Monolithic Fragment • View — inflate layout, find views, set adapters; • State — onSaveInstanceState, onViewStateRestored; • Context — Activity, Resources, getSystemService
8. Monolithic Fragment • View — inflate layout, find views, set adapters; • State — onSaveInstanceState, onViewStateRestored; • Context — Activity, Resources, getSystemService; • Lifecycle — attach/create/start/resume/pause/stop/destroy/detach
9. Monolithic Fragment • View — inflate layout, find views, set adapters; • State — onSaveInstanceState, onViewStateRestored; • Context — Activity, Resources, getSystemService; • Lifecycle — attach/create/start/resume/pause/stop/destroy/detach; • userVisibleHint — visibility in ViewPager
10. Monolithic Fragment • View — inflate layout, find views, set adapters; • State — onSaveInstanceState, onViewStateRestored; • Context — Activity, Resources, getSystemService; • Lifecycle — attach/create/start/resume/pause/stop/destroy/detach; • userVisibleHint — visibility in ViewPager; • targetFragment, onActivityResult, onRequestPermissionResult.
11. Monolithic Fragment
12. Before talking about MVP... MVP is MVC for UI. It inherits MVC’s problems.
13. Typical controller in web-project
14. Controller vs. SOLID • Is not single-responsible
15. Controller vs. SOLID • Is not single-responsible; • No interfaces — cannot be decorated or substituted
16. Controller vs. SOLID • Is not single-responsible; • No interfaces — cannot be decorated or substituted; • Not segregated
17. Controller vs. SOLID • Is not single-responsible; • No interfaces — cannot be decorated or substituted; • Not segregated; • Implementation dependency
18. Controller vs. SOLID • Is not single-responsible; • No interfaces — cannot be decorated or substituted; • Not segregated; • Implementation dependency; • Does not represent a solid object, its behaviour and state
19. Controller vs. SOLID • Is not single-responsible; • No interfaces — cannot be decorated or substituted; • Not segregated; • Implementation dependency; • Does not represent a solid object, its behaviour and state. Is just a bunch of procedures.
20. MVP: to Decompose Undecomposable A Fragment delegates to Presenter the following items: • View; • State; • Context; • Lifecycle; • userVisibleHint; • targetFragment, onActivityResult, onRequestPermissionResult.
21. MVP • View is dumb and has got broken encapsulation
22. MVP • View is dumb and has got broken encapsulation; • View-Presenter abstraction has leaked
23. MVP • View is dumb and has got broken encapsulation; • View-Presenter abstraction has leaked; • View and Presenter are separated by means of interfaces but without any code reuse and polymorphism
24. MVP • View is dumb and has got broken encapsulation; • View-Presenter abstraction has leaked; • View and Presenter are separated by means of interfaces but without any code reuse and polymorphism; • Presenter is a bunch of procedures, like a Controller
25. MVP • View is dumb and has got broken encapsulation; • View-Presenter abstraction has leaked; • View and Presenter are separated by means of interfaces but without any code reuse and polymorphism; • Presenter is a bunch of procedures, like a Controller; • View and Presenter hold links to each other which is very strange and discouraged practice
26. MVP • View is dumb and has got broken encapsulation; • View-Presenter abstraction has leaked; • View and Presenter are separated by means of interfaces but without any code reuse and polymorphism; • Presenter is a bunch of procedures, like a Controller; • View and Presenter hold links to each other which is very strange and discouraged practice; • Presenter is logically tied to Android platform.
27. MVP View Presenter inflate lifecycle requestPremission onRequestPermissionResult setUserVisibleHint getSystemService
28. Presenter implementation inheritance What about extending existing Presenter for similar use-case?
29. Presenter implementation inheritance What about extending existing Presenter for similar use-case?
30. Presenter implementation inheritance What about extending existing Presenter for similar use-case? Inheritance is a procedural technique for code reuse. Yegor Bugayenko Favor composition over inheritance. Joshua Bloch
31. Presenter implementation inheritance What about extending existing Presenter for similar use-case?
32. Interactor / Use Case • No concrete and focused purpose — responsible for nothing and everything
33. Interactor / Use Case • No concrete and focused purpose — responsible for nothing and everything; • Not a solid object, similarly to Controller.
34. CLEAN or VIPER Each feature is scattered through these layers.
35. CLEAN or VIPER Each feature is scattered through these layers. • Many files with many LOC
36. CLEAN or VIPER Each feature is scattered through these layers. • Many files with many LOC; • Hard to modify
37. CLEAN or VIPER Each feature is scattered through these layers. • Many files with many LOC; • Hard to modify; • Hard to trace changes
38. CLEAN or VIPER Each feature is scattered through these layers. • Many files with many LOC; • Hard to modify; • Hard to trace changes; • Single layer itself is useless
39. CLEAN or VIPER Each feature is scattered through these layers. • Many files with many LOC; • Hard to modify; • Hard to trace changes; • Single layer itself is useless. Typical sample of Baklava-code.
40. Android The things are even worse because of Android rules
41. Android The things are even worse because of Android rules: • Fragments forbid composition
42. Android The things are even worse because of Android rules: • Fragments forbid composition; • One Fragment + Presenter per use case — no code reuse!
43. Android The things are even worse because of Android rules: • Fragments forbid composition; • One Fragment + Presenter per use case — no code reuse! • Fragment resolves its own dependencies, like singleton
44. Android The things are even worse because of Android rules: • Fragments forbid composition; • One Fragment + Presenter per use case — no code reuse! • Fragment resolves its own dependencies, like singleton; • Passing an argument deeply through flow based on Fragment stack is painful and unmaintainable.
45. DI containers • Just adding noise and indirection bind(class).toInstance(instance) @Inject @Autowired @Scope @Qualifier @ComponentScan @Module
46. DI containers • Just adding noise and indirection; • Inject different implementations of the same interfaces?
47. DI containers • Just adding noise and indirection; • Inject different implementations of the same interfaces? • This is a dead end: we’ll get scopes and qualifiers, configs which can break something somewhere, dependencies on implementations instead of abstractions
48. DI containers • Just adding noise and indirection; • Inject different implementations of the same interfaces? • This is a dead end: we’ll get scopes and qualifiers, configs which can break something somewhere, dependencies on implementations instead of abstractions; • This introduces semantics of dynamic weakly-typed languages.
49. https://github.com/JavaneseOnline/ JavaneseBackend/blob/master/src/main/kotlin/ online/javanese/JavaneseServer.kt Life without DI containers Actually, you don’t need DI automation at all.
50. Android acts like a bad DI container Application Activity Activity Service Fragment Fragment Child Fragment Fragment Fragment Fragment Fragment Child Fragment He-he
51. userVisibleHint boilerplate
52. What we need • Reuse Fragments or Presenters for similar screens by means of object or functional composition Search books Effective Java, 3rd Edition by Joshua Bloch Java Generics FAQ by Angelika Langer Java Performance: The... by Scott Oaks Thinking in Java, 4th edit... by Bruce Eckel Kotlin in Action by D. Jemerov and S. Isakova Search books Effective Java, 3rd Edition by Joshua Bloch Java Generics FAQ by Angelika Langer Java Performance: The... by Scott Oaks Thinking in Java, 4th edit... by Bruce Eckel Kotlin in Action by D. Jemerov and S. Isakova Paradigms Books Websites Procedural Simple and Annoying Functional Fascinating and Crazy Train Procedural Old and digesting Object-Oriented Interfaces and Composition Procedural You can write it even in Java Amazon.com Expensive books GitHub.com My favourite social net Twitter.com Read programmers’ jokes StackOverflow.com Downvote stupid questions Javanese.online WTF is this? Search paradigms Search websites
53. What we need • Reuse Fragments or Presenters for similar screens by means of object or functional composition; • Escape onActivityResult and onRequestPermissionResult hell
54. What we need • Reuse Fragments or Presenters for similar screens by means of object or functional composition; • Escape onActivityResult and onRequestPermissionResult hell; • Allow hierarchical communication (parent-child)
55. What we need • Reuse Fragments or Presenters for similar screens by means of object or functional composition; • Escape onActivityResult and onRequestPermissionResult hell; • Allow hierarchical communication (parent-child); • Transparent work with userVisibleHint
56. What we need • Reuse Fragments or Presenters for similar screens by means of object or functional composition; • Escape onActivityResult and onRequestPermissionResult hell; • Allow hierarchical communication (parent-child); • Transparent work with userVisibleHint; • SOLID, reusable, cross-platform Presenters.
57. route is an object endpoint is an object I am an object we are objects https://github.com/JavaneseOnline/KRUD/blob/master/krud-core/src/main/kotlin/online/javanese/krud/crud/Crud.kt Refactored Controller
58. Healthy person’s Presenter https://github.com/Miha-x64/Validation/
59. Healthy person’s Presenter
60. Previous problem statement Procedural code Easy to break ‘Customizable object’ antipattern
61. Previous solution: «Safe Fragments» https://github.com/Miha-x64/Advanced-Kotlin-Patterns
62. Previous solution: «Safe Fragments» • All arguments required to be Parcelable. OK for data and functional objects, not for Observables, DB or net connections
63. Previous solution: «Safe Fragments» • All arguments required to be Parcelable. OK for data and functional objects, not for Observables, DB or net connections; • Ugly constructors
64. Previous solution: «Safe Fragments» • All arguments required to be Parcelable. OK for data and functional objects, not for Observables, DB or net connections; • Ugly constructors; • Using Bundles
65. Previous solution: «Safe Fragments» • All arguments required to be Parcelable. OK for data and functional objects, not for Observables, DB or net connections; • Ugly constructors; • Using Bundles • possible typos in keys
66. Previous solution: «Safe Fragments» • All arguments required to be Parcelable. OK for data and functional objects, not for Observables, DB or net connections; • Ugly constructors; • Using Bundles • possible typos in keys; • possible heap pollution in getParcelable<T>
67. Previous solution: «Safe Fragments» • All arguments required to be Parcelable. OK for data and functional objects, not for Observables, DB or net connections; • Ugly constructors; • Using Bundles • possible typos in keys; • possible heap pollution in getParcelable<T>; • custom Map and List storage surprises.
68. Object graph: good architecture Application Activity Activity Service Fragment Fragment Child Fragment Fragment Fragment Fragment Fragment Child Fragment
69. Solution «SufferlessFlawless» helps working around pain Android’s flaws
70. PresenterTag is a token for obtaining Presenter. Parcelable, can be passed anywhere. Similar to URL-based navigation, but type-safe.
71. Implement PresenterFactory, create Presenters for all possible Tags.
72. Create a Fragment using this tag
73. Create a Fragment using this tag Shortcut for SupportFragment(RootPresenterTag, ParcelUnit)
74. ^ what’s this?
75. Pass whatever you need
76. Let’s write a reusable presenter
77. Passing data back and forth
78. Passing data back and forth <- Argument
79. Passing data back and forth <- Argument <- result handler
80. Passing data back and forth <- Argument <- result handler optional cancellation handler ^
81. Passing data back and forth <- Argument <- result handler Handler functions survive config changes. Must be pure! Neither partial application nor capturing is allowed. optional cancellation handler ^
82. Passing data back and forth
83. Passing data back and forth
84. userVisibleHint
85. userVisibleHint
86. userVisibleHint
87. userVisibleHint
88. userVisibleHint
89. Requesting Permissions
90. Requesting Permissions =- requestCode
91. Requesting Permissions =- requestCode ^ permission result handler
92. Requesting Permissions =- requestCode ^ permission result handler =- show rationale
93. Requesting Permissions =- requestCode ^ permission result handler ^ permission list =- show rationale
94. Requesting Permissions continue ^
95. Requesting Permissions continue ^ proceed ^
96. Requesting Permissions
97. Starting Activities
98. What’s next? • Reuse Presenters
99. What’s next? • Reuse Presenters; • Delegate tasks to small objects
100. What’s next? • Reuse Presenters; • Delegate tasks to small objects; • Write cross-platform delegates when you need it
101. What’s next? • Reuse Presenters; • Delegate tasks to small objects; • Write cross-platform delegates when you need it; • Use ViewModels or whatever you want.
102. Try, contribute, ask, complain https://github.com/Miha-x64/Flawless javanese.online @Miha-x64 @miha_x64 @Harmonizr at @kotlin_mobile and @javanese_questions