Is there a best practice about naming the differen...

# android-architecture

[Lukasz Kalnik]

Is there a best practice about naming the different components on different layers of clean architecture?
We currently use:

data layer:
• ...Api suffix for the Retrofit interface definitions (e.g. MoviesApi)
• ...Repository suffix for the class that abstracts away the Api.
domain layer:
• ...UseCase for commonly used, well, use cases, they usually depend on Repository (although often we skip this layer altogether)
presentation layer:
• obviously ...ViewModel here.
I'm asking because I have a ViewModel which grew really large, so I would like to split it in multiple viewmodels. However they all share common view data to some degree, so have to depend on a single source of truth in the presentation layer. And I was wondering how to call such single source of truth in the presentation layer.

[Lukasz Kalnik]

I was thinking about renaming the data layer Repository to a DataProvider and then I could use Repository in the presentation layer as a source of truth for the viewmodels.

[gts13]

I have the following package structure and naming in most of my projects:
data/
• network/
◦ api.interface
◦ client.class (encapsulates the api)
• db/
◦ ...Dao
• localstorage/
◦ PreferencesManager (contains shared preferences)
• repositories/
◦ AccountRepositoryImpl (the AccountRepository interface resides in the domain layer)
◦ AnotherRepositoryImpl
domain/
• repositories/
◦ AccountRepository
• usecases/
◦ ...

[Lukasz Kalnik]

Do you also have sometimes large viewmodels in the presentation layer? If you split a viewmodel into smaller ones, where would you put the shared view state? Do you use some kind of presentation layer "repository"?

[Rafs]

I think the whole idea of having usecases is to prevent viewmodels from growing too large.

[Lukasz Kalnik]

Maybe let me get more clear and give you my concrete example: I have a screen to control an RGBW/temperature/dimmable light.
The screen has multiple controls which partially influence each other.
As an example, for the RGBW controls we have:
1. Hue seekbar (in the HSV model)
2. Saturation seekbar (for HSV model as well)
3. RGBW text fields
4. Hex value text field
I you change the position of the hue (which is the actual "color" of the light) seekbar, you have to update all the other controls. The same if you move the saturation seekbar, change any of the R, G, B or W text fields or the hex text field.

Another example, switching the light on/off and dimming. There is:
1. On/off switch
2. Dim seekbar (1-100%)
If you switch the switch "off", the seekbar should move to minimum position. If you switch it "on", the seekbar should move to 100%. If the light was off and you moved the dim seekbar, the switch should automatically go "on".

And on top of this, everytime the user lifts the finger of any of the controls, a backend call has to be made with all the current parameters (dim value, RGBW, temperature).

So I don't think use cases would help much here. There are just groups of interconnected UI controls which could go into separate viewmodels. But in the end all the ui state data has to be gathered for the backend call in one place.

[gts13]

what you described, it seems pure UI logic for me. I don't even know why would you need a repository, unless you sync the state of the controls with some backend, or store the state in a DB.

So in this case, yes you might need a kinda large viewmodel to coordinate all these states.
Unless you keep this logic in the fragment (or composable)

[Lukasz Kalnik]

I have a large viewmodel (1200 lines), that's why I want to split it.
But all UI controls get the state and send it to the backend (like I wrote above). All the state has to be sent in one call. That's why I'm thinking about having some "ViewModelRepository" which will just be the "state keeper" for all the partial viewmodels.

[Lukasz Kalnik]

And keeping the logic in the fragment/composable makes it not testable. That's not good architecture.