Scaling Android without a Monorepo

Talk given at Droidcon NewYork on September 20th, 2024.

Transcript

1. Ahmed El-Helw - Abdulahi Osoble without a Monorepo Scaling Android Development HudHud Maps - Careem Technologies
2. This Talk is Not Monorepo vs non-Monorepo
3. Starting Point Sharing Libraries
5. Merging 2 Apps
7. “MiniApps” are just Groupings of Features
10. Container (App Shell) * Lives in its own repository * “Cont a ins” (depends on) a ll the fe a tures a nd deleg a tes to them * Outputs the f in a l a pk th a t goes to the Pl a y Store
11. Architectural Principles
12. * No fe a ture directly depends on a nother * Fe a tures a re option a l (T&Cs a pply) * Aim tow a rds not h a ving n di ff erent w a ys of doing things
13. inte rf ace Feat ur eFacto ry { fu n p r ovideFeat u r e(dependenciesP r ovide r : DependenciesP r ovide r ): Feat ur e } inte rf ace Feat ur e { // .. . }
14. inte rf ace Feat ur eFacto ry { fu n p r ovideFeat u r e(dependenciesP r ovide r : DependenciesP r ovide r ): Feat ur e } inte rf ace Feat ur e { // .. . }
15. inte rf ace DependenciesP r ovide r { fu n ana ly tics(): Ana ly ticsP r ovide r fu n expe r iments(): Expe r iments fu n l ocationDependencies(): LocationDependencies fu n netwo rk ingDependencies(): Netwo r k ingDependencies }
17. Dependencies • Cont a iner implements DependenciesP r ovide r • Fe a ture doesn't need to know the concrete type • We c a n ch a nge det a ils without fe a tures needing to m a ke a ny ch a nges a s long a s the API is consistent
21. Dependencies Provider * it’s a n interf a ce, so we c a n h a ve fun with individu a l dependencies * Wr a p it * No-op it * Repl a ce it
22. Navigating with Deep Links
23. scheme: / / <feature id>/<parameters>
24. inte rf ace DeepLin k Reso l ve r { f u n r eso l ve( ur i: St r ing): Intent? }
25. inte rf ace Feat ur e { f u n deepLin k Reso l ve r (): DeepLin k Reso l ve r ? = n ul l }
26. fu n r eso l veDeepLin k ( ur i: St r ing): Intent? { va l host = u r i.pa r seHost() va l f eat ur e = feat ur es.getO r Defa ul t(host, n ul l ) r et ur n f eat u r e ?. deepLin k Reso l ve r () ? .r eso l ve( u r i) }
27. fu n r eso l veDeepLin k ( ur i: St r ing): Intent? { va l host = u r i.pa r seHost() va l f eat ur e = feat ur es.getO r Defa ul t(host, n ul l ) r et ur n f eat u r e ?. deepLin k Reso l ve r () ? .r eso l ve( u r i) }
28. fu n r eso l veDeepLin k ( ur i: St r ing): Intent? { va l host = u r i.pa r seHost() va l f eat ur e = feat ur es.getO r Defa ul t(host, n ul l ) r et ur n f eat u r e ?. deepLin k Reso l ve r () ? .r eso l ve( u r i) }
29. Registration
30. va l feat u r eFacto r ies = mapOf( " r ides" to RidesFacto ry (), " f ood" to FoodFacto ry () )
31. imp l ementation( l ibs. f eat ur e. r ides) imp l ementation( l ibs. f eat ur e.food)
32. / / imp l ementation( l ibs. f eat ur e. r ides) imp l ementation( l ibs. f eat ur e.food)
33. Push Noti f ications • Received by the cont a iner a nd deleg a ted, b a sed on a f ield, to the proper fe a ture
34. How do teams develop?
37. Librarisize the Container
39. CI/CD
40. Sharing steps
41. Common checks
42. Dependency Diff c a reem/dependency-di ff -tldr
43. Size Delta J a keWh a rton/di ff use
45. Manifest Diff
46. Source Compatibility ch a nges to...
47. Source Compatibility ch a nges to...
48. Binary Compatibility
52. Run It
61. Binary Compatibility • Gr a dle will compile e a ch module a g a inst the st a ted version • For p a ck a ging a nd runtime, Gr a dle picks the "newest" version
62. Tooling can Help for our Libs • https://github.com/Kotlin/bin a ry-comp a tibility-v a lid a tor • https://github.com/tylerbwong/met a l a v a -gr a dle
63. Dependency Ownership • Pl a tform Dependencies • Fe a ture speci f ic Dependencies
64. Dependency Alignment • Publish BOM or Version c a t a log • Centr a lizing control of BOM/Version c a t a log a t a pl a tform level • Pl a tform dependencies only
65. Challenges • More di ff icult to m a ke ch a nges a cross a ll a pps • Deprec a tions a re tricky to m a ke • Extr a cting st a nd a lone SDKs is tricky
66. Thank You
67. for some smaller teams having devx is a distant dream but they can continue to scale until their codebase is as big as a whale ignoring the monorepo reviews multiple repos they will use one main repository controls the release version bump PRs will certainly increase since every team builds on their own tests and makes sure it works on their phone uploads their new version to internal maven the ability to rollback makes it a haven tooling comes into play helping to fi nd bugs and slay detect hidden changes before they break catch them early before the mistake di ff erences in size of apks dependency di ff s across the days a central team controls dependencies setting the version and avoiding redundancies let's not forget compatibility too binary and source to name a few using the tools and being aware helps save us from lots of despair unfortunately, that is all the time allotted for this summary rhyme written with 0% GPT now go enjoy sessions and co ff ee
68. Scaling with Kotlin Multiplatform • Te a ms h a ve their own KMP dependencies • Choice between n a mesp a ce cl a shing a nd "KMP" per fr a mework t a x on iOS • Bridges h a ve to be repe a ted, since types a re a ll slightly di ff erent