I was looking at Jetpack Compose Playground in the crossfade animation. Would somebody educate me if I'm wrong but, couldn't this concept be used in a fashion similar to Androids Fragment Containers? Or even a makeshift navigation? Hear me out you make your parent containers "fragments/fragment activities" and the main window contains a container composable "Activity". In your "Activity" you have a enumerated variable that is remembered containing your "fragments" or containers. Using this one would be able to trigger changing the state by changing the composable container in the variable, thus triggering a state change which refreshes the window. Could I be onto something here? Link is here Playground

Yes, we can do that. I've done of my compose desktop projects in an android-ish way 😄 https://github.com/theapache64/stackzy/blob/master/src/main/kotlin/com/theapache64/stackzy/ui/feature/MainActivity.kt Here I use one parent activity and the rest of the screen are considered as

Fragment

. The navigation between these screens are done by @Arkadii Ivanov’s Decomposer library.

👍 I'll have to check it out. Heck it might even make my project easier. Essentially communicating with a credit card reader that is ran on a highly customized locked down version of android, done from windows 10 anywhere on the network. I taught myself coding on android so not only am I more comfortable with it everything should have good fungshway. Why is it that the people that create these kinds things always focus on the "advanced" stuff or the "oh that'd be cool" but don't think about the easy basic things?

Crossfade

can certainly be used for basic navigation transition animations, which is I think what you’re asking. Just be aware that it doesn’t actually do everything you’d expect from a navigation solution - consider a main/detail pair of screens. The main screen has a list of items, tapping on an item navigates to a detail screen. If you use

Crossfade

for the transition, then if you’ve scrolled the list, when you navigate back, I believe the scroll position will be lost. Probably the Decomposer library handles this case correctly, as would fragments, Jetpack Navigation, compose-router, and other real navigation libraries.

@Zach Klippenstein (he/him) [MOD] First off I am not complaining about this project, it's brilliant. I hope I didn't offend you. I ment when working on something like a software project it's easy to overlook the simplest of things that could completely change the whole thing. Since you asked, I don't know how you would accomplish it but maybe find a way to incorporate beginners. Like give guidance of things they can start out with. It would be pretty cool to see the people involved with this project take someone under their wing and just be there. I say this because for example this is the second time I have attempted to get involved with something like this and to be honest it is intimidating. 😄 it's stupid I know but my dream is to be a software developer and this is as close as I can get. After taking care of the family and working all day, spending the night hours reading coding learning and having fun. To me it makes only getting a few hours of sleep worth it. I know I'm not the only one that feels that way. So I was trying to say the concept of the code in that specific example not the animation. It reminded me of when android started to use a when statement in the android navigation drawer. Your main activity, similar to desktops window composable, housed the container that the fragment activities, similar to desktops layout composables, could occupy. It could be done in compose desktop in a similar fashion is all I'm pointing out. Composables, from what I understand have access to other Composables. So you make the main container composable use a state change triggered by an event or button Exetera to change the fragment container composable that is displayed in the container. It should work even for a master/detail example. Since technically the master would be like a fragment activity the state of that composable is technically held and remembered in the main controller container composable. So switching to the detail when trigger a state change recomposing the screen while retaining the state of the master and upon switching back same thing recompose the screen and remember the detail screen state and go right back to the masters previous state.

Not offended - just curious for feedback!