compose-samples | Official Jetpack Compose samples | Android library

Did you enable it on the experimental panel in AS settings?

Also, I believe you're missing the preview dependency implementation "androidx.compose.ui:ui-tooling-preview:$compose_version"

Suppose your LiveData observer in a Fragment navigates to a second Fragment. The user rotates the screen so the first Fragment instance is destroyed. When they back out of the second Fragment, a new instance of the first Fragment is recreated, so its observer is triggered again. Without the event wrapper, it would suddenly and surprisingly navigate back to the second Fragment immediately.

Also, a LiveData might have multiple observers. Maybe two different Fragments are observing the same events LiveData, but you don't want to risk showing the user a message twice for the same event. For example, they could navigate to a second Fragment that is observing the same events LiveData as the first Fragment. An event fires and the second Fragment observer shows the user a dialog box or something. Then the user backs up to the first Fragment and that same event will fire the first Fragment's observer so the event gets handled twice.

If your project uses coroutines, a cleaner solution for this event observing problem is to use a SharedFlow with replay of 0 instead of using a LiveData with an event wrapper class. I suspect the reason they didn't use SharedFlow in the JetSurvey project is that they don't want to assume you're already familiar with Flows when that's not what the example is about.

An alternate solution called SingleLiveEvent appeared in an official Android example once, but was considered too hacky to add to the Jetpack libraries.

After some debugging, I come to the conclusion that the problem is somehow related to Lifecycle.Event.ON_STOP -> mapView.onStop() getMapLifecycleObserver

Removing it solves the problem.

I'm not happy with the solution and would be happy if someone is able to provide a better solution, or at least an answer explaining more details about the problem.

They only need to be defined outside of a class if you plan on using the @Preview annotation, which allows Android Studio to render the composable in a preview pane. They should also be defined outside of the class if you plan on reusing the composable elsewhere in your app or make them generally reusable for other apps.

You can however define it as a inner function if you want to but you can't use the @Preview annotation. Nevertheless, if you don't plan on using preview and you have no reason to reuse the composable outside of the class, you can define it as an inner function. I've done that on many composables.

I experienced the same thing. What is currently happening is:-

1.) App Startup is kinda slow
2.) App is glitchy upon start

The good news is:-

1.) The glitches only happen for the first few times you run the animation,
2.) The glitches seem to disappear from every element after you break one of the elements in.

The bad news is of course, you have to repeat the above steps upon EVERY startup. I have heard that running the production builds instead of the debug variants boosts up the performance significantly. As of now, there's nothing you can do about it. It will only break in as Compose develops. You can check the official Compose Samples too. They are as glitchy as your apps.

All you can really do at this point is wait.

EDITS BASED ON THE COMMENTS BELOW:-

1.) By The glitches seem to disappear from every element after you break one of the elements in., I mean that if you have a lot of animated content, like maybe two LazyColumns, and a few others, then upon swiping the Column back and forth a few times (breaking it in), the lag will be gone from the other columns, as well as the animated content. Element there meant element of the screen, so individual LazyColumns are each elements.

2.) To get the production build, all you need to do is click on the release tab in the left edge of the screen in studio, then select release from the dropdown list instead of debug. 'Production' was substituted by me for 'release', but it's one and the same thing you see.

It's a normal object and as such will be cleaned up once there are no references to it (so when both observing view and ViewModel seizes to exist)

I don't see your pattern described in the official docs:

https://developer.android.com/jetpack/compose/state

It is possible it worked under an older version of Compose and doesn't work under the current version??

According to the docs, recomposition can only occur when you use mutableStateOf in conjunction with a remember and set the value property to a new value to trigger the recomposition:

The uiState that you are using in your Composable val uiState: InterestsUiState = _uiState is not a State and hence doesn't respond to changes. It's just a normal InterestsUiState initialized with the current value of _uiState. To make it work, you can simply expose the getter for _uiState.

updateSection is a lambda here used to update the value of the mutable state. Consider this example: