recompose | converting Android layouts in XML to Kotlin code | Android library

Change

You are not reading var selectedIndex by remember { mutableStateOf(-1) } anywhere in your code what triggers a recomposition in any Composable reading a mutableState value change. You can check here for smart recomposition.

Compose can only understand that it should recompose if you set the value of a State object. In your example myvalue.value++ is really just short for myvalue.value = myvalue.value.inc(), so what triggers the recomposition is calling the state.value setter.
If you just mutate a property of the object held by a state, you are not calling the setter and no recomposition happens.

So you have 2 options to solve this:

1. Make TestClass immutable and update the State with a new object

I found the issue when it would fail at runtime as well. Turns out I didn't have the "compose = true" in the build.gradle file of the module defining AppTheme etc. In other words, each build.gradle file requires these settings to be specified individually.

How to make code sample one to recompose on state change?

You should use a SideEffect to mutate state during first composition in order for these changes to take "effect" :

This behaviour is totally expected.

Compose is trying to reduce number of recompositions as much as possible. When you comment out MyText, the only view that depends on counter is Button content, so this is the only view that needs to be recomposed.

By the same logic you shouldn't see VALUE1 logs more than once, but the difference here is that Column is inline function, so if it content needs to be recomposed - it gets recomposed with the containing view.

Using this knowledge, you can easily prevent a view from being recomposed: you need to move part, which doesn't depends on the state, into a separate composable. The fact that it uses scrollState won't make it recompose, only reading state value will trigger recomposition.

Well I had the same problem using emulator or phone both work well with small simplistic composables. And when I create more complex Composable and try animating the navigation, using the accompanist animation library it gets very laggy. But then I tried building the release APK file, since it is usually optimized and way faster, and that will significantly speed up your app. Here is link on how you can generate signed APK then install it on your phone or emulator and see if that fixes your problem!

You could also check if you accidentally disabled the hardware acceleration from the manifest. Make sure you set android:hardwareAccelerated="true" in you activity tag.

In case that does not help either, then you have to implement your own animation and use Shared ViewModel, for communication and triggering the transition from one Composable to another. The idea is that you can use modifier offset property to show/hide the Composable by placing it outside the screen.

First set your ViewModel, and add mutable state variable, that will trigger the transition from Home to Settings and vice versa.

This is not the best practice, since there is no way to directly pass data from one composable to another as you would normally do with the normal navigation. But you can still share data using the Shared ViewModel. Using this method it will not recompose your Composable, and thus be really fast. So far I have no problem with any out of memory exceptions even on some very old/slow devices with 2GB RAM.

I think the performance impact is minimal from choosing one or another. I think that the Compose developers just didn't think data classes as parameter where the best route, and I agree.

I don't see how this:

Recomposition happens when either the parameter values change or a mutable state variable within the composable function is updated.

A stateless function, sometimes referred to as an "immutable" function, is one where no data is stored in the function. This means that if you call the function repeatedly, it would be the same as if you had called it for the first time. The function retains no memory of any variables each time it is called.

Hoisting the state of a composable means that the state variables are kept outside of the composable and the values of those state variables are passed into the composable as normal parameters. This allows you to reuse the composable. This is especially important if you are creating a library of composables that you want to reuse from one project to another. Users of the library can be assured that there are no state dependencies that the composable requires. If you want a truely stateless composable, you would avoid doing things like passing in viewmodels. A viewmodel is very much dependent on the app in which it resides and will have code in it that is very specific to the app. A stateless composable has no dependencies on the app and therefore can be reused elsewhere.

That doesn't mean that you can't use viewmodels in your composables. Initially Google was against this when Compose first came out but realized that it was very awkward for developers. If a developer had no reason to make a reusable composable outside of the screen that it appears on, hoisting the state for every composable becomes a pain resulting in unnecessary boilerplate code. So the general rule is that if your composable is not going to be reused elsewhere and you need access to viewmodel data, you can either pass in the viewmodel as a parameter or access it within the composable through other means.

Aside from viewmodels, you may still want to make a composable stateful even when it needs to be reused. A good example of this is if you are using a TextField. As you are typing in text, you want the text to appear. Without using a state variable to retain the typed characters, you won't see the TextField update. For this reason, using a local state variable to store the entered characters is acceptable. While this doesn't make the composable stateless, it is still something you need to implement. However, even in this example, you can still make it stateless by passing the typed characters back up to the hoisted function and storing it in a viewmodel state variable that in turn triggers the hoisted function to recompose the composable and pass in the text that the TextField needs. But this is rather convoluted and a big round trip just to get characters shown in the TextField and therefore isn't recommended. You might want to do it though if you have a very complex TextField composable and you need to process the characters in your viewmodel as they are being typed - such as might be the case for doing a suggestion lookup for a url.

So even if your composable is stateless but your viewmodel has a mutable state variable that the hoisted function is observing, if the mutable state of that variable changes, the hoisted function will recompose. But whether the composable that the hoisted composable is calling gets recomposed depends on whether the parameter values to that composable change. If they change, a recomposition will occur.