IssueTracker

As a data point for this issue: going forward, core will likely have more dependencies on the animation primitives (from animation-core). :)

We were running into a similar circular dependency problem with animated vectors (cc Nader) - vectors live in UI but animated vectors need animation APIs.

Did we consider moving animation to be a lower group than ui? We could move the animation clock ambient to animation directly, avoiding the cyclic dependency, and also lets us use animation APIs in the ui library.

It also seems that animateContentSize makes more sense in the ui group than animation.

Re #4: Could you elaborate on what moving animation to be a lower group would look like? Is this animation or both animation and animation-core?

I assume there's a policy against having animation-core and animation in separate groups? That would solve the cicular dependency between groups.

BTW, AnimationClock is going away by Beta, although that wouldn't solve the animated vectors issue.

Re #4: Could you elaborate on what moving animation to be a lower group would look like? Is this animation or both animation and animation-core?

Sorry, I meant moving the group androidx.compose.animation 'down' - so that would be both animation and animation-core.

Currently our dependencies are something like: (we want to prevent these groups from depending on things above them)

material
foundation
animation
ui
runtime

If we swap animation and ui, and make it so that nothing in the animation group depends on ui, but allow the ui group to depend on animation, it sounds like we can fix this dependency issue, move UI related APIs like animateContentSize out of animation keeping the animation group strictly animation related, and also lets us add new APIs to ui like animated vectors since we would be able to depend directly on animation and animation-core from within ui.

From a brief look it doesn't look like this would affect much, there aren't many ui related imports in animation.

Thanks for the walk-through. It was very helpful. :) I would propose a small tweak to your suggestion: Bring animation lib into ui group, instead of moving APIs. That would allow us to animation group down.

The design intention for animation as a library was to host higher level APIs that depend on both animation-core and other modules. If we were to move the animation group down and remove animation lib's dependency on ui, and move all the APIs that depend on ui to ui, we might as well move the whole lib to ui. This way animation group would only contain animation-core (and demos and samples module for it), and it's gauranteed to not depend on anything above it. Wdyt?

Sounds like a reasonable option to me as well, although I kinda like having the separation of androidx.compose.animation - I don't see why things like transition and single animated value should be tied to Compose UI, theoretically they could be useful for other tree types. Either option sounds good, but we should decide and land this soon.

Transition v2 is in animation-core. Single value animation can also be moved to animation-core as a result of recent decision to have it depend on runtime. We plan on re-naming the animate APIs as well. Agreed that we should make a decision on this soon.

cc+ George

result of recent decision to have it depend on runtime

I wonder if it's still fair to call it animation-core at this point. How about we move everything in animation-core to animation, and the ui bits go to ui-animation? So we would have:

// Compose animation library (transition / single value animation etc)
androidx.compose.animation:animation

// Animation integration for Compose UI (crossfade / animated modifier, etc)
androidx.compose.ui:ui-animation

Yes, assuming we do decide to move animation into ui group, then it makes total sense to rename animation-core to animation. :)

Is this actually obsolete? We still have a dependency on :compose:animation:animation-core from compose:ui:ui

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/ui/ui/build.gradle;l=45

Looks like this is used in our animated vector support, shouldn't these be moved up to a separate module? (having an api dependency here in particular seems very worrying..)

Seems like it's a different reason for the dependency now - previously it was ambient animation clock. Splitting animation and animation-core in separate groups is no longer a viable option. Moving animation group up is reasonable as long as we could sort out the dependency issue. :)

Looping in Yuichi, owner of animated vector. Yuichi, would it be possible to move the animated vector impl to the animation group or another module that depends on both animation and ui? If I remember correctly, we tried that approach and ended up with a bunch of extra APIs to support cross module communication. :(

Louis, how critical is this? This would require a large refactor that I think might be too late at this stage of Beta. :(

My understanding is that we don't currently have a circular dependency, just a module separation that isn't critical to have anymore, right?

My understanding is that we don't currently have a circular dependency, just a module separation that isn't critical to have anymore, right?

We still have a cycle between library groups:

animation:animation depends on ui:ui which depends on animation:animation-core

This will make it very difficult to independently version these library groups (ui and animation), since if a developer increases the version of ui:ui, it might actually end up increasing the version of animation:animation-core too.

if that's the case then either animation and ui are effectively part of the same version group, or animation and animation-core are separate version groups of their own and may not establish and use opt-in internal APIs between them.