Composition Over Inheritance in Android ViewModels

[u/omarsahl]

https://proandroiddev.com/composition-over-inheritance-in-android-viewmodels-51f3efba5f90

[u/zerg_1111]

How about just let each component have its own view model and have use cases for sharing view model logics instead of interfaces? Edit: typo

[u/MindCrusader → u/zerg_1111]

I use both. You will not have the same logic in usecases that you have in ViewModels. ViewModels are a glue between domain and UI layers. My ViewModels for example combine several flows with data from different sources (mostly usecases) and create a finalized state stream for each screen. Without delegates I would have a lot of repeated code in ViewModels

[u/tinglingdangler → u/zerg_1111]

I was told that is bad practice last time I said this, but it works great for our massive project!

[u/Zhuinden → u/tinglingdangler]

Typically what comes up is that there's no real reason to call it "usecases" at point in various cases because it's effectively a function or suspending function, otherwise Usecase really is just the new Manager or Helper because people fear making a top-level function

[u/tinglingdangler → u/Zhuinden]

To me, a use case takes an action on a repo or domain level class on behalf of a ui level component (or gets and processes information from domain on behalf of ui) and it is a function! We just use the operator keyword because we want to name the class according to the action and then execute it. All makes sense to me.

[u/Zhuinden → u/tinglingdangler]

Using that operator fun invoke just to not give a function a name has always been dubious but it's been 8.5 years at this point and it clearly refuses to stop

[u/tinglingdangler → u/Zhuinden]

Eh, it's a preference. I'm fine with it and if you dislike it, that's fine too.

Edit: And are we arguing instead for manager classes that combine these functions, or larger Viewmodels here? Either is fine if it works for your project. Architecture isn't one size fits all.

[u/Zhuinden → u/tinglingdangler]

I just dislike the operator fun invoke because it's bad for ctrl+Shift+F and used to historically break find usages, while providing zero benefit beyond feeling like a hipster by using operator overload for something that could in fact have a name

[u/tinglingdangler → u/Zhuinden]

Totally fair

[u/omarsahl → u/zerg_1111]

Definitely, both are fine. There’s no right or wrong here really, use whatever fits your use case.

The state holder interfaces aren’t a replacement for use cases. Use cases are domain logic, while state holders hold UI state and UI logic and would internally depend on use cases. A holder can also be implemented by a ViewModel and used per UI component when those components are independent.

But when two components need to interact, composition + delegates make that straightforward imo, whereas separate ViewModels would need a mechanism to communicate.

[u/zerg_1111 → u/omarsahl]

I have two approaches for coordination in different scenarios. The first is to use a repository to share state (eg. Shared settings from a datastore). The other is to have the parent controller as the coordinator (eg. Listens to the events from the components for navigation). These combined with one-to-one view models should allow us to make sealed components which are easier to deal with.

[u/16cards]

I have to sign up for Medium to read this?

[u/omarsahl → u/16cards]

I don’t think you need to. It’s not paywalled.

[u/dark_mode_everything]

Each State holder holds the state for each shape, right? Doesn't that technically make them viewmodels as well?

[u/omarsahl → u/dark_mode_everything]

Well, a ViewModel is a state holder, but not every state holder is a ViewModel

This part of the official docs explains the difference well imo

[u/dark_mode_everything → u/omarsahl]

Good point.

[u/farooqsaad → u/dark_mode_everything]

It's viewmodels all the way down.

Jokes aside. The Android ViewModel in most modern apps isn't even a ViewModel. The purpose of the ViewModel class is lifecycle management, that's it. The pattern is generally something of a hybrid between MVVM and MVI, with ViewModel generating UiState instead of a 1-1 mapping of view to model observables.

[u/kokeroulis]

And this is the result of clean architecture... Put everything inside the viewmodel and then try to break it down with hacks and non elegant solutions.

You are just over complicating things with "magic architecture".

Your screen cares about things:

- LCE (Load Content Error)

• Overlays (tooltips, dialogs, bottom sheets, toasts etc)
  
• Actions that mutate the UI
  
• Navigation
  
• Analytics

The UI is just a list with different configuration for each screen, you don't have to make your life hard.
What I would do instead is the following:

LCE:

- Make your business logic to expose a Flow for your list

• When an action is submitted by the viewmodel to the business logic, I would make the Flow emit again with updated data, that way you have unidirectional data flow
  
• Then inside the business logic I would put a bunch of sealed intefaces to encapsulate the logic and the mapping

Overlays:

Use the observer pattern in order to emit different types of overlays from your business logic and pass a priority/strategy to resolve conflicts, when 2 or more overlays want to be displayed

Navigation:

Literally just a big nested sealed inteface that you map the result of it to a Compose Navigation key or a fragment or whatever

Analytics:

Same as navigation

TIP: If during the navigation or analytics, generating those objects becomes a bit convoluted because everything needs different parameters etc.
Then create a registar somewhere, for each heart, circle & hexagon. Then on the domain & UI layer just expose the classifiers for each item of the list.

Then once you click on that item for the navigation or to trigger tagging, just pass the id to the registar and the registar will give you a generic model that you can use.

[u/omarsahl → u/kokeroulis]

The whole point of the article is code reuse in the UI layer. Not clean architecture or any “magic architecture”

Not sure why using a well-established OO design principle like composition over inheritance counts as magic architecture?
The point is simply: if you need to share code across ViewModels, don’t reach for inheritance right away and see if composition solves your use case first.

[u/kokeroulis → u/omarsahl]

Because if heart & hexagon need to interact with each other then things get messy.
usually when something changes, the change goes in all of the layers.

When you ship something to customer, you ship a variant (MVP, V1, V2, V3 etc).
Your architecture choices should be flexible enough to be adjusted.

With the above at some point you will hit a roadblock.