Slides from mDevCamp 2020 conference This talk is about modularization of the Android apps. Modularization is a big hot topic in the last couple of years and we've jumped on the train too here at Ackee. But this talk will not be about rainbows and puppies and about how everything is perfect with modularized app. I would like to talk about darker sides of modularization, the questions that are shady and noone has the right answer for.

1. Dark side of Android
apps modularization
David Bilík
@bilikdavid

2. #selfpromo
> 8 years experience with Android development
> Android Team Lead @AckeeCZ
> Lecturer of Android course at Czech Technical University in Prague
> Focused on architecture, testing and beautiful designs

3. Why am I here?

4. Why am I here?
> Modularization became popular topic in 2018
> Every conference had at least one talk “How to modularize your app”
> Since we are hype-oriented programmers we hopped on the train in 2019
> But we’ve hit some bumps along the way

5. What we expected
> Faster build times
> Improved architecture
> Preparation for instant apps/dynamic features

6. Modularized architecture
> Main inspiration

7. Modularized architecture

8. Modularized architecture
> Looks simple
> But contains multiple shady areas
> Google does not have the answers
> Community does not have all answers
> Because they do not exist

9. Gradle

10. Gradle
> Apps contains tens of dependencies
> Not all of them used in all modules
> Good idea to define them in one place

11. buildSrc
> Leverage buildSrc folder in gradle project
> Contains common code (constants, tasks) used in build.gradle scripts
> Can be written in Kotlin

12. object Config {
const val minSdk = 26
const val compileSdk = 29
const val targetSdk = 29
val javaVersion = JavaVersion.VERSION_1_8
}
android {
compileSdkVersion Config.compileSdk
defaultConfig {
minSdkVersion Config.minSdk
targetSdkVersion Config.targetSdk
versionCode 1
versionName "1.0"
}
buildSrc/src/main/kotlin/Config.kt
app/build.gradle

13. buildSrc/src/main/kotlin/Deps.kt
object Deps {
"// Koin
private const val koinVersion = "2.0.1"
const val koin = "org.koin:koin-android:$koinVersion"
const val koinScope = "org.koin:koin-androidx-scope:$koinVersion"
const val koinViewModel = "org.koin:koin-androidx-viewmodel:$koinVersion"
"// Epoxy
private const val epoxyVersion = "3.9.0"
const val epoxy = "com.airbnb.android:epoxy:$epoxyVersion"
const val epoxyProcessor = "com.airbnb.android:epoxy-processor:$epoxyVersion"
"// OkHttp
private const val okHttpVersion = "4.3.1"
const val okHttp = "com.squareup.okhttp3:okhttp:$okHttpVersion"
const val okHttpLoggingInterceptor = “com.squareup.okhttp3:logging-interceptor:$okHttpVersion"
…
app/build.gradle
dependencies {
"// Koin
implementation Deps.koin
implementation Deps.koinViewModel

15. Version updates
> Automatic Android Studio version check is not available
> Plugins exists but not they are not suitable for us
> So.. we check manually 😞

16. Shared gradle scripts
> A lot of the build.gradle code will be completely the same
≥ defaultConfig with minSdk, compileOptions, applied plugins, …
> Common code can be extracted and applied in module build.gradle
scripts
> Applied code is merged with the code inside module’s build.gradle script

17. apply plugin: 'com.android.library'
apply plugin: 'kotlin-android'
apply plugin: 'kotlin-android-extensions'
android {
compileSdkVersion Config.compileSdk
defaultConfig {
minSdkVersion Config.minSdk
targetSdkVersion Config.targetSdk
versionCode 1
versionName "1.0"
}
buildTypes {
…
}
productFlavors {
…
}
compileOptions {
sourceCompatibility = 1.8
targetCompatibility = 1.8
}
…
…
kotlinOptions {
jvmTarget = "1.8"
freeCompilerArgs += "-Xopt-in=kotlin.time.ExperimentalTime"
}
testOptions {
unitTests.all {
setIgnoreFailures(true)
}
}
}
gradle/common-library-script.gradle

18. apply from: “$rootDir/gradle/common-library-script.gradle”
dependencies {
implementation Deps.junit
implementation Deps.rxJava
implementation Deps.rxAndroid
implementation Deps.appCompat
}
mymodule/build.gradle

19. android {
productFlavors {
flavorDimensions "api"
devApi {
dimension "api"
}
prodApi {
dimension "api"
}
}
}
gradle/common-library-script.gradle

20. networking/build.gradle
apply from: “$rootDir/gradle/common-library-script.gradle”
android {
productFlavors {
flavorDimensions "api"
devApi {
dimension "api"
buildConfigField("String", "BASE_URL", ""api-development.myapp.com"")
}
prodApi {
dimension “api"
buildConfigField("String", "BASE_URL", ""api.myapp.com"")
}
}
}

21. Build variants

22. Build variants
> Example: flavors defining base url for api environment
> What modules care about this flavor?
≥ :app - control what variant of app to build
≥ :networking - contains buildConfigFields with base api url

23. Build variants

24. * What went wrong:
Could not determine the dependencies of task ':events:compileDebugAidl'.
> Could not resolve all task dependencies for configuration ':events:debugCompileClasspath'.
> Could not resolve project :networking.
Required by:
project :events
> Cannot choose between the following variants of project :networking:
- devApiDebugRuntime
- devApiDebugUnitTestCompile
- devApiDebugUnitTestRuntime
- devApiReleaseAndroidTestCompile
- devApiReleaseAndroidTestRuntime
- devApiReleaseApiElements
…
./gradlew assembleDevApiDebug

25. Build variants

26. events/build.gradle
android {
defaultConfig {
missingDimensionStrategy "api", "devApi"
}
}

27. gradle/common-library-script.gradle
android {
…
productFlavors {
flavorDimensions "api"
devApi {
dimension "api"
}
prodApi {
dimension "api"
}
}
…
}

28. app/build.gradle
android {
…
productFlavors {
flavorDimensions "api"
devApi {
dimension "api"
buildConfigField("String", "BASE_URL", ""api-development.myapp.com"")
}
prodApi {
dimension "api"
buildConfigField("String", "BASE_URL", ""api.myapp.com"")
}
}
…
}

29. networking/src/main/java/…/ApiDefinition.kt
data class ApiDefinition(
val url: HttpUrl
)
fun provideRetrofit(api: ApiDefinition): Retrofit {
return Retrofit.Builder()
.baseUrl(api.url)
.build()
}
networking/src/main/java/…/RetrofitDI.kt
app/src/main/java/…/ApiDI.kt
fun provideApiDefinition(): ApiDefinition{
return ApiDefinition(
BuildConfig.BASE_URL.toHttpUrl()
)
}

30. Final tip
> Improve organization of modules with directories

33. Module folders protip
> Prefix module name with directory for automatic placement

34. Code sharing

35. Code sharing
> Our apps (try to) follow Uncle Bob’s Clean Architecture

36. Clean architecture Android

37. Shared library module

38. Split feature module

39. Shared module

40. Shared module

41. Navigation

42. Navigation
> Feature modules are independent of each other
> ActivityA in :featureA does not have access to ActivityB in :featureB
> unified solution for in-feature and between-feature navigation

43. Navigation #1 solution

44. object Intents {
fun startingActivity(context: Context): Intent? {
return loadClass<Activity>(“cz.ackee.sample.StartingActivity”)
"?.let { Intent(context, it) }
}
}
object Fragments {
fun contactsFragment(context: Context): Fragment? {
return loadClass<Fragment>(“cz.ackee.sample.contacts.ContactsFragment”)
"?.let { Fragment.instantiate(context, it.name) }
}
}
navigation/src/main/…/Intents.kt
navigation/src/main/…/Fragments.kt
fun <T> loadClass(className:String): Class<T>? {
return try {
Class.forName(className)
} catch (e: Exception) {
null
} as? Class<T>
}

45. #1 solution - problems
> Not using typical pattern like MyFragment.newInstance(args)
> Fully qualified class names in Strings not changed in refactorings

46. Arguments passing
> Problems with passing the arguments through :navigation module
> Does not have access to feature classes

47. object Fragments {
fun contactDetailFragment(context: Context, contact: Contact): Fragment? {
return loadClass<Fragment>("cz.ackee.sample.contact.ContactDetailFragment")
"?.let { Fragment.instantiate(context, it.name, bundleOf(Arguments.CONTACT_KEY to contact)) }
}
}
object Fragments {
fun contactDetailFragment(context: Context, contact: Parcelable): Fragment? {
return loadClass<Fragment>("cz.ackee.sample.contact.ContactDetailFragment")
"?.let { Fragment.instantiate(context, it.name, bundleOf(Arguments.CONTACT_KEY to contact)) }
}
}
navigation/src/main/…/Fragments.kt

48. Parcelable solution
> Easiest solution
> Type safety is lost

49. object Fragments {
fun contactDetailFragment(context: Context, contact: ContactDetailNavArgs): Fragment? {
return ClassesCache.loadClassOrNull<Fragment>("cz.ackee.sample.contact.ContactDetailFragment")
"?.let { Fragment.instantiate(context, it.name, bundleOf(NAV_ARGS_KEY to navArgs)) }
}
}
@Parcelize
data class ContactDetailNavArgs(
val contactId: String,
val name: String
): Parcelable
navigation/src/main/…/navargs/ContactDetailNavArgs.kt
navigation/src/main/…/Fragments.kt

50. inline fun <reified T: Parcelable> Fragment.navArgs() : T {
return requireArguments().getParcelable(NAV_ARGS_KEY)
}
class ContactDetailFragment : Fragment() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
toolbar.title = navArgs<ContactDetailNavArgs>().name
}
}
contacts/src/main/…/ContactDetailFragment.kt
navigation/src/main/…/FragmentKtx.kt

51. NavArgs solution
> Improved type safety
> More boilerplate

52. Abstracted navigation
> Introduce abstraction over navigation
> Free Fragments/Activities of knowing details of navigation

53. interface Navigator {
fun openContactDetail(args: ContactDetailNavArgs)
}
class ContactsListFragment : Fragment() {
private val navigator: Navigator by inject()
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
contactsList.setOnContactClickListener { contact "->
navigator.openContactDetail(ContactDetailNavArgs(contact.id, contact.name))
}
}
}
navigation/src/main/…/Navigator.kt
contacts/src/main/…/ContactDetailFragment.kt

54. Navigation Architecture Component
> Navigator implemented with Navigation Architecture Component
> :navigation module still a library module
> Contains navigation graphs, Navigator interface and implementation of this
interface

55. <?xml version="1.0" encoding="utf-8"?>
<navigation xmlns:android="http:"//schemas.android.com/apk/res/android"
xmlns:app="http:"//schemas.android.com/apk/res-auto"
android:id="@+id/navigation_graph"
app:startDestination="@+id/navigation_contacts_list">
<fragment
android:id="@+id/navigation_contacts_list"
android:name="cz.bilik.sample.contacts.ContactsListFragment" >
<action
android:id="@+id/navigation_action_open_contact_detail"
app:destination="@id/navigation_contact_detail"
app:enterAnim="@anim/nav_default_enter_anim"
app:exitAnim="@anim/nav_default_exit_anim"
app:popEnterAnim="@anim/nav_default_pop_enter_anim"
app:popExitAnim="@anim/nav_default_exit_anim" "/>
"</fragment>
<fragment
android:id="@+id/navigation_contact_detail"
android:name="cz.bilik.sample.contacts.ContactDetailFragment" "/>
"</navigation>
navigation/src/main/res/values/nav_graph.xml

56. class NavigationComponentNavigator : Navigator {
private var navigationController: NavController? = null
override fun openContactDetail(navArgs: ContactDetailNavArgs) {
navigationController"?.navigate(
R.id.navigation_action_open_contact_detail,
navArgs.toBundle()
)
}
}
navigation/src/main/…/NavigationComponentNavigator.kt
fun bindController(navigationController: NavController) {
this.navigationController = navigationController
}
fun unbindController() {
this.navigationController = null
}

57. abstract class NavigationActivity : AppCompatActivity() {
val navigator : NavigationComponentNavigator by inject()
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_navigation)
setupNavigation()
}
private fun setupNavigation() {
navigator.bindController(findNavController(R.id.nav_host_fragment))
}
override fun onDestroy() {
super.onDestroy()
navigator.unbindController()
}
}
navigation/src/main/…/NavigationActivity.kt

58. Abstracted navigation
> Growing Navigator interface
≥ Create multiple smaller Navigators and NavigationActivity
implements all of them
> Multiple Activity
≥ Multiple navigation graphs with multiple NavigationActivitys

59. Database

60. Database
> Room used as database library
> No native support for multimodule projects
> Need to define all entities and DAOs in single Database class

61. Database per feature

62. Database per feature
➕ Encapsulated within single module
➕ Each database can have different settings - eg. descructive migrations rule
− Aggregations over mutliple tables not possible
− Multiple connections to database

63. Single database

64. Single database
➕ Easy to maintain
− Breaks the encapsulation of the features.

65. Compromise
> :database module containing definition of RoomDatabase
> Keep DAOs and entities within features

66. Compromise

67. Compromise
> :database module depends on all features and define RoomDatabase class
> DI for DAOs must be defined in this module

68. @Entity(tableName = "contacts")
data class DbContact(
@PrimaryKey(autoGenerate = true) val id: Long = 0,
val eventId: Int,
val name: String
)
features/contacts/…/DbContactfeatures/events/…/DbEvent
@Entity(tableName = "events")
data class DbEvent(
@PrimaryKey val id: Int = 0,
val name: String
)
features/events/…/EventsDao
@Query("""
select events.* from events
join contacts on (contacts.eventId = events.id)
where contacts.id "== :contactId
""")
abstract fun getEventForContact(contactId: Long): DbEvent

69. Testing

70. Testing
> Where to define utilities in tests?
≥ custom JUnit rules for RxJava/Coroutines
≥ extensions on LiveData to retrieve value once available
≥ …

71. Testing module
> Define them in one place
> Can’t be placed in :base module test source set folder
> Gradle does not support dependencies on test source sets of different
module in android projects

72. Testing module
> Separate:testing library module
> Contains also dependencies to common testing dependencies
≥ Mocking framework, testing dependencies for coroutines, AndroidX, …
> Important note - don’t declare this dependencies as testXXX and also don’t
place the code to the test source set folder

73. fun <T> LiveData<T>.getOrAwaitValue(
time: Long = 2,
timeUnit: TimeUnit = TimeUnit.SECONDS,
afterObserve: () "-> Unit = {}
): T {
…
}
libraries/testing/src/main/java/LiveDataKtx.kt
libraries/testing/build.gradle
dependencies {
api Deps.architectureComponentsTesting
api Deps.mockitoInline
api Deps.mockitoKotlin
api Deps.coroutinesTesting
}

74. features/contacts/build.gradle
dependencies {
…
testImplementation project(':libraries:testing')
}

75. Test fixtures
> Same problem with test fixtures of feature module
> How to reuse eg. test doubles in different feature module tests?

76. Test fixtures

77. Testing database

78. Testing database

79. libraries/database-testing/src/main/java/RoomDatabaseRule.kt
class RoomDatabaseRule : TestWatcher() {
lateinit var database: MyDatabase
override fun starting(description: Description?) {
database = Room.inMemoryDatabaseBuilder(ApplicationProvider.getApplicationContext(), MyDatabase"::class.java)
.allowMainThreadQueries()
.build()
}
override fun finished(description: Description?) {
database.close()
}
}

80. @RunWith(AndroidJUnit4"::class)
class ContactsLocalDataSourceTest {
@get:Rule
val databaseRule = RoomDatabaseRule()
private fun createDataSource(): ContactsLocalDataSource {
return ContactsLocalDataSource(
databaseRule.database.contactsDao()
)
}
…
features/contacts/app/src/test/…/ContactsLocalDataSourceTest.kt

81. Networking

82. Networking
> :networking library module with common setup - OkHttpClient, Moshi,
Retrofit
> Each feature contains Retrofit API interface with transfer objects (DTO)
≥ eg. LoginRequest, LoginResponse

83. Networking
> What about generated classes?
≥ gRPC, Swagger-codegen
> Generation of this classes is handled in :networking module
> Feature modules use this generated classes

84. SUMMARY

85. Summary
> Would I modularize new app right from the beginning?
> Have we learned anything?
> What about our expectations?

86. Questions time 🤗

87. Thanks for participation!
@bilikdavid