https://kotlinlang.org logo
Join Slack
Powered by
I really appreciate the Now in Android app for giv...
# android-architecture
t
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.
Copy code
Layout structure
screen -> "article screen" -> "daily article tab"
Copy code
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
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.
a
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
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
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
j
I think it is pretty obvious why Google is using Dagger Hilt over Koin
s
Doesn't make it right though
Also, why?
Hilt is a wrapper over Dagger2 which is not that great tbh.
j
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
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?
j
dagger hilt is pretty similar to what is koin
s
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
j
and? front part can be almost the same, dagger has some advantages, koin others
s
Where as Dagger 2 performs code generatio
What advantages does dagger have, except over engineering?
j
compile time safety
s
Lol, but you have that natively in Kotlin
:))))
It's a language feature
j
you haven't that with koin
looks like you are talking about things you don't know to be honest
s
Sure you do, you have type checking and what not
j
koin is a map under the hood
if a dependency is missing, it crashes in runtime
s
Dude, just Dagger2 generating its own code is a turn off for me
j
i don't care about that
s
But that takes loooads of time
j
you asked for a feature i give it you
s
fair point, Dagger builds its own dep tree graph and can do some logic
Doesn't mean Koin couldn't do some pre processing
j
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
Out of curiosity, which one are you using?
j
both in different projects
k
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.
54 Views
Open in Slack
PreviousNext
Powered by