ViewPropertyObjectAnimator VS simple-stack-compose-integration

I've been using https://github.com/blipinsk/ViewPropertyObjectAnimator and it's amazing

you just use https://github.com/blipinsk/ViewPropertyObjectAnimator for everything, and if you need shared element transtiions you cry (then again, it's not like Compost can do that at all, so)

Animations with views were much easier, you just had to use this lib https://github.com/blipinsk/ViewPropertyObjectAnimator and animator sets made it trivial. If you needed fancy crossfades then TransitionManager.beginDelayedTransition(container) and that's it.

Honestly, they're pretty even in that regard. Whether you use XML or Compose in "simple apps" is up to you. Some things are easier in Compose, and some things are just stupid tricky. Animations in Compose are the worst imo, with ViewPropertyObjectAnimator they used to be trivial for XML layouts.

This is probably just my experience, but with Compose I have to muck around with LaunchedEffects and manual interpolation, while with XML views I could just use https://github.com/blipinsk/ViewPropertyObjectAnimator and AnimatorSet().playTogether().

That, and animations with https://github.com/blipinsk/ViewPropertyObjectAnimator were much easier than linear interpolating in a LaunchedEffect, and shadow support is basically non-existent (Modifier.shadow() doesn't work as you expect, even android:elevation was better).

I like this library https://github.com/blipinsk/ViewPropertyObjectAnimator

I don't know how to write animations without ViewPropertyObjectAnimator https://github.com/blipinsk/ViewPropertyObjectAnimator

Really? I just used https://github.com/blipinsk/ViewPropertyObjectAnimator + AnimatorSet for everything and it always just worked

Yup, that's why we're working on https://github.com/Zhuinden/simple-stack-compose-integration/ to make it as simple as backstack.goTo(SomeScreenKey(arg1, arg2)) instead of this navController.navigateTo("some/screen&arg1=${UrlEncoder.encode(arg1.toBase64())} stuff. If you are working on an Android app that will always be on Android-only, why would you inherit limitations from Kotlin Multi-platform?

We have https://github.com/Zhuinden/simple-stack-compose-integration/ but the fact that I'd normally prefer to use fragments kinda holds it back

Simple-Stack-Compose https://github.com/Zhuinden/simple-stack-compose-integration

However, it's worth noting that thanks to a guy named @matejdro we are working on a pure-Compose version, in which setup has been reduced to

And ,yes, although not being made for Compose, also Simple stack :)

i'd love to recommend simple-stack-compose-integration but i never wrote this missing link

Using any of the 5 prominent community alternatives is a better approach (even though most people hoping to use the docs as if it was like, written for stable code, will muck around with their apps crashing if the user inputs a & symbol). I have this thing but I'd consider taking a look at https://github.com/adrielcafe/voyager or maybe https://github.com/olshevski/compose-navigation-reimagined

If you're deadset on full compose navigation I'd check out Zhuinden`s simple-stack-compose-integration

I'm almost tempted to use multiple ComposeViews, but I'm definitely not using 1 ComposeView N composables any time soon, even though technically I have the code to support it.