I have noticed a problem with dependency injection and *multi-module project*s. I have a clean-like architecture using Koin as DI library, but since my android application module is responsible for creating the DI graph, it is forced to know all other modules to grab its "koin modules". To overcome this my only idea is to create a new module called, e.g. di that knows all other modules and defines the "koin modules" so the android application module just need to know the di module. But is this approach common in practice?

We do this, we have an

all-common

, which "aggregates" all shared and common modules, so Android only depends on this one to get all shared modules.

@wbertan Do you use this module also for dependency injection or just to share common stuff.

Each module is responsible to create their own Koin

module

, then on the

all-common

we expose a method

initKoin

, which Android/iOS then calls to configure and initialise Koin itself. On this

initKoin

we have the list of all shared modules there, which they are loaded in Koin. Basically to add a new module in DI: • Create the module itself and create the Koin

module

for the module; • Add as dependency to

all-common

; • Go inside the

initKoin

and add the Koin module in the list; • "Done"; (At least the DI part is done)

ok nice, thanks for sharing

Here: https://medium.com/clearscore/drivescore-kmm-journey-episode-iii-issues-and-solutions-a83f58234b2#3fce From last year, we basically still have same things (just moved away from

packForXcode

and we finally remove the Dagger/Hilt), but in essence can see our structure and "architecture" for DI. In that session

Umbrella modules

and in the other

Interop Koin and Dagger/Hilt

to get roughly the full picture.

What do you use Koin for in your library modules? Are they UI or something else?

We share up to the ViewModel in our project 🙃 and we have 59 modules in KMM (plus 17 that is just Android). We have UseCases there used in different modules, we have a

ResourceProvider

to do some handling with text and helper functions to MokoResources, we have some classes abstracting things from Platforms, Like Analytics, their SDK is per platform, we have our own abstractions, leaving the platforms to create and provide it.

Well I may be assuming too much, but if you're just sharing up to the viewmodel layer, you may not even need koin in your other modules

Good point @Tim Oltjenbruns. In my case I have 80 % constructor injection and 20 % composition (it's a small project and in active development, so changes are not a problem). So finally, the question will be 20% composition work on my own vs. Koin + a shared gradle module to handle DI

When you conveniently don’t have to worry about someone else’s object lifecycle (Android UI), I think there are many advantages to doing the composition “yourself”. Especially when your project is just starting out. • Less commitment to a DI library, and more able to change later • The boundary between your modules is more in your control • The little bit of extra hassle could encourage better software design • The composition code can be eerily similar to a Koin module, without the Koin • The IDE can help a lot more with cross-module refactors Disadvantages: • More commitment to DI choice • Less boundary control • More difficult to see structural code smells • Potentially more busywork when evolving your architecture • Less IDE help I would expect the core disadvantage of doing the composition yourself in this case to be “Potentially more busywork when evolving your architecture”. But I would also expect that the benefits of the additional IDE help, more control over boundaries, and more visibility to smells would balance that out. What do I know about your code though? I’m just a random dude on the internet.

@Tim Oltjenbruns Thanks for sharing your thoughts. Appreciated!