IssueTracker

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.

animation and ui are effectively part of the same version group

What would this look like? I'd rather not put a hard requirement to never use internal or experimental APIs across the two animation libs, which would be required by the other option.

After some investigation, I think we can eliminate the dependency from ui to animation to simplify things a bit. This would require refactoring out the impl of animated-vector that depends on animation group into a separate module. Since the animated-vector features are experimental, this can be done post 1.0.

However, there is unfortunately another group level dependency cycle:

foundation (from foundation group) -> animation -> foundation-layout (from foundation group)

I don't see a good way to avoid this without creating hurdles that'd make animation feature development difficult. It is somewhat analogous to the group level dependency story between fragment and lifecycle:

 lifecycle-extensions (from lifecycle group) -> fragment -> lifecycle-viewModel/livedata-core (from lifecycle group)

Louis is right that independent versioning would be difficult. Animation and foundation would need to be released in lock steps, similar to lifecycle and fragment. It's still lesser of the two evils, compared to splitting animation libs. The animation lib requires animation-core to add new low-level experimental APIs (for example: Transition.createChildTransition) to support high level animation features. Not allowing experimental API usage between these two libs would therefore hinder feature development.

foundation (from foundation group) -> animation -> foundation-layout (from foundation group)

We have usages in Crossfade and AnimatedVisibility

Crossfade just uses a Box as an implementation detail, we can probably refactor that out and just build our own simpler box for internal usage.

AnimatedVisibility has (experimental) extensions for RowScope and ColumnScope, which seems more problematic.

Do these extensions need to live here? Or when the underlying APIs are stable, could they live in foundation-layout? It seems reasonable that ColumnScope / RowScope animation implementations, live in the same place that they are defined, then we could remove this dependency inversion. I would really like to avoid the case where updating your animation dependency so you can make use of new animation APIs also ends up updating how Row behaves.

I would really like to avoid the case where updating your animation dependency so you can make use of new animation APIs also ends up updating how Row behaves.

I understand the desire to make the two libs independent. I'm in full support of removing the dependency on animation from ui group.

Updating how Row behaves when updpating animation may be desired because going forward we'll lean more and more on foundation-layout to reuse some of the implementation so that animation doesn't need to reinvent the wheels and implement the same layout logic. For example, I'm planning on implementing AnimatedRow, for which I'd prefer to reuse as much from the Row's static layout/spacing logic as possible, rather than duplicating the code. I won't be able to put something like AnimatedRow outside of animation, because animating values not known until measure/layout is not supported in stable animation API yet.

Do these extensions need to live here? Or when the underlying APIs are stable, could they live in foundation-layout? It seems reasonable that ColumnScope / RowScope animation implementations, live in the same place that they are defined, then we could remove this dependency inversion.

That's a great question. We are just starting with the layout animation APIs. There will be more and more cases where we'd put out experiemental animation APIs, as well as their Row/Column specific variant. The Row/ColumnScope extension of AnimatedVisibility account for the majority API use for AnimatedVisiblity nowadays, because they are tailored to the specific layouts and therefore more convenient. We'd hurt the dev experience more than we gain if we had to take that (and future opportunities of) optimization away.

Doris and I chatted; it looks like a promising path forward is aligning the compose-animation modules with the foundation version group and breaking the dependency from compose-ui on animation-core. The only usages in a quick survey are the experimental animated vector support, tests, and samples. If we move the experimental animated vector support to a foundation-level module that depends on animation, we can keep the compose-ui <-> compose-foundation version boundary strict.

Yes, that was also what I meant in #21 by "removing the dependency on animation from ui group."

Yuichi has kindly agreed to take on the task to move the animated vector work out of ui, therefore removing ui's dependency on animation-core. We can cherry-pick that change into release branch once it lands. (https://android-review.googlesource.com/c/platform/frameworks/support/+/1748158)

I'll fix the tests' and sample's dependency on animation from ui in a follow-up CL.

Follow-up is at: https://android-review.googlesource.com/c/platform/frameworks/support/+/1750079

It'd be nice to enforce the lib group dependency so it can only be one-way from higher level groups on lower level groups. Filed feature request at b/192389944 to track that.

In 1.0.0 the animatedvectorresource and the AnimatedImageVector is missing. please release it as soon as possible as it is causing issues with my app. please sugest some workaround as my app heavely depend on it.

Re #28:

AnimatedVectorResource will be included in the next Compose release in 1-2 weeks in a new lib: animation-graphics. Stay tuned! Sorry for the inconvenience.

Thanks