👋 I have a question about a potential onion architecture using jetpack compose. • A single activity with a composable view containing the whole application • Each screen is a composable fnuction • Navigation is done by a `androidx-architecture:navigation-compose`implementation In a nutshell: In our current architecture, we are using fragment to handle each screen, and each fragment have a viewmodel to retain it’s state and call the core layer made of use cases and repositories interfaces (implemented in the data layer). Fragment’s view model are scope by their fragment lifecycle so use cases are disposed when needed (using

viewModelScope

) Is a composable screen going to expose a scope so that we’ll be able to provide a ViewModel associated with such a scope ?

the short answer is “yes”, but we haven’t made a decision on exactly what this will look like. In the meantime, it should be relatively easy for you to create a LifecycleOwner ambient and pass it through from your fragment and use that in your composable functions if you need it.

If I'm on screen B and I'm loading content and I press back to go back to screen A, I need the loading of content to be stopped. I have two choices for this: 1. Like our current architecture, my screen has a scoped view model (then leveraging ktx this view model exposes a CoroutineScope so jobs are going to be cancelled on clear). UI input are sent to the single exposed method of the ViewModel and treated there. 2. I don't have a view model but I directly have a CoroutineScope so I can call my use case and when I leave my screen my jobs are cancelled. UI input are directly treated in my screen and I need to inject the uses cases. However, solution 1 would be preferable since use cases won't be expose directly to the screens. Hum... But with solution 2, I could create a parent comparable fonction which exposes a

(UiAction)-> Unit

callback to its children and would treat those actions and call the use cases 🤔. I'll have to try that out... Thank you for your answer 👍

👍 note that in the future you will be able to launch coroutines from composable functions and they will have a scope that matches the lifecycle of the composable, so they would be automatically cancelled in this case

I was focused on ViewModel because it's the current way to go but if composable functions have a scope, I could just rely on this scope and organize them the right way to keep as much as possible a good UI layer isolation. The two others points being: - Configuration change: from my understanding composable functions have mechanisms to survive it right ? - Process death: I saw some responses from you guys talking about plans to use SaveInstanceState ?

no worries! some of this stuff can be hard to discover

yes, we do work on SavedInstanceState support for compose

And regarding configuration change, that's also handled by Compose with its state mechanism, AFAIK. 👍

Does it? [In this screen](https://github.com/monzee/over-engineered/blob/2939f24da26997b861e3f9fdeb273597febe0097/app/src/main/java/ph/codeia/overengineered/LoginFragment.kt#L176) I have a component

AnotherCounter

that resets its value after rotation. Am I doing something wrong here?

it is not handled yet. but I work on it!

Ah, I see. That would be nice so I could avoid `ViewModel`s entirely. `@Composable`s in classes seem far easier to inject stuff into.

Ahh nice! Thanks for the correction. simple smile