Thread
#android-architecture
    Lukasz Kalnik

    Lukasz Kalnik

    1 month ago
    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.
    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.
    g

    gts13

    4 weeks ago
    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

    Lukasz Kalnik

    4 weeks ago
    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

    Rafs

    4 weeks ago
    I think the whole idea of having usecases is to prevent viewmodels from growing too large.
    Lukasz Kalnik

    Lukasz Kalnik

    4 weeks ago
    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.
    g

    gts13

    4 weeks ago
    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

    Lukasz Kalnik

    4 weeks ago
    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.
    And keeping the logic in the fragment/composable makes it not testable. That's not good architecture.