Thread
#android-architecture
    t

    takahirom

    2 months ago
    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
    K Merle

    K Merle

    2 months ago
    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.
    Ali

    Ali

    2 months ago
    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.
    s

    Sorin

    1 month ago
    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 logichttps://github.com/android/nowinandroid/blob/main/core-database/src/main/java/com/google/samples/apps/nowinandroid/core/database/DaosModule.kt
    Also, why use DI all over the place
    When you can just use simple factories and only at the higher level modules you can use a much simpler library like for example Koin
    Feels quite opinionaited to me
    A modular app/ framework should never ever rely on DI from the ground up
    DI should be used to glue the pieces together if, the structure grows in size, at the highest levels possible.
    Everything else can be solved with good ol factory patterns that are just a pattern and not a library on which you have to rely on
    Javier

    Javier

    1 month ago
    I think it is pretty obvious why Google is using Dagger Hilt over Koin
    s

    Sorin

    1 month ago
    Doesn't make it right though
    Also, why?
    Hilt is a wrapper over Dagger2 which is not that great tbh.
    Javier

    Javier

    1 month ago
    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
    s

    Sorin

    1 month ago
    Dagger 2 is absurd. Extra code generation compile time, shitty and confusing debug messages, and the list goes on.
    DI should be elegant, simple, concise
    Yes, I know, but them reccomending something is uite often shitty.
    Remmeber DataBinding and code in XML?
    Javier

    Javier

    1 month ago
    dagger hilt is pretty similar to what is koin
    s

    Sorin

    1 month ago
    List goes on
    Only that under the hood it isn't
    Completely different mechanisms
    Koin is pure Kotlin and makes use of all the beautfiul language features
    Hilt tries to hide away that Dagger 2 is
    Javier

    Javier

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

    Sorin

    1 month ago
    Where as Dagger 2 performs code generatio
    What advantages does dagger have, except over engineering?
    Javier

    Javier

    1 month ago
    compile time safety
    s

    Sorin

    1 month ago
    Lol, but you have that natively in Kotlin
    😃)))
    It's a language feature
    Javier

    Javier

    1 month ago
    you haven't that with koin
    looks like you are talking about things you don't know to be honest
    s

    Sorin

    1 month ago
    Sure you do, you have type checking and what not
    Javier

    Javier

    1 month ago
    koin is a map under the hood
    if a dependency is missing, it crashes in runtime
    s

    Sorin

    1 month ago
    Dude, just Dagger2 generating its own code is a turn off for me
    Javier

    Javier

    1 month ago
    i don't care about that
    s

    Sorin

    1 month ago
    But that takes loooads of time
    Javier

    Javier

    1 month ago
    you asked for a feature i give it you
    s

    Sorin

    1 month ago
    fair point, Dagger builds its own dep tree graph and can do some logic
    Doesn't mean Koin couldn't do some pre processing
    Javier

    Javier

    1 month ago
    that is irrelevant, koin crashes at runtime, two different approaches, each one has different advantages
    dagger can have slower builds but it has compile time safety and the app load is faster (but it can be irrelevant). Koin is simpler than dagger 2 (similar to Hilt tho), build faster but it does not have compile time safety and the app load is slower
    s

    Sorin

    1 month ago
    Out of curiosity, which one are you using?
    Javier

    Javier

    1 month ago
    both in different projects
    K Merle

    K Merle

    1 month ago
    Koin is a service locator, you can provide any object anywhere.
    I do like my objects being provided over the constructor, and OOP restrictions/rules.