I have a very noob question. What is the easiest w...

# compose

[Halil Ozercan]

I have a very noob question. What is the easiest way to definitely recompose a View? In other words, completely remove from the tree and reinsert like it's brand new.

[Zach Klippenstein (he/him) [MOD]]

Why do you want to do that? Are you talking only about Android Views, or composables in general?

[Timo Drick]

There is a lifecycle to the views. (onActive/onDispose) normally you do not want that a view is completely removed because this reduce the performance. I worked the complete weekend on a Transition effect to optimize it so it does not recompose and also do not get disposed and reattached.
So when you just want to make sure that the view gets recomposed you can use following code:

Stack {
   val recompose = invalidate
   //your views here.
   // call recompose() when you want to trigger a recompose
 }

[Sean McQuillan [G]]

You might want to do this in an advanced case, but typically you don't.

You should think about composables as describing your UI and they'll automatically recompose based on their parameters changing, or reading from state/observables.

If you find yourself needing to reset state based on a parameter changing, it's likely you have added state too low in the tree and should hoist it to the caller where it can become a single source of truth.

Sometimes in loops the source position won't be "keyed" correctly, and you can manually give it a key using this API: https://developer.android.com/reference/kotlin/androidx/compose/package-summary#key(kotlin.Any,%20kotlin.Function0)

Key can also be used to reset the state of the subtree rooted at key.

That said – it's better to hoist state than it is to hold logic like this in composition when it can be avoided.

[Sean McQuillan [G]]

If your views aren't recomposing when you expect, check to make sure that all of the values needed are observable by compose. This means using state, LiveData.observeAsState, Flow.subscribeAState, etc.

[Halil Ozercan]

Thanks for the answers. I also thought to myself that this was something I've never needed when coding in React or Flutter. Declarative already suggests that the state should perfectly describe the view layer and the framework should handle state changes. Unfortunately, mixing AndroidView with some old callbacks like surface updates for TextureView threw me off a little bit.

A mediaplayer needs a surface, which becomes available asynchronously, to play the video. I struggled with implementing the source URL as a dependency to my Composable view so that when this URL changes, MediaPlayer should start playing the new video. It felt like the easiest way was to completely get rid off the surface(TextureVuew) and restart from scratch because the initial source always worked as expected.

I decided to tweak my design a bit and move MediaPlayer related functionality to a specific controller. That helped a lot to figure out how to map other video player related stuff like seekbar into compose.