IssueTracker

Initial proposal in https://android-review.googlesource.com/c/platform/frameworks/support/+/1931284

Design doc: https://docs.google.com/document/d/11-TD-Cr6_luQYztmOHNFUiOKGzZLKYgD9Zx0yjkyb74/edit?resourcekey=0-Z13UmPVZQVE2Z0pRs6-HoA

Related to b/185418980

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.compose.foundation:foundation:1.4.0-alpha04

Can we have some state for this modifier, so we know if content fits the container or it's gonna be animated? To match XML attribute behaviour, I'd like to draw gradient edges, but I don't need them in case content doesn't animate.

I created a feature request for this: https://issuetracker.google.com/268320333. Please add any information to that feature request instead of here!

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