If your just talking about of Viewmodel in term of a Mvvm architecture. Than sure , you can do what you want , even create a presenter If you , because it's just a architecture decision.

I suspect that hybrid UIs between compose and views will be with us for quite some time though, and using

ViewModel

directly might still make a lot of sense as a bridge between things

in any case we've been working with having activities and fragments register more components with their respective view trees that things can tie into, and the viewmodel provider may be another good one to make easily accessible from compose in general

(e.g. the LIfecycleOwner https://android-review.googlesource.com/c/platform/frameworks/support/+/1182955 )

this will make it easier for compose to perform some basic service discovery of this sort of thing

as for LiveData, there's a lot to be said for using something like

Flow

in its place, but it still definitely has a place for subscription management. By contrast,

@Model

is always a hot data source. We've played with the idea of adding something like LiveData's `onActive`/`onInactive` events to

@Model

classes as an optional element, but the existing reactive types are already quite good for most of those related use cases

and it's easy enough to use an effect in compose to perform the subscription management and bridge over to an

@Model

object or

state {}

for compose to read from

there's some debate on the team of whether or not that's enough, or what we should learn from

LiveData

and apply to

@Model

. On one hand we'd like to avoid oversubscribing too high in the tree by manually using effect calls, but on the other adding event callbacks risks

@Model

becoming a mirror of

LiveData

and a few of the drawbacks it has around its active callbacks vs. its instant-read

getValue()

my personal feeling on it at the moment is that it's better to say nothing on the topic and wait and see for now, and let observable subscription effect calls fill the gap rather than adding more features to

@Model

just yet. We can always add more capabilities later if the need is overwhelming.

the tension to resolve there is that there are two very different abstractions presented:

@Model

is a plain old kotlin object that just happens to be able to notify observers when its field-backed properties change.

Flow

is a reactive stream type with very well-defined subscription begin/end semantics.

LiveData

exists somewhere in the middle as a data holder that has callbacks for when it is and isn't being observed

but this causes some problems for

LiveData

since it has an instantaneous

getValue()

method - take room for example, if you get a

LiveData

from a room query and just call

getValue()

on it, the data will be stale or not present since the subscription active/inactive callbacks aren't invoked

so when you have a

LiveData

you have to know whether it's just a data holder or a reactive subscription-driven instance before you access it. The behavior of

getValue()

might be kind of useless to you

and

@Model

is basically only

getValue()

semantics in the form of property reads

so I'd like to not repeat this tension with

@Model

unless we have a good answer for this gotcha, and one way to not repeat it is to omit the subscription awareness

tl;dr:

Flow

and

LiveData

aren't in conflict with

@Model

- they serve some different use cases in important ways and you're likely to see them side by side in compose app code.