1

In the Android development world there is a set order of Fragment/Activity lifecycle superclass method calls. I refer to the answer.

Now, regarding Flutter, if I type an empty StatefulWidget in IDE (both Visual Code and Android Studio) didUpdateWidget or any other callback, then I accept the prompt, I end up with such an order with place for implementation before the call.

  @override
  void didUpdateWidget(covariant AnimatedIconsCircle oldWidget) {
    // TODO: implement didUpdateWidget
    super.didUpdateWidget(oldWidget);
  }

The superclass method call order proposition is in contrary to the Flutter codebase:

  /// Implementations of this method should start with a call to the inherited
  /// method, as in `super.didUpdateWidget(oldWidget)`.
  @mustCallSuper
  @protected
  void didUpdateWidget(covariant T oldWidget) { }

What's the correct approach? Does it even matter?"

PrzemekTom
  • 1,328
  • 1
  • 13
  • 34
  • The key ones to remember are super.initState which comes first, and super.destroy which comes last. If it's not documented, it probably doesn't matter, but I typically put them first anyway. – Randal Schwartz Feb 23 '23 at 20:04
  • I don't think the `// TODO: Implement didUpdateWidget` comment is meant to be indicative of where to place your code. It's just telling you that you need to add your own implementation, and in the meantime, it's falling back to the base implementation. – jamesdlin Feb 23 '23 at 21:24

1 Answers1

0

I realised that the docs are obvious about some of the build methods:

Implementations of this method should start with a call to the inherited method, as in super.initState().

No information. I tested it with InheritedWidget and the order doesn't matter.

Implementations of this method should start with a call to the inherited method, as in super.didUpdateWidget(oldWidget).

Implementations of this method should end with a call to the inherited method, as in super.dispose().

PrzemekTom
  • 1,328
  • 1
  • 13
  • 34