to allow for parallel compilation of core, but have features depends on whole core still?

# android-architecture

[ursus]

to allow for parallel compilation of core, but have features depends on whole core still?

[ghedeon]

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.

[ursus]

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?

[ursus]

what about use cases or domain stuff? how you modularize that?

[ghedeon]

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

[ursus]

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

[ghedeon]

any logic abstraction is good, as long as you're not juggling 5 Repositories via merge/denounce/combineLatest directly in Viewmodel 🙂

[ursus]

Anyways, youd have the GetFooUse case in a module where the fragment/viewmodel lives?

[ghedeon]

yes, usually my feature module is not worth splitting further, so I just go with data, domain, ui packages inside.

[ursus]

interesting you have data package in your :foo? what is there? what if you have models which are shared between modules like User?

[ghedeon]

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.