https://kotlinlang.org logo
#android-architecture
Title
# android-architecture
t

takahirom

07/10/2022, 10:36 AM
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

K Merle

07/15/2022, 8:02 PM
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

Ali

07/16/2022, 1:47 PM
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

07/29/2022, 4:17 PM
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

Javier

07/29/2022, 4:20 PM
I think it is pretty obvious why Google is using Dagger Hilt over Koin
s

Sorin

07/29/2022, 4:21 PM
Doesn't make it right though
Also, why?
Hilt is a wrapper over Dagger2 which is not that great tbh.
j

Javier

07/29/2022, 4:23 PM
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

07/29/2022, 4:23 PM
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

Javier

07/29/2022, 4:24 PM
dagger hilt is pretty similar to what is koin
s

Sorin

07/29/2022, 4:24 PM
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

Javier

07/29/2022, 4:25 PM
and? front part can be almost the same, dagger has some advantages, koin others
s

Sorin

07/29/2022, 4:25 PM
Where as Dagger 2 performs code generatio
What advantages does dagger have, except over engineering?
j

Javier

07/29/2022, 4:25 PM
compile time safety
s

Sorin

07/29/2022, 4:26 PM
Lol, but you have that natively in Kotlin
:))))
It's a language feature
j

Javier

07/29/2022, 4:26 PM
you haven't that with koin
looks like you are talking about things you don't know to be honest
s

Sorin

07/29/2022, 4:27 PM
Sure you do, you have type checking and what not
j

Javier

07/29/2022, 4:27 PM
koin is a map under the hood
if a dependency is missing, it crashes in runtime
s

Sorin

07/29/2022, 4:27 PM
Dude, just Dagger2 generating its own code is a turn off for me
j

Javier

07/29/2022, 4:28 PM
i don't care about that
s

Sorin

07/29/2022, 4:28 PM
But that takes loooads of time
j

Javier

07/29/2022, 4:28 PM
you asked for a feature i give it you
s

Sorin

07/29/2022, 4:28 PM
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

Javier

07/29/2022, 4:29 PM
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

07/29/2022, 4:42 PM
Out of curiosity, which one are you using?
j

Javier

07/29/2022, 5:06 PM
both in different projects
k

K Merle

07/29/2022, 5:10 PM
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.
31 Views