Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Newly constructed tweens should have same begin and end #94363

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 16, 2022

Conversation

werainkhatri
Copy link
Member

FIxes a bug where when a tween is constructed (was null before), after the implicit animated widget has animated at least once, the newly constructed tween has end = null. The widget is not animated, as the tween has just been constructed (shouldAnimate = targetValue != (tween.end ?? tween.begin)) and hence not updated. But the animation.value is 1.0 (as it has been animated once before). So, when this tween is evaluated against animation.value, it throws an error.

The fix is to set the tween.end of every newly constructed tween to tween.begin.

fixes #84258

Pre-launch Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
  • I signed the CLA.
  • I listed at least one issue that this PR fixes in the description above.
  • I updated/added relevant documentation (doc comments with ///).
  • I added new tests to check the change I am making, or this PR is test-exempt.
  • All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@flutter-dashboard flutter-dashboard bot added a: animation Animation APIs framework flutter/packages/flutter repository. See also f: labels. labels Nov 29, 2021
@google-cla google-cla bot added the cla: yes label Nov 29, 2021
@werainkhatri
Copy link
Member Author

Failing checks will be fixed once #94601 is merged.

@HansMuller HansMuller requested a review from goderbauer December 3, 2021 23:00
@flutter-dashboard
Copy link

This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@@ -430,6 +430,8 @@ abstract class ImplicitlyAnimatedWidgetState<T extends ImplicitlyAnimatedWidget>
tween ??= constructor(targetValue);
if (_shouldAnimateTween(tween, targetValue))
shouldStartAnimation = true;
else
tween.end ??= tween.begin;
Copy link
Member

@goderbauer goderbauer Jan 13, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is correct. For some tweens (e.g. ColorTween, https://master-api.flutter.dev/flutter/animation/ColorTween-class.html) null has a special meaning. And as documented in https://master-api.flutter.dev/flutter/animation/Tween-class.html under "Nullability" that's totally ok.

Copy link
Member Author

@werainkhatri werainkhatri Jan 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand that.

  1. I haven't removed the ability for the value to be null. I'm just making sure that when the tween should not animate, begin and end should be the same, as there is no animation. This adds to a state of being unanimated.
  2. In the current implementation of ImplicitlyAnimatedWidget, it is not possible to animate from non-null color to null anyway, as when the color (aka targetValue) becomes null, the tween is set to null, ignoring it. As a matter of fact, this is something that needs to be fixed too.
  3. Lastly, ImplicitlyAnimatedWidget should be agnostic of what should happen when targetValue becomes null. Current extensions of ImplicitlyAnimatedWidget are trying to expect different things from it. Example: AnimatedContainer has a nullable alignment argument which is supposed to be ignored when it is null, which makes its tween null. Whereas AnimatedColor (fictional widget working over ColorTween) has a special meaning when its color is null, meaning its tween should remain non-null and have end set to null.

Possible solution:

  1. The tweens' nullability should be handled by ImplicitlyAnimatedWidget's extension instead of itself.
  2. The check for whether a tween should animate or not, should depend only on its current end, even it it's null.
    bool _shouldAnimateTween(Tween<dynamic> tween, dynamic targetValue) {
        return targetValue != tween.end;
      }
  3. From the perspective of ImplicitlyAnimatedWidget, targetValue being null should be considered as one of the valid tween states instead of using it to null the tween.

From the user's perspective, whatever value (null or non-null) is passed to forEachTween, the tween will animate to it. If I wish to ignore it, I should make the tween null themselves.

@goderbauer
Copy link
Member

@werainkhatri This is still blocked on #94601 getting fixed first?

@werainkhatri
Copy link
Member Author

werainkhatri commented Mar 31, 2022

@goderbauer no, this is separate now. i have listed my findings in the conversation above. do let me know what you think.

@goderbauer
Copy link
Member

OK. Can you rebase this to the latest master and make sure that all checks pass? Thanks!

Copy link
Member

@goderbauer goderbauer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@werainkhatri
Copy link
Member Author

Looks like this was blocked due to #94601

@goderbauer do you mind taking a look at the Google Testing check?

@goderbauer
Copy link
Member

Retriggered the check, let's see what happens.

@werainkhatri
Copy link
Member Author

Fails again :(

@goderbauer
Copy link
Member

I triggered it again. Hopefully it will pass. There were some technical problems with the check last week.

@werainkhatri
Copy link
Member Author

Still failing...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a: animation Animation APIs framework flutter/packages/flutter repository. See also f: labels.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CircleAvatar widget throws Exception if the foregroundImage property changed
2 participants