Introducing AnimationControllerX for Flutter

This article covers a previous version of Simple Animation. The basics stay the same but class names have changed.

When creating custom animations in Flutter at some point you get in touch with Flutter’s AnimationController that connects rendering requests with your Animatable, like tweens. For each rendered frame it computes a value between 0.0 and 1.0 depending on it’s current animation execution and passes it to your tweens.

Adding an AnimationController to your widgets is a little more overhead in code than are you are used to. That’s why the Simple Animations package provides you with some easy-to-animate widgets like ControlledAnimation.

But in some situations it’s inevitable to use AnimationController to have precise control over your custom animations. Aspects like dependencies to other states of the app or changing animation durations may want you to use an AnimationController .

When you look into Flutter’s regular AnimationController you will find out that it’s possibilities are quite limited:

  • You can just tell it to do one thing (animate forward / reverse) but not declare your animation plan.
  • You can’t tell it to consider external circumstances.
  • It’s not very extensible for other animation approaches.
  • The status management (StatusListener) is very limited. It just tells when it reaches 0.0 and 1.0 but nothing in between.

To solve these issues I am proud to introduce AnimationControllerX.

The setup

The AnimationControllerX is the new member of the Simple Animation package. It’s a powerful implementation of an AnimationController that you can use to create precisely-controlled animations.

Lets start by looking on how we do animations with a regular animation controller:

What’s happening in short: We use the mixin to make our state class a ticker provider and passes it as vsync parameter to create a controller. We also provide a duration. Then we need to tell our controller to call setState() to rebuild on every new animation value computed. Don’t forget to dispose the controller. Finally we can specify our tween for the width and start animating forward.

Using AnimationControllerX instead of the regular one is very simple. Just change two lines:

AnimationControllerX uses the same interfaces towards your tweens and widget rebuilding logic.

But there is more. AnimationControllerX comes with an own mixin to accelerate the setup. Just use AnimationControllerMixin on your state class:

The mixin provides you with a ready-initialized AnimationControllerX as controller class property and rebuilds automatically on animation value changes. We achieve the same with 40% less code.


From the example above you can guess that there are no plain commands like forward or reverse. AnimationControllerX uses a task queue to animate complex scenarios easily. On each frame it looks into the queue for a new task and executes it. After completing, it looks for another, and so on.

The task interface is designed with expandability in mind. You can create new task types by simply extending from the abstract class AnimationTask .

But you don’t need to. I created many important task types to start with. Here are some small examples:

You may notice that the animation duration is no longer a property of the controller itself. Each task manages it’s own duration. Here are some other differences:

This should be enough for one blog post about AnimationController theory. In my next post I will focus on the new possibilities enabled by AnimationControllerX.

The curious ones of you can already dive into the documentation to find out. You can start using it with the new version 1.3.0 of simple_animations .

See you next time with cool complex, conditional aware animations and awesome status management. Leave some claps if you like it.

— Felix —

Software Developer,