why not split it into ` payments` ` payments ui`

Question

pardom · Answer

That s what I d recommend ``` payments payments android payments core payments data payments view```

ursus · Answer

the first line is just a folder or does it have code

ursus · Answer

where do viewmodels and fragments controllers whatever live in this

ursus · Answer

and to sum it up you basically say feature modules dont exist

pardom · Answer

The first is just a folder but you can give it a `build gradle` that includes the other projects

pardom · Answer

fragments gt android controllers gt view

ursus · Answer

do you split each android core data view module into api interfaces and impl as to avoid circular dependencies

ursus · Answer

say you want to share some part of ui like binder of Foo ojbect to piece of ui where would you stick it

ursus · Answer

my classic example is I have playments screen there is a piece of ui bound to ppayment object and this piece of ui is also on a dashboard of the app so two places

pardom · Answer

gt do you split each android core data view module into api interfaces and impl as to avoid circular dependencies Yes to isolate and enforce dependency rules

pardom · Answer

For shared UIs ``` core android common Android which features may depend on```

ursus · Answer

so technically it is ``` payments payments android api payments android impl payments core api payments core impl payments data api payments data impl payments view api payments view impl ```

pardom · Answer

Ah I see

ursus · Answer

core android I thought you mean those two live on the same level

pardom · Answer

I define APIs in ` feature core` and implementations either in ` feature data` for platform agnostic implementations e g `` and ` android data` for Android specific implementations e g ``

ursus · Answer

hm and who do you then depend on in some other module

pardom · Answer

Eh ` common` then ``` common common android common core common data common view```

ursus · Answer

whats common junkdrawer

pardom · Answer

Code you d use across features

ursus · Answer

so youd have PaymentsRepository and MessageRepository etc in there

ursus · Answer

as opposed to payments and messages modules

pardom · Answer

Also in KMP project you might have ``` feature ios feature desktop ```

ursus · Answer

feature = placeholder

pardom · Answer

Yeah

ursus · Answer

k but I still dont understand the common module unless its a junkdrawer

ursus · Answer

if you were to have payments code in common then if you were to create a 3rd app and that would not need payments but would need something else from common it would get payments as well

pardom · Answer

It s for whatever you need across feature modules For example common types in ` common core` e g `User` `Either` etc common Views in ` common android` etc

ursus · Answer

well whats a feature why is User not a feature

pardom · Answer

man shrugging skin tone 3 that part is up to you

ursus · Answer

my point was that everything is a feature so nothing isa feature and lets just call it modules whatever

ursus · Answer

so the new app can actually pick and chose stuff it needs

ursus · Answer

in your project do you have multiple apps or just one

pardom · Answer

Typically just one

ursus · Answer

whats the point of modularization when theres no code sharing

pardom · Answer

Isolation build times scalability and large teams

ursus · Answer

sure but thats self imposed mostly actually sharing code would lead to different design I believe

ursus · Answer

like that android specific module I dont see how is it relevant unless KMP

pardom · Answer

In that case modularization is a tool to enforce a dependency rule

ursus · Answer

true thats why common module is a anti pattern mostly

brandonmcansh · Answer

I would personally split models into it s own models module Each feature module own it s viewa and data handling in isolation

ursus · Answer

^^ so if you need to the data handling in the another ui other than the one youre in would you only then split it into data ui