timer not disposed when the animated text is

[Brainstorm67]

When using FadeAnimatedTextKit (and probably other animations to check) the inner timer keeps going even if the widget is disposed (on screen change for example).
This can cause trouble depending on what is in the onFinished callback. In my case it was a setState going crazy because its widget was already disposed.

To Reproduce
my usage :
FadeAnimatedTextKit(
duration: Duration(milliseconds: 500),
isRepeatingAnimation: false,
onFinished: () {
setState(() {
go = true;
});
},
text: ['Ready ?', '3', '2', '1', 'Go !'],
textStyle: kCenterStyle,
)

the error triggered when I swipe pages while text is animating :
[ERROR:flutter/lib/ui/ui_dart_state.cc(166)] Unhandled Exception: setState() called after dispose(): _StartScreenState#2530f(lifecycle state: defunct, not mounted)
E/flutter (26541): This error happens if you call setState() on a State object for a widget that no longer appears in the widget tree (e.g., whose parent widget no longer includes the widget in its build). This error can occur when code calls setState() from a timer or an animation callback.
E/flutter (26541): The preferred solution is to cancel the timer or stop listening to the animation in the dispose() callback. Another solution is to check the "mounted" property of this object before calling setState() to ensure the object is still in the tree.
E/flutter (26541): This error might indicate a memory leak if setState() is being called because another object is retaining a reference to this State object after it has been removed from the tree. To avoid memory leaks, consider breaking the reference to this object during dispose().

Expected behavior
The timer should be canceled on dispose

Flutter:

• version 1.19.0-4.2.pre
• channel beta

Dart:

• version 2.9.0 (build 2.9.0-14.1.beta)

[awhitford]

I think you are right in that the Timer's lifecycle does not seem to be properly managed.

At the very least, I think calling _timer?.cancel(); in the dispose() method is worth adding. Not totally sure if that is all, though -- I'd like to see some kind of assertion before creating a new _timer that there isn't already an active timer (otherwise it will leak).