Flutterexperts

Knowing the basics of Flutter is the most significant and commendable speculation you can do while learning Flutter. You ought to consistently know how the application lifecycle is created, rendered, updated, and destroyed as it will assist you with understanding your code!. Similarly, as with each structure out there, Flutter likewise has a lifecycle related to each application.

We will likewise explore how to observe orientation change in our application. At last, we will perceive how to reuse the lifecycle rationale so all the lifecycle strategies are accessible across our application.

In this blog, we will explore the App Lifecycle In Flutter. We will likewise explore the distinctive application lifecycle strategies accessible in flutter and use them in your flutter applications.

---

---

Lifecycle of Flutter App:

The lifecycle of the Flutter App is the show of how the application will change its State. It helps in understanding the idea driving the smooth progression of our applications. Everything in Flutter is a Widget, so before thinking about Lifecycle, we should think about Widgets in Flutter.

Flutter has majorly two types of widgets:

• Stateless Widgets
• Stateful Widgets

Before thinking about the Lifecycle, we need to comprehend the distinction between the two widgets.

> Stateless Widgets:

Stateless Widgets are those widgets that don’t need to deal with the State as they don’t change powerfully at runtime. It becomes permanent like on variables, buttons, symbols, and so forth, or any express that can’t be changed on the application to recover information. Returns a widget by overwriting the build method. We use it when the UI depends on the data inside the actual item.

import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

> Stateful Widgets:

Stateful Widgets are those widgets that hold the State and the UI being portrayed can change progressively at runtime. It is a changeable widget, so it is attracted numerous times during its lifetime.

We utilize this when the user progressively updates the application screen. This is the most significant of the multitude of widgets, as it has state widgets, everybody realizes that something has been updated on our screen.

import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatefulWidget {
  @override
  _MyAppState createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {
  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

Thus, as we are examining the LifeCycle of Flutter, we will focus on ‘Stateful Widgets’ as they need to deal with the State.

Stages Of App Lifecycle:

The life cycle depends on the state and how it changes. A stateful widget has a state so we can clarify the life cycle of flutter dependent on it. Stage of the life cycle:

• createState()
• initState()
• didChangeDependencies()
• build()
• didUpdateWidget()
• setState()
• deactivate()
• dispose()

Let deeply explain on Stage of the life cycle:

> createState()

This method is called when we create another Stateful Widget. It is an obligatory strategy. The createState() returns a case of a State-related with it.

class HomeScreen extends StatefulWidget {

  HomeScreen({Key key}) : super(key: key);
  
  @override
  HomeScreenState<StatefulWidget> createState() => HomeScreen();
}

> initState()

This is the strategy that is considered when the Widget is made interestingly and it is called precisely once for each State object. If we characterize or add some code in the initState() method this code will execute first even before the widgets are being built.

This method needs to call super.initState() which essentially calls the initState of the parent widget (Stateful widget). Here you can initialize your variables, objects, streams, AnimationController, and so on.

@override
void initState(){
  super.initState();
}

> didChangeDependencies()

This method is called following the initState() method whenever the widget initially is constructed. You can incorporate not many functionalities like API calls dependent on parent data changes, variable re-initializations, and so forth.

@override
void didChangeDependencies() {

}

> build()

This strategy is the main method as the rendering of all the widgets relies upon it. It is called each time when we need to render the UI Widgets on the screen.

At whatever point you need to update your UI or on the other hand on the off chance that you click hot-reload, the Flutter structure modifies the build() strategy!. Assuming you need to expressly revamp the UI if any information is transformed, you can utilize setState() which teaches the framework to again run the form method!

@override
Widget build(BuildContext context) {
  return Scaffold()
}

> didUpdateWidget()

This strategy is utilized when there is some adjustment of the configuration by the Parent widget. It is essentially called each time we hot reload the application for survey the updates made to the widget

If the parent widget changes its properties or designs, and the parent needs to modify the child widget, with a similar Runtime Type, then, at that point, didUpdateWidget is triggered. This withdraws to the old widget and buys into the arrangement changes of the new widget!.

@protected
void didUpdateWidget(Home oldWidget) {
  super.didUpdateWidget(oldWidget);
}

> setState()

The setState() method illuminates the framework that the internal state of this item has changed in a manner that may affect the UI which makes the structure plan a build for this State of the object.

It is an error to call this method after the system calls dispose(). This inside state could conceivably influence the UI apparent to the user and subsequently, it becomes important to rebuild the UI.

void function(){
  setState(() {});
}

> deactivate()

This method is considered when the State is removed out from the tree, however, this strategy can be additionally be re-embedded into the tree in another part.

This strategy is considered when the widget is as of now not joined to the Widget Tree yet it very well may be appended in a later stage. The best illustration of this is the point at which you use Navigator. push to move to the following screen, deactivate is called because the client can move back to the past screen and the widget will again be added to the tree!.

@override
void deactivate(){
  super.deactivate();
}

> dispose()

This strategy is essentially something contrary to the initState() method and is likewise important. It is considered when the object and its State should be eliminated from the Widget Tree forever and won’t ever assemble again.

Here you can unsubscribe streams, cancel timers, dispose animations controllers, close documents, and so on. At the end of the day, you can deliver every one of the assets in this strategy. Presently, later on, if the Widget is again added to Widget Tree, the whole lifecycle will again be followed!.

@override
void dispose(){
  super.dispose();
}

Conclusion:

In the article, I have explained the basic structure of the App Lifecycle in a flutter; you can modify this code according to your choice. This was a small introduction to App Life cycle On User Interaction from my side, and it’s working using Flutter.

I hope this blog will provide you with sufficient information on Trying up the App Lifecycle in your flutter projects. We will show you what the Lifecycle of the Flutter App is?. In this blog, we have examined the lifecycle of the flutter app. I hope this blog will help you in the comprehension of the Lifecycle in a superior way. So please try it.

❤ ❤ Thanks for reading this article ❤❤

If I got something wrong? Let me know in the comments. I would love to improve.

Clap 👏 If this article helps you.

---

Feel free to connect with us:
And read more articles from FlutterDevs.com.

FlutterDevs team of Flutter developers to build high-quality and functionally-rich apps. Hire a flutter developer for your cross-platform Flutter mobile app project on an hourly or full-time basis as per your requirement! You can connect with us on Facebook, GitHub, Twitter, and LinkedIn for any flutter-related queries.

We welcome feedback and hope that you share what you’re working on using #FlutterDevs. We truly enjoy seeing how you use Flutter to build beautiful, interactive web experiences.

---