https://kotlinlang.org logo
Join Slack
Powered by
why not split it into `:payments` `:payments-ui` ?
# android-architecture
u
why not split it into 
:payments
:payments-ui
?
p
That's what I'd recommend:
Copy code
:payments
:payments:android
:payments:core
:payments:data
:payments:view
u
the first line is just a folder? or does it have code
where do viewmodels and fragments/controllers/whatever live in this?
-- and to sum it up, you basically say feature modules dont exist?
p
The first is just a folder, but you can give it a 
build.gradle
that includes the other projects.
fragments -> android, controllers -> view
u
do you split each (android, core, data, view) module into api (interfaces) and impl? as to avoid circular dependencies?
say you want to share some part of ui, like "binder" of Foo ojbect to piece of ui, where would you stick it?
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)
p
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
For shared UIs
Copy code
:core:android // common Android which features may depend on
u
so technically it is
Copy code
: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

 ?
p
Ah, I see
u
coreandroid? I thought you mean those two live on the same level
p
I define APIs in 
:feature:core
and implementations either in 
:feature:data
for platform agnostic implementations (e.g. 
<http://java.net|java.net>
) and 
:android:data
for Android specific implementations (e.g. 
<http://andorid.net|andorid.net>
)
u
hm, and who do you then depend on, in some other module
p
Eh, 
:common
then.
Copy code
:common
:common:android
:common:core
:common:data
:common:view
u
whats common? junkdrawer?
p
Code you'd use across features.
u
so youd have PaymentsRepository and MessageRepository etc in there?
as opposed to :payments and :messages modules?
p
Also, in KMP project you might have
Copy code
:feature:ios
:feature:desktop
...
u
feature = placeholder?
p
Yeah
u
k -- but I still dont understand the common module, unless its a junkdrawer
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
p
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.
u
well, whats a feature, why is User not a feature?
p
🤷🏼‍♂️ that part is up to you.
u
my point was that everything is a feature, so nothing isa feature, and lets just call it modules, whatever
so the new app can actually pick and chose stuff it needs
in your project, do you have multiple apps or just one?
p
Typically just one.
u
whats the point of modularization when theres no code sharing
p
Isolation, build times, scalability and large teams.
☝️ 2
u
sure, but thats self imposed mostly, actually sharing code would lead to different design I believe
like that android specific module, I dont see how is it relevant -- unless KMP
p
In that case modularization is a tool to enforce a dependency rule.
u
true, thats why common module is a anti-pattern mostly
b
I would personally split models into it's own models module. Each feature module own it's viewa and data handling in isolation
u
^^ 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?
5 Views
Open in Slack
PreviousNext
Powered by