A Complete Journey of Android Modularisation

Modularisation is a demanding topic. With modularisation, you can have extraordinary achievements or spectacular failures. We split 200k lines of monolith app modules into 150+ modules with 10+ developers. Now we can contribute faster, test features in isolation and use foundation modules for best practices. With an increasing number of features and code, we needed a scalable codebase. During the process, we find out practical patterns, and we had lots of pitfalls. In the end, improved build speed, uncoupled features, strong foundation for best practices come with modularisation. Separated responsibility layers help team members contribute and contain changes in smaller efforts. Correct modularisation is the foundation of having scalable codebases. From navigation to reusing views and resources, your mental model needs to change. In this talk, you will learn compelling problems you can encounter and how to overcome issues proficiently.

Transcript

1. A Complete Journey of Android Modularisation Sinan Kozak Twitter - @snnkzk
2. 2 Single module code base Nothing wrong with having a single module
3. 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. 4 1 Code conflict No clear ownership 4 Long build time 2 High coupling 3 What problems can modularisation solve?
5. 5 Modularise all the things But how? Photo by Tanalee Youngblood on Unsplash
6. 6 What needs to be a module Modules for software architecture? Modules per feature? Photo by Sarah Arista on Unsplash
7. What is a good modularisation layering? https://www.droidcon.com/2019/11/15/android-at-scale-square
8. 8 My suggestions for modularisation • Public API module per feature • Implementation modules per public API • Fakes implementation for tests • Almost empty app module
9. 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. 10 Possible metrics to track • Lines of code per module • Keep splitting biggest module • Build time • Repeatable build scenarios • Dependency depth • CPU utilisation
11. 11 CPU utilisation
12. 12 CPU utilisation
13. 13 What were our goals? • Maximise CPU utilisation • Flatter dependency graph • Increase isolated UI test count
14. Convention plugin Source of truth for library gradle setup
15. 15 Convention plugin • Set min, target and compile sdk at first • Write plugin as included build
16. Maintenance and Modernisation What is next after modularisation?
17. 17 Maintenance and Modernisation
18. 18 Modernisation • Template module • Configuration cache • Namespaced R file • Cache usage and incremental build improvements • Build performance regression detection
19. Navigation How to open different features?
20. 20 Activity navigation • Intent needs class or class path • Deeplink - App-link? • Input for next activity? • Animation?
21. 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. 22 Use purposeful name Common, core, base are not good names
23. 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. 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. 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. 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. 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. 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
29. Thank you! Q/A Sinan Kozak Twitter - @snnkzk