A Complete Journey of Android Modularisation Sinan Kozak Twitter - @snnkzk

2 Single module code base Nothing wrong with having a single module

3 Legacy code base • There might be one or two giant modules • Lots of features in same module • Build times are longer than your lunch time

4 1 Code conflict No clear ownership 4 Long build time 2 High coupling 3 What problems can modularisation solve?

5 Modularise all the things But how? Photo by Tanalee Youngblood on Unsplash

6 What needs to be a module Modules for software architecture? Modules per feature? Photo by Sarah Arista on Unsplash

What is a good modularisation layering? https://www.droidcon.com/2019/11/15/android-at-scale-square

8 My suggestions for modularisation • Public API module per feature • Implementation modules per public API • Fakes implementation for tests • Almost empty app module

9 What is the goal? • Boundaries between features • How many modules per team? • Better build times • How fast is enough? • Isolated tests • What will be the cost?

10 Possible metrics to track • Lines of code per module • Keep splitting biggest module • Build time • Repeatable build scenarios • Dependency depth • CPU utilisation

11 CPU utilisation

12 CPU utilisation

13 What were our goals? • Maximise CPU utilisation • Flatter dependency graph • Increase isolated UI test count

Convention plugin Source of truth for library gradle setup

15 Convention plugin ● Set min, target and compile sdk at first ● Write plugin as included build

Maintenance and Modernisation What is next after modularisation?

17 Maintenance and Modernisation

18 Modernisation • Template module • Configuration cache • Namespaced R file • Cache usage and incremental build improvements • Build performance regression detection

Navigation How to open different features?

20 Activity navigation • Intent needs class or class path • Deeplink - App-link? • Input for next activity? • Animation?

21 Fragment navigation • In feature fragment navigation is different than cross feature fragment navigation • AndroidX Navigation? • XML doesn’t work • Nav Graph DSL and Deeplink • Passing input needs to be simplified

22 Use purposeful name Common, core, base are not good names

23 Split the legacy Do not keep reusing a messy legacy module Create new modules for the part you need Photo by Brina Blum on Unsplash

24 New module for new code Use smaller modules to contain different logic based on they do Keep them in isolation to increate reuse Photo by Sen on Unsplash

25 Learning curve 01 02 03 Explain with visual https://github.com/vanniktech/gradle- dependency-graph-generator-plugin Lint checks https://github.com/autonomousapps/ dependency-analysis-android-gradle- plugin Graph assertion https://github.com/jraska/modules- graph-assert Photo by Drew Beamer on Unsplash

26 Where to start • Move all the code in app module to a library • New features are great candidates • Extract reusable code pieces to new module

27 Team can quickly add new features or delete old ones while building faster Faster delivery Features can live without depending on each other’s implementation Less conflict Modules have clear names and responsibilities Clear ownership

28 Summary • Modularisation is a mental modal • Creating new module should be habit • Be careful to not end up with worse than what you started • Track your progress

Thank you! Q/A Sinan Kozak Twitter - @snnkzk