DroidCon London 2022 - KMP and Build System

Exposito Pablo
JobTeaser Engineering
4 min readDec 8, 2022

After Android Makers in Paris at the beginning of the year, we had the pleasure for this end of the year to attend Droidcon in London.
The dimensions aren’t the same, more than 90 talks and over 100 speakers during 2 days, some concessions are needed for such an organization and the speakers have the hard task to make their talks in less than 40 mn, usually answering questions during the small 20 mn between talks. There is obviously no much time for conviviality like coffee break or a long lunch, maybe it’s just a cultural difference ?

But this isn’t the subject, we’re here to talk about Android, but also KMP, flutter, and more related to our field that now have his own Shrine if you ever feel lost.

Thanks to kotlin, our field is growing faster than before, allowing us to develop outside of our comforting Android ecosystem.
While KMM justed reach beta recently, some are already making it to production and share their knowledge about it.

Pamela Hill and Tadeas Kriz present us some tooling allowing to publish and share kotlin xCode Framework as an SDK using KMMBridge on the CI step. During this said step, KMMBridge will be charged to package, version and publish the SDK. No gradle or even kotlin dependencies are needed on the iOS dev machines. And the SDK is treated as a usual one. At the time of this article, KMMBridge is only available with Github Action.

  • But before even considering tooling, it might be best to think about your architecture and the caveat you might encounter on this journey.
  • While sealed class are a great tool for kotlin developers, in the context of a KMP project it would be best no to abuse it as it’s no particularly compatible with iOS environment where Casts won’t work as expected. (But fear not, Moko KSwift aim to fix this compatibility issue among others)
  • Expect/actual give great promises but has limitation like same constructor signature.
  • Some folks went ahead of you, and develop their own architecture solution helping you in your choices, that’s the case of Decompose that was the subject of another talk from his creator Arkadii Ivanov and mokko-mvvm.
  • Using those solutions you’ll then have an awesome architecture allowing you to isolate your business logic and off course allow you to test it. To this extend you could use MockMP or KMP test suite
  • All of that seem quite linear, but we all know it, the journey is full of bugs and mystical crashes and you better have a good approach to debug all of that, a good reporting and loging using CrashKiOS or Kermit might be handy.

KMP might be a big leap for a team or way too early for a project. Before tackling such subjects it would be better to have solid bases, a good build system and dependency management might save you some headaches.

While not all teams might need it, Gradle Enterprise can give you some good insight about your build, and Nelson Osacky will help you to Keep your gradle build in top shape or just point your finger at who has the slowest builds in your team.

Another way to solve some of your issues with gradle could be to create Gradle plugins to extends your build. The best way to plugging into the gradle matrix is to follow Tony Robalik and John Rodriguez into the rabbit hole, you might fall yes, but you might also learn the good practices when creating your tasks

  • Use tasks.named("yourTask") to avoid early/eager task creation
  • Explicitly register your tasks which will return a taskProvider
  • Use withType(java.lang.Class).configureEach(org.gradle.api.Action) instead of simply using withType() directly
  • You’ll of course learn how to reuse effectively your build logic using Convention plugins and inspect your dependencies using some appropriate tooling

With a healthy build system, modularization would become less of a hassle, even less in the company of Josef Raska giving you the keys on how to Flatten your graph

  • Helped with Module Graph Assert plugin , you can enforce module rules within your team, allowing only specifics dependencies, making sure of the heigh of your module, …
  • Keep an eye on your Modules Loc, Height, Longest Path, Modules dependencies and Betweeness centrality (Bottleneck Modules)
  • Analyze your dependencies using Android studio (Code > Analyze Code > dependencies/backward dependencies)
  • For more about modularization, Google recently released their guide to Android app modularization

--

--