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

ursus

12/23/2019, 5:23 AM
to allow for parallel compilation of core, but have features depends on whole core still?
g

ghedeon

12/23/2019, 9:48 AM
LGTM. Not sure what's left in data if you extract repos and net but yes,
core:ui
and others is pretty standart. Just be aware that modules not necessary mean boost of build speed. Sometimes, it can actually slow you down, so I'd collect some build scans first, to have something to compare with after.
u

ursus

12/23/2019, 3:03 PM
why would it not? everybody depends on core, therefore its single core compile, bottle neck, if I split it in 4 ill fill all cores, no?
what about use cases or domain stuff? how you modularize that?
g

ghedeon

12/23/2019, 5:27 PM
probably core:domain, according to your structure. But most of it is going to be in the features, where each feature has it's own domain, etc
u

ursus

12/23/2019, 6:05 PM
do you use UseCases? I honestly find them useless. Usually I'd better like FooManager which is scoped to user session etc. Disjoint usecases as GetFooUseCase, PostFooUseCase are useless imo, thats just composition of viewmodel
g

ghedeon

12/23/2019, 9:28 PM
any logic abstraction is good, as long as you're not juggling 5 Repositories via merge/denounce/combineLatest directly in Viewmodel 🙂
u

ursus

12/24/2019, 12:44 AM
Anyways, youd have the GetFooUse case in a module where the fragment/viewmodel lives?
g

ghedeon

12/24/2019, 8:32 AM
yes, usually my feature module is not worth splitting further, so I just go with data, domain, ui packages inside.
u

ursus

12/24/2019, 9:17 AM
interesting you have data package in your :foo? what is there? what if you have models which are shared between modules like User?
g

ghedeon

12/24/2019, 10:25 AM
if it's shared then logically it goes to core. But if I have a bunch of api calls related to
chat
then I might as well call it
ChatApi
and put it into
chat:data
package.
9 Views