preface

If you’re an Android, iOS, React, or Vue developer, then you’re no stranger to the lifecycle. While learning about Flutter, Flutter has its own lifecycle. This article will cover the lifecycle of Flutter to learn where business logic should be written.

The life cycle of a Flutter

The lifecycle of a Flutter is divided into two parts:

  1. The Widget’s life cycle
  2. App life cycle

The Widget in a Flutter refers to a View, so the lifecycle of the Widget is the creation and destruction of the View, etc. But if you want to know whether the App is in the foreground or background, you need to use the lifecycle of the App.

The Widget’s life cycle

Flutter widgets are divided into statelessWidgets and StatefulWidgets. The life cycles of these two widgets are different.

Life cycle of the StatelessWidget

The StatelessWidget has only one life cycle:

  • build

    The build is used to create the Widget, but since the build is called every time the screen is refreshed, do not write the business logic in the build. Instead, write the business logic in the constructor of your StatelessWidget.

    The build function for the StatelessWidget looks like this:

    class TestWidget extends StatelessWidget{
  @override
  Widget build(BuildContext context) {
    // TODO: implement build
    print('StatelessWidget build');
    return Text('Test'); }}Copy the code

The life cycle of StatefulWidget

The life cycle of statefulWidgets is complex, in order:

  • createState
  • initState
  • didChangeDependencies
  • build
  • addPostFrameCallback
  • didUpdateWidget
  • deactivate
  • dispose

Let’s look at each life cycle in detail.

  • createState

    CreateState is the method used to create a State in a StatefulWidget. When a new StatefulWidget is created, createState is executed immediately and only once. CreateState must implement:

    class MyScreen extends StatefulWidget {
  @override
  _MyScreenState createState() => _MyScreenState();
}
Copy the code

  • initState

    The previous createState method is called when the StatefulWidget is created, initState is the first method called after the StatefulWidget is created, and is executed only once. Similar to onCreate on Android, viewDidLoad() on iOS, so the View is not rendered, but the StatefulWidget is already loaded into the render tree, The StatefulWidget’s mount value will be true until Dispose calls it false. You can do some initialization in initState.

    Super.initstate () must be called when overriding initState:

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

  • didChangeDependencies

    When the StatefulWidget is first created, the didChangeDependencies method is called immediately after the initState method and not later when the StatefulWidget is refreshed. DidChangeDependencies will not be called until the InheritedWidget that your StatefulWidget depends on has changed, so didChangeDependencies may be called multiple times.

  • build

    When StatefulWidget is first created, the Build method is called immediately after the didChangeDependencies method. Another scenario where the Build method is called is whenever the UI needs to be rerendered, So build gets called multiple times and returns the Widget to render. Never do anything in your build other than create widgets, as this will affect UI rendering efficiency.

  • addPostFrameCallback

    AddPostFrameCallback is a callback to the end of StatefulWidge’s rendering. It is only called once, and the StatefulWidget will not be called after it needs to refresh the UI. AddPostFrameCallback is used by adding a callback to initState:

    import 'package:flutter/scheduler.dart';
@override
void initState() {
  super.initState();
  SchedulerBinding.instance.addPostFrameCallback((_) => {});
}
Copy the code

  • didUpdateWidget

    DidUpdateWidget is a life cycle that we don’t normally use and is called only when a Widget is reused using a key.

  • deactivate

    When a State object is removed from the render tree, the DeActivate lifecycle is called, which signals that the StatefulWidget is about to be destroyed, but sometimes the State is not destroyed, but reinserted into the render tree.

  • dispose

    When the View no longer needs to be displayed and is removed from the render tree, State is permanently removed from the render tree and Dispose life cycle is called. At this time, you can do some unlisten and animation operations in dispose, which is the opposite of initState.

App life cycle

If you want to know the lifecycle of the Flutter App, such as whether the Flutter is in the foreground or background, you need to use WidgetsBindingObserver as follows:

  1. State class Mix WidgetsBindingObserver:

    class _MyHomePageState extends State<MyHomePage> with WidgetsBindingObserver {
    ...
}
Copy the code

  2. Add listener to initState of State:

    @override
  void initState(){
    super.initState();
    WidgetsBinding.instance.addObserver(this);
  }
Copy the code

  3. Dispose dispose dispose dispose dispose dispose dispose dispose dispose dispose

      @override
  void dispose() {
    // TODO: implement dispose
    super.dispose();
    WidgetsBinding.instance.removeObserver(this);
  }
Copy the code

  4. In the State override didChangeAppLifecycleState

    @override
void didChangeAppLifecycleState(AppLifecycleState state) {
  super.didChangeAppLifecycleState(state);
  if (state == AppLifecycleState.paused) {
    // went to Background
  }
  if (state == AppLifecycleState.resumed) {
    // came back to Foreground
  }
}
Copy the code

The AppLifecycleState is the life cycle of the App.

  • resumed
  • inactive
  • paused
  • suspending

reference

Medium.com/flutter-com…