Playground Android

This is a template project for Android development. I use it as a way to test new concepts or integrate libraries that are otherwise hard in a more complex project.

Some of the concepts implemented here:

• gradle version catalog, BOM & Bundles (one source of truth)
• sharing build logic with gradle convention plugin
• custom lint-rules
• Makefile with common cli commands
• logcat lib and injecting multiple loggers
• basic networking with ktor #10
• Coil for image loading
• multi module setup
• compose-navigation between feature modules
• dependency injection with kotlin-inject-anvil
  • function-injection demo in @Composable
• USF architecture (much like usf-movies-android)

Getting started

• Download this repository and open the template folder on Android Studio
• in libs.versions.toml change app-namespace to your desired package name
• in AndroidStudio rename the app package sh.kau.playground
• Check if the manifest package was renamed along with the package
• In app/build.gradle.kts, change the applicationId to the new app package

Ready to Use and you're ready to start working on your new app!

App module diagram (multi-module setup)

Below diagram should give you an idea of how the inter module dependencies are setup. In practice, when you add feature modules it is pretty straightforward as the core requirements are already setup. See the Landing feature's build.gradle.kts file as an example for how simple the build script for new features land up being.

The dependency graph is widest at the top (:app module) and becomes more focused and self-contained as you move down through domain and common modules. So modules at the bottom have lesser dependencies and are more self-contained.

• new features are added to :features module
• the core :app module itself assembles all the dependencies (and is intentionally lean)
• template.feature = custom gradle plugin that sets up a fully functional feature for your app
• template.android = custom gradle plugin that has the things you need for a pure android lib
  • think jvm target, minSDK etc. that you don't want to repeat everywhere
• :common modules are shared but can be hot-swapped with another implementation (possible)
• :domain modules are specific to the app but also shared (but not intended to be swapped out)

I talked about this in ep #252 of Fragmented