I have noticed a problem with dependency injection...

# android-architecture

[Lilly]

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?

[wbertan]

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.

[Lilly]

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

[wbertan]

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)

[Lilly]

ok nice, thanks for sharing

[wbertan]

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.

[Tim Oltjenbruns]

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

[wbertan]

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.

[Tim Oltjenbruns]

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

[Tim Oltjenbruns]

It may work out to all be constructor injection and composition within your other modules

[Lilly]

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

[Lilly]

Do you have some advantages disadvantages for both options?

[Tim Oltjenbruns]

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.

[Lilly]

@Tim Oltjenbruns Thanks for sharing your thoughts. Appreciated!