Hello everyone I’m working with an architecture de...

# android-architecture

[Daniel Okanin]

Hello everyone
I’m working with an architecture design system using MVI on Android. I fetch the Model data from the server and use a transformer in the ViewModel to create a UiModel specific to the view.
I’m wondering: when I need to display an icon based on the UiModel, should I include the drawable resource (@DrawableRes) directly in the UiModel class? Or, should I include a type field and map the drawable resource in the view layer itself?
Which approach is considered best practice? If I go with the first approach, the view stays very simple since it only needs to display the data. However, I’m unsure if this is the best solution for maintainability or flexibility

[Alexandru Caraus]

Wouldn't it be better for the testing side of things having a type field and mapper?

[Alexandru Caraus]

For an easy case A) might also work well.

[Daniel Okanin]

Right, both works as expected, just wondering what is better. Should the view need to hold the map logic?

[Maarten de Goede]

I personally prefer to use a type field and mapping it to an icon in the view layer for testability purposes, and because we don't have access to @DrawableRes on our `UiModel`s because we use Kotlin Multiplatform.

In my opinion it just depends on your use case tbh.

[dewildte]

From my experience, allowing resources of any kind into the ViewModel evolves into unnecessary complexity.
Everything needed to access and render resources is in the UI layer (Composables , Fragments, etc...).
Injecting that part of the UI's responsibilities into the ViewModel leaves it bloated, harder to test, etc...

The main reason I see people putting navigation logic and resource resolution logic into ViewModels is because they have misunderstood the Single Responsibility principle. Responsibility does not mean do only one thing. It means have only one reason to change. Navigation, lifecycle, and resource selection based on changes in the data in the ViewModel are the responsibility of the UI layer to manage. That layer is the easiest and simplest place to do it. So if we aim to keep things simple then we do not need to add more complexity in the ViewModel based on some misunderstood ideal.

[Alexandru Caraus]

^^ This is my preferred approach, for the exact same reasons.

[Alexandru Caraus]

And makes things straightforward and easy to manage.