If you’ve ever worked with ViewControllers in iOS, it’s easy to understand the importance of life cycles in UI drawing. Flutter also has a lifecycle, and its callback methods are reflected in State, source code reference.

The life cycle of a Flutter is divided into widgets and apps. Understanding the Flutter lifecycle is crucial to writing a sensible Widget and a robust APP.

Page life cycle

Take a look at the life cycle of a Flutter page using the StatefulWidget as an example. The life cycle of a Widget can be roughly divided into three phases:

1. Initialization

  • createState
     // This method must be overridden
     @override
     _LifecycleWidgetState createState() => _LifecycleWidgetState();
Copy the code

This method is called first when building a StatefulWidget and must be overridden.

  • initState
@override
  void initState() {
  super.initState();
}
Copy the code

This method call occurs after createState and is the first method to be called other than the constructor, similar to onCreate() on Android and viewDidLoad() on iOS. This method usually does some initialization, such as channel initialization, listener initialization, etc. Corresponding to Dispose ().

2. Status changes

  • didChangeDependencies

    @override
      void didChangeDependencies() {
        super.didChangeDependencies();
      }
    Copy the code

    This approach requires that you must call the superclass method. Super didChangeDependencies, call when rely on the State of the object of change.

    1. When the Widget is first built, theinitState()This method is then called immediately.
    2. If StatefulWidgets depend on the InhertedWidget, it will be called again when variables in the InheritedWidget on which the current State depends change.
  • build

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

Is a method that must be implemented to implement the page content to be rendered. It is called immediately after didChangeDependencies(), and again when setState() is called

  • didUpdateWidget
@override
void didUpdateWidget(covariant LifecycleWidget oldWidget) {
     super.didUpdateWidget(oldWidget);
}
Copy the code

The didUpdateWidget will be called when setState is called to change the Widget’s State. A new Widget will be created by Flutter to bind the State and the old Widget will be passed in this method. So if you want to compare old and new widgets and make some adjustments to State, you can use it.

Also, if changes to the Controller are involved in some widgets, be sure to remove the old Controller and create a new Controller listener in this callback method.

3. The destruction of

  • deactivate

    @override
      void deactivate() {
        super.deactivate();
      }
    Copy the code

    This method is uncommon, it is called when the component is removed, and before dispose calls

  • dispose

    @override
      void dispose() {
        super.dispose();
      }
    Copy the code

    Corresponds to initState().

    Called when a component is destroyed. Usually this method performs some work to free resources, such as listener removal, channel destruction, etc., which is equivalent to iOS dealloc. Methods the reference

App life cycle

Apps have scenes, such as cutting from the foreground to the background and cutting back from the background to the foreground. In iOS, these life cycles can be represented in the AppDelegate. How should we handle these scenes in Flutter? The app-level life cycle is slightly different from the Widget life cycle described above.

Source reference

If you want to listen for the life cycle of your App, you need to use WidgetsBinding to listen for WidgetsBindingObserver, which is a Widgets binding observer, to listen for the life cycle of your App. The observer is bound in a mixin manner and the listener needs to be removed in the Dispose callback method.

Rewrite didChangeAppLifecycleState, when life cycle will callback when there is a change this method,

class _LifecycleAPPState extends State<LifecycleAPP>
    with WidgetsBindingObserver {
	@override
  void initState() {
    // Add a listenerWidgetsBinding.instance! .addObserver(this);
    super.initState();
  }

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

  @override
  void didChangeAppLifecycleState(AppLifecycleState state) {
    super.didChangeAppLifecycleState(state);
		print(state);
  }

  @override
  void dispose() {
		// Remove the listenerWidgetsBinding.instance! .removeObserver(this);
    super.dispose(); }}Copy the code

Flutter encapsulates an enumeration, AppLifecycleState, to describe the APP lifecycle:

enum AppLifecycleState {
  resumed, // Enter the front desk
  inactive, // called when the app is inactive and does not receive user input. Like answering a call
  paused,// go to the background
  detached, // App still resides on the Flutter engine but is separated from the native platform
}
Copy the code

We can get the state in didChangeAppLifecycleState () to do something we need to deal with logic.