1 Flutter lifecycle
When a Widget starts, it
runs the initStateO and build() methods respectively. Then the did UpdateConfig
and setState methods work according to the interaction with the user. When the
last application is
closed, the dispose() method works.
1) createState):
When Flutter is
instructed to build a StatefulWidget, it immediately calls createState(). This
method must exist. A StatefulWidget rarely needs to be more complicated than
this.
class MyHomePage extends
StatefulWidget {
@Override
MyHomePageState
createState() =>new _MyHomePageState(); }
2) mounted() true: When createState creates the state class, a buildContext is assigned to that state. All widgets have a bool this.mounted property. It is turns true when the buildContext is assigned. It is an error to call setState when a widget is unmounted.
This property is useful when a . method on your state calls setState but it is not clear when or how often that method will be called. Perhaps its being called in response to a stream updating. You can use if (mounted) {... to make sure the State exists before calling setState.
3) initState): initState) (mustsuper initState)
This is the first method called when the widget is created (after the class constructor, of course.) It represents the time elapsed before the application is up and the user meets the interface.
initState is called once and only once. It must also call superinitState). This @override method is the best time to:
1) Initialize data that relies on the specific Build Context for the created instance of the widget.
2) Initialize properties
that rely on this widgets parent in the tree.
3) Subscribe to
Streams, Change Notifiers, or any other object that could change the
data on this widget.
4) The framework will call this method exactly once for each State object it creates. Override this method to perform initialization of objects that are relevant to State of the given Widget in Widget tree..
5) build0 This method is called often (think fps + render). It is a required, @Override and must return a Widget.
6) didUpdateWidget(Widget oldWidget): didUpdateWidget() is called if the parent widget changes and has to rebuild this widget (because it needs to give it different data), but it is being rebuilt with the same runtimeType, then this method is called. This is because Flutter is reusing the state, which is long lived. In this case, required is to initialize some data again, as one would in initState If the state of build) method relies on a Stream or other object that can change, unsubscribe from the old object and re-subscribe to the new instance in didUpdateWidget().
This method is basically
the replacement for initState if it is expected the widget associated
with
the widgets state need
to be rebuilt!
7) didChangeDependencies: The didChange Dependencies method is called immediately after initState on the first time the widget is built. It will also be called whenever an object that this widget depends on data from is called. For example, if it relies on an InheritedWidget, which
updates. build is always
called after didChange Dependencies is called, so this is rarely
needed. However, this method is the first change you have to
call BuildContext.inherit From Widget Of act Type. This essentially would make this
State listen to changes on a Widget it is inheriting data from The
docs also suggest that it could be useful if you need to do network calls
(or any other expensive
action) when an InheritedWidget updates. When this section changes
location, when the application is taken down, when the next page is
changed, etc. in cases where we will be done The following example
covers the cases followed when the application is taken.
The didChangeAppLifecycleState method was used for this.
This method can be called an observer before we can
use widgetsbindingobserv is to add to our class as follows, initstate
we start listening in method.
class Lifecycle Watcher State extends State< Lifecycle Watcher>
with
WidgetsBindingObserver
Widget Build ... in
@Override void
initState
Super.initState 0);
Widgets Binding
instance.
addObserver (this); } //
initState }
8) setState : Notify the widget that the State of objects changes in setState callback. It is used to notify the framework that data has changed, and the widget at this build context should be rebuilt. setState takes a callback which cannot be async.
State method actually allows the rendering engine to re-run. We have defined a Button and Text. And every time the button is pressed, we want the number in the Text to increase.
Lets explain this by
dividing it into 2 We can increase the number without using setState,
but we can not see it on the screen. Because the screen is not
updated. Using setState, we can
see the number on the
screen as we can increase the number. Because here the rendering
engine runs again and the screen is updated.
void _arttir () { setState (() {counter ++;});}
9) deactivate(): The framework calls this method whenever it removes this State object from the tree, but it might be reinserted before the current frame change is finished. This method exists basically because State objects can be moved from one point in a tree to another.
10) dispose: Called when object is removed from widget tree that never build again
@Override void dispose()
(super.dispose (); }
11) mounted is false : The state object can never remount, and an error is thrown is setState() is called.)
2 What is the pubspec yaml! file and what does it do?
Manage all assets, third
party libraries
The Pubspec.yaml allows you to define the packages your app relies on, declare your assets like images, audio, video, etc. It also allows you to set constraints for your app. For Android developers, this is roughly similar to a build.gradle file, but the differences between the two are also evident.
3 Route
The application of top-level routing table.
When a named route is pushed with I Navigator.pushNamed], the route name is looked up in this map. Of the name is present, the associated WidgetBuilder is used to construct a MaterialPageRoute that performs an appropriate transition, including Hero
animations, to the new
route.
4 Dart VM
During development, your
Flutter app runs in the Dart VM. When you invoke hot reload, the
updated source code files are injected into the Dart VM.
After this finishes, Flutter rebuilds the widget tree. This makes hot reload and some other features possible.
5 AOT
This means that the Dart
code is compiled into machine code and uses a stripped version of the
Dart VM which is incapable of loading source code dynamically, but it
is much faster. This mode is used on production builds for
maximum performance.
This way we get the best of the two worlds. We get nice development features while we work on our app. And we get the best performance in the deployed app.
The dart VM supports building of native ARM code for the platforms you are developing for.
6 JIT
Dart also offers Just In
Time compilation. Flutter leverages this ability in development to
make for faster development cycles. Features like hot reloads are
help you to quickly and easily experiment, build Uls, add features
and fix bugs.
