I set up my code like this, with a viewModel which is platform-independent:

class MainActivity : AppCompatActivity() {

    val viewModel = MyViewModel()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            MyTextComponent(viewModel.state)
        }
    }
}

@Composable
@ExperimentalCoroutinesApi
fun MyTextComponent(stateFlow: StateFlow<DataModel>) {
    val state by stateFlow.collectAsState()
    Text(text = state.mytext)
}

But on configuration changes (e.g. device rotation), the Activity gets destroyed, and so the viewModel. Is it better to tie the viewModel to the App class, or which other strategy do you suggest?

by definition, ViewModel should survive activity orientation changes. However, to achieve that you should use proper

ViewModelProvider

to instantiate your ViewModel. Easiest way to do that would be depending on KTX and using

viewModels

delegate. You can look at the example in here https://developer.android.com/kotlin/ktx#fragment

Well, I am actually using my own ViewModel, not the Android viewModel

sorry for jumping the gun then 🙂 Yes, extending on Android's ViewModel API would be better.

I was expecting that on Compose, we just need to work with data, and not with Android’s ViewModel

Android's ViewModel is definitely not a requirement. You can create your own state objects and use

remember

and

rememberSavedInstanceState

to initialize them inside composable components.

Oh I see, I was not aware of those those 2 functions. I must research. Do you have any tutorial/article I can read about them?

class JetnewsApplication : Application() {

    lateinit var container: AppContainer

    override fun onCreate() {
        super.onCreate()
        container = AppContainerImpl(this)
    }
}


class MainActivity : AppCompatActivity() {

    val navigationViewModel by viewModels<NavigationViewModel>()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val appContainer = (application as JetnewsApplication).container
        setContent {
            JetnewsApp(appContainer, navigationViewModel)
        }
    }
}

I just realized in Google’s JetNews application, they use this approach to retain objects

JetNews uses Android ViewModels (that's the

by viewModels()

call). Creating a Singleton is a terrible alternative since that means it never gets cleared out, unlike Android ViewModels (which do get cleared when the activity is finished)

Hi @Ian Lake thanks! I had a look at

remember

, but I don’t understand how to apply in the case of

StateFlow

. This is my code:

Yeah, really looks like you should be using Android ViewModels

So, you said

remember

is using the Android ViewModel under the hood, right?

MVVM is usually built in top of a repository layer, yes.

@Ian Lake sorry, to ask again, but I still haven’t understood when using StateFlow to pass the data (which is not an Android ViewModel), where I should define the object and how I can make it persist. So, you said

remember

is the way, but as far as I understand “remember” should be applied inside components, while my StateFlow object is defined inside the Activity.

You should use an Android ViewModel if you're building objects outside of a

@Composable

that needs to be retained across config changes

OK, I see, so I guess I need to wrap the StateFlow inside the Android ViewModel

Correct

Finally! I made it working:

class AppViewModel : ViewModel() {
    val coreModel = CoreViewModel()
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val appViewModel: AppViewModel by viewModels()
        setContent {
            MyTextComponent(appViewModel.coreModel)
        }
    }
}

@Composable
@ExperimentalCoroutinesApi
fun MyTextComponent(coreModel: CoreViewModel) {
    val state by coreModel.stateFlow.collectAsState()
    Text(text = state.mytext)
}

Great, I'm glad you got it working!

@Daniele B I've came to the same conslusions, using Android's ViewModel, but comming from multiplatform corner, where I wanted to get also viewmodel sharable with other platforms. And thanks actual/expect its perfectly doable without wrapper- Obsesed with "don't repetead yourself" I have also learned that its good to go with platform instead of fighting it.

yes, actually it’s just a thin wrapper. So it’s not a big deal, and the Android’s ViewModel is also the suitable place where to trigger app events, such as entering backround/foreground

@Daniele B You can also inherit from Android ViewModel for your actual class, here’s the common one:

expect open class ViewModel() {

    protected val viewModelScope: CoroutineScope

    open fun onCleared()
}

And here’s the Android one:

actual open class ViewModel actual constructor() : ViewModel() {

    protected actual val viewModelScope: CoroutineScope = CoroutineScope(Dispatchers.Main)

    public actual override fun onCleared() {
        super.onCleared()

        viewModelScope.cancel()
    }
}

Hope that helps!

@galex thanks! In my case I have a CoreViewModel class with a StateFlow holding the state. I am not sure how to integrate it with the expect/actual constructs.

Haven’t started looking at Flow and but you can do that in the expect class yes, it’s like an interface