Road to Modularization(DroidCon NYC 2019)

First commit of Tinder Android app was in April 2013, now the app has grown to over 1.5M LOC, with over 100M downloads on Play store. Android development has changed significantly during the time. Kotlin release versions used to have M-notation, now we live in a Kotlin first world, and everyone is waiting on kapt.

The benefits of modularization are well known in the community. But what are the steps to get there? In this talk, we will briefly cover our app architecture, and the motivation behind the initial effort in 2016, and how we got to an app with over 300 modules. Then we will dive into several modularization strategies where we started getting immediate benefit of a drastically reduced feedback loop.

But the road paved with good intentions might lead you to hell. Through many many bumps, crashes and accidents on the road, those strategies have been evolved to answer many open questions we weren’t sure about initially. How can Dagger help with separation of concerns? How granular each module should be? Where is the glue to stitch everything together? And finally, has build speed actually improved? Join Aaron and Siggi from Android Platform team at Tinder to learn a few things about modularization!

Transcript

1. Road to Modularization Aaron He Siggi Jonsson
2. Android Engineering
3. Android Engineering
4. • 31 Android Engineers + 23 openings Android Engineering
5. • 31 Android Engineers + 23 openings • Hundreds commits every week Android Engineering
6. • 31 Android Engineers + 23 openings • Hundreds commits every week • 2M LOC(85% Kotlin) Android Engineering
7. • 31 Android Engineers + 23 openings • Hundreds commits every week • 2M LOC(85% Kotlin) • 300+ modules Android Engineering
8. • 31 Android Engineers + 23 openings • Hundreds commits every week • 2M LOC(85% Kotlin) • 300+ modules • 1 hour clean build Android Engineering
9. Android Engineering • 31 Android Engineers + 23 openings • Hundreds commits every week • 2M LOC(85% Kotlin) • 300+ modules • 6 min clean build
10. Architecture
11. ATOM
12. Asynchronous Transactional Oriented Manager
13. Asynchronous Transactional Oriented Manager
15. View ViewModel UseCase Repository DataRepository DataStore ApiClient TinderApi 2016
16. Presentation Domain Data Api View ViewModel UseCase Repository DataRepository DataStore ApiClient TinderApi 2016
17. Presentation Domain Data Api Tinder View ViewModel UseCase Repository DataRepository DataStore ApiClient TinderApi 2016
18. Presentation Domain Data Api Tinder View ViewModel UseCase Repository DataRepository DataStore ApiClient TinderApi 2016
19. Presentation Domain Data Api Tinder View ViewModel UseCase Repository DataRepository DataStore ApiClient TinderApi 2017
20. Presentation Domain Data Api Tinder
21. Presentation Domain Data Api Tinder
22. Presentation Domain Data Api Tinder
23. Presentation Domain Data Api Tinder
24. Presentation Domain Data Api Tinder
25. Presentation Domain Data Api Tinder
26. Presentation Domain Data Api Tinder
27. Presentation Domain Data Api Tinder
28. Presentation Domain Data Api Tinder
29. Data class DelightOpenHelperCallbackMigrationTest : DataRobolectricTestCase() { @Test fun upgradeSchemaFromV2() { } . . . . . . . . . . @Test fun upgradeSchemaFromV60() {
30. Data class DelightOpenHelperCallbackMigrationTest : DataRobolectricTestCase() { @Test fun upgradeSchemaFromV2() { } . . . . . . . . . . @Test fun upgradeSchemaFromV60() {
31. Data class DelightOpenHelperCallbackMigrationTest : DataRobolectricTestCase() { @Test fun upgradeSchemaFromV2() { } . . . . . . . . . . @Test fun upgradeSchemaFromV60() {
32. class DelightOpenHelperCallbackMigrationTest : DataRobolectricTestCase() { @Test fun upgradeSchemaFromV2() { } . . . . . . . . . . @Test fun upgradeSchemaFromV60() { Data
33. Modularize by Feature
35. Feature A Feature B Tinder Resources Dependencies Domain
36. Feature A Feature B Tinder Resources Dependencies Domain Superlikable Superlikable
37. Feature A Feature B Tinder Resources Dependencies Domain Superlikable Superlikable
38. Feature A Feature B Tinder Resources Dependencies Domain Superlikable Common Superlikable
39. Feature A Feature B Tinder Resources Dependencies Domain Superlikable Common Base Superlikable
40. Feature A Feature B Tinder Resources Dependencies Domain Superlikable Common Base Superlikable
41. Feature A Feature B Tinder Resources Deps Domain Superlikable Common Base Common Deps Superlikable
42. Feature A Feature B Tinder Resources Deps Domain Superlikable Common Base Common Deps Superlikable
43. Existing features?
44. Feature A Feature B Tinder Resources Deps Domain Superlikable Common Base Superlikable Common Deps
45. Feature A Feature B Tinder Resources Deps Domain Common Base Common Deps
46. Feature A Feature B Tinder Resources Deps Domain Common Base Common Deps
47. Feature A Feature B Tinder Resources Deps Domain Common Base Common Deps
48. Feature A Feature B Tinder Resources Deps Domain Common Base Common Deps
49. Feature A Feature B Feature A Resources Deps Domain Common Base Common Deps Tinder
50. Feature A Feature B Feature A Resources Deps Domain Common Base Common Deps Tinder A
51. Feature A Feature B Feature A Resources Deps Domain Common Base Common Deps Tinder A
52. Feature A Feature B Feature A Resources Deps Domain Common Base Common Deps Tinder A
53. Feature A Feature B Feature A Resources Deps Domain Common Base Common Deps Tinder A <I> “Contracts”
54. Feature A Feature B Feature A Resources Deps Domain Common Base Common Deps Tinder A <I> “Contracts” A Contracts <implements>
55. Feature A Feature B Feature A Resources Deps Common Base Common Deps Tinder A <I> “Contracts” A Contracts
56. Feature A Feature B Feature A Resources Deps Common Base Common Deps Tinder A <I> “Contracts” A Contracts Feature B B B Contracts <I> “Contracts”
57. Feature A Feature B Feature A Resources Deps Common Base Common Deps Tinder A <I> “Contracts” B Contracts Feature B B <I> “Contracts” A Contracts Feature A
58. Common Base Common Deps Com
59. Common Base Common Deps Com
60. Common Base Common Deps Com
61. common:resources common:reactivex common:logger common:app-lifecycle
62. app-lifecycle app-process androidx animation blur navigation resources view dialogs rx-recyclerview reactivex-view runtime-permissions collections datetime glide-transformations locale database logger location moshi kotlinx-coroutines
63. Feature A Feature B Feature A Resources Deps Common Base Common Deps Tinder A Com <I> “Contracts” B Contracts Feature B B <I> “Contracts” A Contracts Feature A common:resources common:reactivex common:logger common:app-lifecycle
64. Feature A Feature B Feature A Resources Deps Tinder A <I> “Contracts” B Contracts Feature B B <I> “Contracts” A Contracts Feature A common:resources common:reactivex common:logger common:app-lifecycle
65. :ui Resources Deps Tinder B Contracts Feature B :domain A Contracts Feature A :data :ui :domain :data common:resources common:reactivex common:logger common:app-lifecycle
66. Independently Deployable?
69. Tinder :B :A :C :common:x :common:y
70. Tinder :B :A :C :common:x :common:y Demo
71. abstract class DemoFeature(context: Context) : ContextWrapper(context) { } abstract fun createView(): View }
72. abstract class DemoFeature(context: Context) : ContextWrapper(context) { abstract fun createView(): View }
73. flavorDimensions 'feature' productFlavors { recs { dimension 'feature' } account { dimension 'feature' } intropricing { dimension 'feature' } profilesuggestions { dimension 'feature' }
74. flavorDimensions 'feature' productFlavors { recs { dimension 'feature' } account { dimension 'feature' } intropricing { dimension 'feature' } profilesuggestions { dimension 'feature' } profileshare { dimension 'feature' } toppicks { dimension 'feature' } // ... }
75. dimension 'feature' } profileshare { dimension 'feature' } toppicks { dimension 'feature' } // ... } recsImplementation project(':recs:ui') // demo build.gradle
76. variantFilter { variant -> def buildTypeName = variant.buildType.name if (buildTypeName.endsWith("release")) { setIgnore(true) } }
77. Join feature modules to Tinder
78. Dagger A Dependency Injector’s 3 Jobs - Jesse Wilson https://publicobject.com/2019/06/25/a-dependency-injectors-3-jobs/
79. Extending App Component
80. Extending App Component SubComponent
81. Extending App Component SubComponent?
82. appComponentProvider.get() .plus(new OnboardingModule()) .inject(this); @ActivityScope @Subcomponent( modules = [ OnboardingModule::class ] ) interface OnboardingComponent { fun inject(nameStepView: NameStepView) } public interface AppComponent { OnboardingComponent plus(OnboardingModule module); }
83. appComponentProvider.get() .plus(new OnboardingModule()) .inject(this); @ActivityScope @Subcomponent( modules = [ OnboardingModule::class ] ) interface OnboardingComponent { fun inject(nameStepView: NameStepView) } public interface AppComponent { OnboardingComponent plus(OnboardingModule module); }
84. appComponentProvider.get() .plus(new OnboardingModule()) .inject(this); interface OnboardingComponent { fun inject(nameStepView: NameStepView) } public interface AppComponent { OnboardingComponent plus(OnboardingModule module); }
85. appComponentProvider.get() .plus(new OnboardingModule()) .inject(this); interface OnboardingComponent { fun inject(nameStepView: NameStepView) } public interface AppComponent { OnboardingComponent plus(OnboardingModule module); }
86. Component Dependency
87. @Component( dependencies = [FeatureComponent.Parent::class], modules = [FeatureModule::class] ) interface FeatureComponent { fun inject(activity: FeatureActivity) interface Parent { fun repository(): Repository fun logger(): Logger fun analyticsTracker(): AnalyticsTracker } } interface FeatureComponentProvider { fun provideFeatureComponent(): FeatureComponent }
88. modules = [FeatureModule::class] ) interface FeatureComponent { fun inject(activity: FeatureActivity) interface Parent { fun repository(): Repository fun logger(): Logger fun analyticsTracker(): AnalyticsTracker } } interface FeatureComponentProvider { fun provideFeatureComponent(): FeatureComponent } @Singleton @Component(...) interface AppComponent : FeatureComponent.Parent
89. } interface FeatureComponentProvider { fun provideFeatureComponent(): FeatureComponent } @Singleton @Component(...) interface AppComponent : FeatureComponent.Parent val component = (context as FeatureComponentProvider) .provideFeatureComponent() // Application val component: FeatureComponent = DaggerFeatureComponent.builder() .parent(appComponent) .build()
90. interface FeatureComponentProvider { fun provideFeatureComponent(): FeatureComponent } @Singleton @Component(...) interface AppComponent : FeatureComponent.Parent val component = (context as FeatureComponentProvider) .provideFeatureComponent() // Application val component: FeatureComponent = DaggerFeatureComponent.builder() .parent(appComponent) .build()
91. @Singleton @Component(...) interface AppComponent : FeatureComponent.Parent // Feature module val component = (context as FeatureComponentProvider) .provideFeatureComponent() // Application val component: FeatureComponent = DaggerFeatureComponent.builder() .parent(appComponent) .build()
93. 0 100 200 300 400 1/1/2017 1/1/2018 1/1/2019 8/1/2019
94. settings settings-analytics settings-email settings-notifications discovery-settings account-settings Modules overdone?
95. What is a feature module?
96. Self contained
97. Self contained :sdk :data :ui :domain :entities :sms-auth
98. Self contained Demo fake-data :sdk :data :ui :domain :entities :sms-auth
99. SmsAuth.launch(this, SMS_AUTH_LOGIN_REQUEST_CODE, config, LaunchMode.LoginWithPhoneNumber()) implementation libs.smsAuth.sdk // build.gradle // LoginActivity
100. SmsAuth.launch(this, SMS_AUTH_LOGIN_REQUEST_CODE, config, LaunchMode.LoginWithPhoneNumber()) implementation libs.smsAuth.sdk // build.gradle // LoginActivity
101. SmsAuth.launch(this, SMS_AUTH_LOGIN_REQUEST_CODE, config, LaunchMode.LoginWithPhoneNumber()) implementation libs.smsAuth.sdk // build.gradle // LoginActivity
102. SmsAuth.launch(this, SMS_AUTH_LOGIN_REQUEST_CODE, config, LaunchMode.LoginWithPhoneNumber()) implementation libs.smsAuth.sdk // build.gradle // LoginActivity
103. SmsAuth.launch(this, SMS_AUTH_LOGIN_REQUEST_CODE, config, LaunchMode.LoginWithPhoneNumber()) implementation libs.smsAuth.sdk // build.gradle // LoginActivity val loginCredential = SmsAuth.extractLoginCredential(data) // LoginActivity#onActivityResult
104. SmsAuth.launch(this, SMS_AUTH_LOGIN_REQUEST_CODE, config, LaunchMode.LoginWithPhoneNumber()) implementation libs.smsAuth.sdk // build.gradle // LoginActivity val loginCredential = SmsAuth.extractLoginCredential(data) // LoginActivity#onActivityResult
105. Self contained Demo :sdk :data :ui :domain :entities fake-data :sms-auth
106. Self contained Tinder Demo :sdk :data :ui :domain :entities fake-data :sms-auth Login
107. Self contained Tinder Demo :sdk :data :ui :domain :entities fake-data :sms-auth Login
108. Compiler avoidance
109. Self contained But to a degree
110. When context changes, Implementation detail changes
111. Tinder Feature A :domain :data :ui Logger Impl Common View
112. Tinder Feature A :domain :data :ui Logger Impl Common View Tinder Lite
113. Tinder Feature A :domain :data :ui Logger Tinder Logger Common View Tinder Lite
114. Tinder Feature A :domain :data :ui Logger Tinder Logger Common View Tinder Lite Lite Logger
115. Tinder Feature A :domain :data :ui Logger Tinder Logger Common View Tinder Lite Lite Logger
116. Next Steps
117. Thanks (of course, we’re hiring) @tindereng @aaronhe42 @siggijons