Unbound AnimationControllers for Anicoto

[AndreBerzun]

Hi there!

first of, great library, I'm really enjoying it so far. Thanks for sharing!

Is there a particular reason for not supporting unbound controllers in Anicoto's createController method? I recently stumbled upon this issue when I tried to implement a physics-based AnimationController as these ones usually require to be unbound, see the Flutter doc to the AnimationController#animateWith method:

Drives the animation according to the given simulation.

The values from the simulation are clamped to the [lowerBound] and [upperBound]. To avoid this, consider creating the [AnimationController] using the [new AnimationController.unbounded] constructor.

Returns a [TickerFuture] that completes when the animation is complete.

The most recently returned [TickerFuture], if any, is marked as having been canceled, meaning the future never completes and its [TickerFuture.orCancel] derivative future completes with a [TickerCanceled] error.

The [status] is always [AnimationStatus.forward] for the entire duration of the simulation.

[felixblaschke]

Hi,

no there is no particular reason for this. I never stumbled about that scenario. Is it a common use case to have an unbound controller?

[AndreBerzun]

Hi,

as I said, if you want to power the AnimationController with a physical simulation (e.g. to simulate a spring or gravitational force) instead of a simple linear progression from 0 to 1, you need an "unbound" AnimationController. From my understanding, animation controllers by default are bound to the interval [0;1] but physical simulations often pass the boundaries of said interval (therefore "unbound").

Also the only difference between a regular and an unbound animation controller is that they are instantiated through different constructors. Other than that there are no differences API-wise ... At the moment you can't use animation controllers that are managed by anicoto for physical simulations because the library always uses the bound constructor version.

I think it shouldn't be too difficult to maybe implement some kind of flag that lets devs choose what type of AnimationController to instantiate.

[felixblaschke]

Okay, I added it as an optional Parameter inside the createController() method that's offered by the AnimationMixin.

Example:

class AnicotoUnbounded extends StatefulWidget {
  @override
  _AnicotoUnboundedState createState() => _AnicotoUnboundedState();
}

class _AnicotoUnboundedState extends State<AnicotoUnbounded> with AnimationMixin {

  AnimationController unboundController;

  @override
  void initState() {
    unboundedController = createController(unbounded: true);
    super.initState();
  }

  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

Since I am not familiar with physical based animation. Can you try out if this works?

You can do this by adding the 1.1.0 version of anicoto in your pubspec:

dependencies:
  (...)
  sa_anicoto: ^1.1.0

[AndreBerzun]

Thanks ... will look into it today!