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

ursus

01/25/2019, 3:35 AM
I feel like it warrants its own package, but its not a ui facing feature like news or weather, where should I put it? account/ package in root? in data/? if root, then data/ already has MessageRepository etc, wouldnt that be a mismatch?
g

ghedeon

01/25/2019, 8:13 AM
sounds like another feature to me, so probably feature/account/{data, domain, ui}. But it's not clear what architecture you're following, I'd expect "net" inside data package. Also, depends on the size of the app, eventually you want to start using modules.
u

ursus

01/25/2019, 2:27 PM
well Im following package by feature, but not clean per say but I dont think it matter, within your feature you can split it up however you want. What im strugling where to put shared stuff like net, utils, and some repositories
should it be just root or some explicit /core ?
g

ghedeon

01/25/2019, 2:57 PM
maybe solve problems as they come. If the poject is big enough and you follow clean arch terminology, you'd probably have
app
module that connects
core
+
feature1
+
feature2
, etc. The
core
itself most probably could be splitted in
coredata
,
coreui
modules... It really depends on the scale. For a trivial app your main module is `app`+`core` by default, so you can have:
Copy code
app
     - data // shared
     - domain // shared
     - ui //shared
     - features
            - feature1
                     {data, domain, ui}
            - feature 2
Later, shared stuff can go into
core
module and each feature to its own module.
u

ursus

01/25/2019, 3:34 PM
yea thats more or less what I have, but where would you put a "intrastructure" thing like AccountManager? its has like 5 classes associated with it, id feel bad spliting it into coredata and coredomain
by core now should I understand (from the above)
Copy code
- data // shared
- domain // shared
- ui //shared
?
g

ghedeon

01/25/2019, 4:50 PM
yes. Again, it will be easier for you if you follow a specific architecture pattern. Because then you don't have to think too much "where I put this or that". Roles are defined for you. I don't know what's
AccountManager
. But if it's kind of repository role from Clean Architecture, than its interface goes to domain and implementation goes to data package, because of the inversion of control.
Maybe try to read a few articles on this matter, so you have a clear structure in mind. You'll find Clean Architecture sample apps in Google samples repo.
u

ursus

01/25/2019, 6:19 PM
I dont really like the formal clean architecture, i.e. having everything inherit from UseCase
but as a composition its okay, but the meat is still in manager, they just call it repositories, afaik repos used to be just gateway to data
in simple apps okay, but think sync.. should it be a Syncer which takes repo or a use SyncUseCase? idk
3 Views