Is anyone building a "pure" Compose app? - single ...

# compose

[Colton Idle]

Is anyone building a "pure" Compose app?
• single activity
• no fragments
• no AndroidArchComponent ViewModel
If so, are you creating your own ViewModel (plain kotlin class, that does not extend AAC ViewModel)? I think most people agreed that AAC ViewModel was a not so great name when it came out.

What is your project calling the thing that keeps state + handles events?

[tad]

All of the above. Not using "ViewModel", but following the Compose framework example of "FooState"

[tad]

I was using an MVI-like abstraction on top of MutableStateFlow , and called that "FooStateMachine", but it ended up being unwieldy

[jw]

our app has been single activity, no fragments, and no architecture components for about 7 years. and we're adding in Compose-based things which includes Compose UI with basically zero change to architecture

[jw]

it's just another rendering frontend to the existing screen presenters completely opaque to the rest of the app

[Colton Idle]

So you call the thing that holds state + handles events "presenters"?

[jw]

we do. over time we may migrate them to be more friendly to Compose UI, but for now having them also be opaque to the view layer as nothing more than event sinks and model sources is really, really nice

[tad]

do you pass them down the composable tree, or do you inject them?

[Colton Idle]

Cool. Yeah. I think I saw a talk about square and their arch a while back at droidcon NY, but I'm more curious about the naming choice. Ditching AAC ViewModel, but keeping the name ViewModel just feels wrong IMO since even Yigit said that ViewModel wasn't all that reflective of what it is actually supposed to be.

[jw]

everything is passed explicitly currently. the root Compose UI for a screen tends to unpack the monolithic UI model into granular states which are then propagated. or if you're feeling lazy just propagate the whole thing. it's too new that we don't really have best practices, but the architecture let's us experiment with the glue code that sits between the layers and then have totally normal Compose UI everywhere beneath the root of a screen

[brandonmcansh]

@cb was also playing around with something as a state machine as well in tivi

[ursus]

what about orientation changes? wont the viewmodel-thing get recreated losing the instance & inflight coroutines?

[Shakil Karim]

I would add no Jetpack Navigation Compose as well. 🙂

[KamilH]

@ursus in pure Compose app you should disable all kinds of Activity recreation triggers:
https://kotlinlang.slack.com/archives/CJLTWPH7S/p1618758688086300?thread_ts=1618691113.058800&cid=CJLTWPH7S
there is a list of all of the possible options you should disable in your AndroidManifest in the same topic. It means that there will be no Activity recreation during orientation change, which means your component (ViewModel?) will not have to “survive” it

[ursus]

oh thats idiomatic now? great! simplifies a lot. I do however wonder about overloaded resource loading but ill see that when i get there, probably a when statement in code?

[KamilH]

You mean for example loading text in different languages? Maybe compose can handle it (load text according to current Locale) without any work on developer side 🤔

[ursus]

More like dimensions in phone vs tablet, number of columns in grid view in portrait vs landscape, colors in light vs dark mode etc

[KamilH]

Colors in light/dark mode is handled via isSystemInDarkTheme Composable function, which means every time it changes it will update the colors in your theme
If number of columns is calculated according to device’s width it should also be automatically updated whenever there was a change in this setting (I’m sure there is some Local to query a width, but I can’t remember the name)
Portrait vs Landscape - if you want to have different Composable to be used for each mode I think the best would be to check LocalConfiguration. I’m sure it will recompose whenever it changes

[ursus]

K thanks

[dimsuz]

our app has been single activity, no fragments, and no architecture components for about 7 years. and we're adding in Compose-based things which includes Compose UI with basically zero change to architecture

We have exactly the same experience. No ViewModel/AAC Navigation. Although we use Conductor (for now), but still using Compose is currently done by simply using different base class on a "View" (as in Model-View) layer.
Presenters have 0 change because they contain only view logic and view is dumb and is doing only rendering. One can simply swap "rendering backends" (=base class of the "view) without touching presenter.

[Rick Regan]

My app is pure Compose/single activity/no fragments/no ViewModel. My top-level Kotlin state/handler object is a collection of smaller state objects which more or less map to UI components. All these classes have a suffix of ‘State’. (Mine is a simple-ish app with one main screen, and this approach is working for me so far.)

[Colton Idle]

Lots of good discussion in this thread. My main question was about what to people call this "AAC ViewModel" thing in a world where no AAC VM is needed.

I'm going to stick with what Jake Wharton said though and just call it a Presenter.