I really appreciate the Now in Android app for giving me a lot of insight. I am reading the Modularization learning journey in the Now In Android app. I found this sentence.

A feature module should have no dependencies on other feature modules.

I was wondering what happens when a feature nests more than once. For example, if there is an "article screen" that has a "your article tab" and "daily article tab" in it, I thought that the feature module would want to depend on the feature module. In such a case, does nowinandroid assume that all tabs are implemented in the core module? If it is a simple screen, you can put it in the article feature module, but assume it is a complex and large function.

Layout structure
screen -> "article screen" -> "daily article tab"

module structure
app -> feature-article(contains "article screen") -> core-dailyarticle(contains "daily article tab")
                                                  -> core-yourarticle(contains "your article tab")

As I write this message, I am beginning to think that this is not a problem because it works fine. https://github.com/android/nowinandroid/blob/main/docs/ModularizationLearningJourney.md#types-of-modules-in-now-in-android

feature

modules in

nowinandroid

are strictly presentation layer. So it doesn't make much sense for one presentation layer to depend on other presentation layer. You could share viewmodel tho, but in that case, you could have nested and parent screen inside of the same feature I'd say.

You can follow these guidelines when one feature depends on another feature module. 1. You can move the common code to the core module if these functionalities are needed by a few others feature modules. Core module can be accessible by any feature module 2. You can create a featuer2-api module and expose the public interface in this module. Then use the functionalities from the feaurte1 module by the api module inyterface 3. Use the Adapter pattern inside your main app module to provide functionalities from feature2 to feature1 module. App module can access any feature module.

Not sure I like the structure. Looks to me a little bit like layered architecture at the same time the core module names are super generic yet when you look into them, for example the DAOs Module you see allot of business domain logic https://github.com/android/nowinandroid/blob/main/core-database/src/main/java/com/google/samples/apps/nowinandroid/core/database/DaosModule.kt

I think it is pretty obvious why Google is using Dagger Hilt over Koin

Doesn't make it right though

Dagger Hilt is a library created by google which they are recommending for dependency injection, so it is normal they use that in an architecture sample repo

Dagger 2 is absurd. Extra code generation compile time, shitty and confusing debug messages, and the list goes on.

dagger hilt is pretty similar to what is koin

List goes on

and? front part can be almost the same, dagger has some advantages, koin others

Where as Dagger 2 performs code generatio

compile time safety

Lol, but you have that natively in Kotlin

you haven't that with koin

Sure you do, you have type checking and what not

koin is a map under the hood

Dude, just Dagger2 generating its own code is a turn off for me

i don't care about that

But that takes loooads of time

you asked for a feature i give it you

fair point, Dagger builds its own dep tree graph and can do some logic

that is irrelevant, koin crashes at runtime, two different approaches, each one has different advantages

Out of curiosity, which one are you using?

both in different projects

Koin is a service locator, you can provide any object anywhere.