Hey does compose provide functionality to attach detach layo

Question

Hey does compose provide functionality to attach detach layout nodes Basic example is routing we have a list with some heavy animation running on screen gt open detail of list item on top In that case it will be great to not draw the background screen anymore but keep scroll state of the list Currently two solutions I ve seen is to either draw screens on top of each other quite inefficient or just switch composables completely doesn t keep the state Maybe there are some interesting methods of making pieces of composition detached not drawing them while keeping the state

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

The background screen should save any state it cares about using the `UiSavedStateRegistry` ie using `savedInstanceState` then you can stop composing it and restore it later

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

This is the same idea as classic android views and `onSaveInstanceState` scroll views save their scroll position here then when they re restored they read it back

shikasd · Answer

Huh makes sense Probably need to check how we can support `UiSavedStateRegistry` in `compose router` and such thanks slightly smiling face

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

All the standard Android components facilitate this Activity Fragment and any backstack library that wants to play nice with android views needs to support this mechanism too e g <https github com square workflow kotlin blob 56dc0762151602006308d451baad97145bdfe91e workflow ui backstack android src main java com squareup workflow1 ui backstack BackStackContainer kt L76 L85>

shikasd · Answer

Yeah we did it for RIBs quite a long time ago but I just missed when it was introduced in compose slightly smiling face

shikasd · Answer

On the unrelated note it is quite funny how everyone produces their notion of backstack library which actually work in quite a similar way ツ

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

< grandstaish> did this exact thing in my compose backstack project after i messed up the initial implementation sweat smile if this helps you get started

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

Yea I think every UI developer eventually writes a backstack library joy

shikasd · Answer

Don t get me started on MV whatever libraries sweat smile Thanks for references

Timo Drick · Answer

I think it is a good sign when everyone can write their own backstack lib in a few lines of code Including myself

Timo Drick · Answer

It gets more complicated when we now want to integrate some more advanced transitions between screens Morphing one image into the new screen or <http s th|s th> like that

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

I have an idea for that using subcomposition i want to play with at some point where e g the image composable actually becomes the new screen so you don t need any shared element stuff

Timo Drick · Answer

sounds great Interesting idea

romainguy · Answer

Note that the rendering pipeline on Android should be able to eliminate the rendering of all the hidden elements automatically

romainguy · Answer

As long as the screen on top has a solid background for instance

Timo Drick · Answer

So instead of switching to a new component we could just change the size of one subcomponent to take the whole screen and the rendering system will do the rest

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

That wouldn t help with stuff like animations or anything else that s not strictly drawing operations that are tied to the composition of the background screen though right

romainguy · Answer

If you recompose stuff that s not visible you ll pay the cost of recomposition

romainguy · Answer

+ measure layout

romainguy · Answer

It s only drawing that gets optimized away

shikasd · Answer

gt I have an idea for that using subcomposition i want to play with at some point where e g the image composable actually becomes the new screen so you don t need any shared element stuff Had a similar idea in mind but it may be easier to get this done in compose terms slightly smiling face

shikasd · Answer

I think I was mostly referring to the cost of recomposing animation like if it is dynamic vector or relayouting if you for example have an autoscrolling column in the back

Timo Drick · Answer

I think the other approach would be to use layoutId modifier and use that I am not sure but i think some of the compose team is working on doing transitions with that

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

This <https android review googlesource com c platform frameworks support + 1351645>

Leland Richardson [G] · Answer

we literally just had a meeting about this slightly smiling face The referenced CL is super interesting but will not help you out here We are still debating ways to support enter exit transitions at a more fundamental level There s a lot of factors to consider so we haven t landed on one solution for this yet unfortunately confused

molikto · Answer

I ve been using a activity based backstack and it works quite well I feel activity backed backstack works better because an activity is backed by a Window Also I don t think destory an item in backstack when onPause is always desired ~Another thing I d like to know is before each View is an RenderNode but now seems an entire scene is an RenderNode how does it affect performance it seems it doesn t ~

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

gt now seems an entire scene is an RenderNode I don t think that s true I believe every layer in Compose is backed by a `RenderNode` and a layer is created any time you use something like the `drawLayer` modifier or the upcoming `withLayer` API

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

In general the nice thing about keeping the backstack in app space is that you have full control over it E g if you want to work with a router API you can use compose router library If you don t need all that functionality and just need a list with some animations you can use something like compose backstack If you want a fancy nested backstack solution you can use something else or build something from scratch Backstacks aren t really a hard or interesting problem at the core they re just a stack The tricky bits are transition animations and view state restoration but those concerns needn t be coupled to the mechanism your app uses to define history and navigation

molikto · Answer

for transition animation I feel activity based animation is smoother and I assumed it is because an Activity has it s own Window so it has it s own surface so activity transition animation is performed by the window mananger but not your own app

romainguy · Answer

Note that the performance aspects of RenderNode is mostly around drawing commands recording and culling

romainguy · Answer

More RenderNodes means more granular control over those two things

romainguy · Answer

Anyway not something for you to worry about

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

I don t think there s anything inherent about window transitions that is cheaper than regular layer transitions Layout animations are more expensive than pure layer transformations Software layers are usually slower than hardware layers I would be curious to see an example of where you ve noticed window animations are smoother than in app ones I haven t noticed that in any recent android versions except for the occasional bad app

romainguy · Answer

Window animations are definitely cheaper

romainguy · Answer

They are handled directly by the hardware composer we don t even go through the GPU

romainguy · Answer

But on recent devices it won t make a huge difference

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

TIL

romainguy · Answer

It s also why SurfaceViews are better than TextureView

romainguy · Answer

They go directly to the hardware composer when possible so you can skip an extra GPU composition step

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

So RenderNodes are still composited using the GPU

romainguy · Answer

Render nodes contain drawing commands for the GPU yes