Flutter is Google's SDK for crafting beautiful, fast user experiences for mobile, web, and desktop from

a single
codebase. Flutter works with existing code, is used by developers and organizations around the world, and is
free and open source.
This API reference covers all libraries that are exported by the Flutter SDK.
Framework Libraries
Libraries in the "Libraries" section below (or in the left navigation) are part of the core Flutter framework and
are imported
import 'package:flutter/material.dart';
import 'package:flutter/services.dart';
Supporting Libraries
Libraries in other sections are supporting libraries that ship with Flutter. They are organized by package and are
imported
import 'package:flutter_test/flutter_test.dart';
import 'package:file/local.dart';
The Flutter animation system.
To use, import package:flutter/animation.dart.
Flutter widgets implementing Material Design.
To use, import package:flutter/material.dart.
The Flutter rendering tree.
To use, import package:flutter/rendering.dart.
The Flutter widgets framework.
To use, import package:flutter/widgets.dart.

StatelessWidget class(abstract)
A widget that does not require mutable state. A stateless widget is a widget that describes part of the user
interface by building a constellation of other widgets that describe the user interface more concretely. The
building process continues recursively until the description of the user interface is fully concrete (e.g., consists
entirely of RenderObjectWidgets, which describe concrete RenderObjects).
Stateful widgets

A widget that has mutable state. State is information that (1) can be read synchronously when the widget is built
and (2) might change during the lifetime of the widget. It is the responsibility of the widget implementer to
ensure that the State is promptly notified when such state changes, using State.setState.
Inherited widgets.

When your app starts to grow and your widget tree gets more tangled, passing and grabbing data can be a pain.
Imagine having 4 or 5 widgets stacked on top of each other and you need to pass some data from the top to the
bottom. You end up adding it to all those constructors and built methods.
so you got to like reach up the tree to grab that data, right? Luckily, there's this dope widget type called
inherited widget that lets you do just that. When you slap that switch in your tree, you can snag a reference to it
from any widget below it. It's basically like a family tree - I got my big nose from both my pops and my
grandpa because they're both above me in the family tree. So, I can inherit from them. Just to clarify, this aren’t
like inheriting in a class hierarchy, it's more like inheriting in a personal way.

so basically, we're going to talk about this thing called 'widget hierarchy'. Let's figure out how we can make one
of those widgets that inherit stuff. So, we make a class called 'InheritedNose' that extends 'InheritedWidget'. We
got to make sure our widget can take at least one parameter, which is the 'child'.

Technically, this is already a valid inherited widget, but it's pretty useless. So, let's spice it up a bit by adding a
nose. In this case, the nose will just be an image of a nose that we'll add as a field to the InheritedNose widget.
Now, any widget that's a descendant of InheritedNose can access this nose in its 'built' method by using the
'context'." you can grab your custom widget by hittin' up this method with the type of your inherited widget. It
tells the code to search up the tree from the build context for a widget that matches that type.
But to keep things easy, inherited widgets usually have a static method called 'off' that does the work for you.

So now, we can update our code in the child widget to access inherited data from the context.
know how to get the global theme of a material app? You got to use the theme.of(context).theme, which is
actually an inherited widget. So, things like scaffold, focus, scope, and others are all part of that. The thing
about inherited widgets is that they can't be changed, that's why our image asset is set as final. You can only
switch out an inherited widget by rebuilding the whole thing. Just remember, a lot of inherited widgets will stay
the same throughout the whole lifecycle."

so like, having an app is cool and all, but just cause something is final doesn't mean it can't change internally.
Like, instead of just a value, you can hook up a service object to the inherited widget. It can be like a cover for
your database, a middleman for your web api, or a source for assets. This service object can have its own little
world inside, it can make network calls, do whatever. In our situation, each descendant of the inherited widget
will have access to different services.

so, this widget thing can hook you up with the service by using the inherited knows dot off context. You can
call methods on it, subscribe to streams, and all that good stuff.
Basically, inherited widget is super cool because it lets you access state from way up high in the tree.

Summary

Inherited widgets in Flutter allow for efficient data propagation up and down the widget tree.

Highlights

 Inherited widgets provide a way to pass data down the widget tree effortlessly. 🔗

 They function similarly to a family tree, allowing for easy inheritance of data. 🌳

 Inherited widgets are accessed using the ‘off’ method from the context. 🔄

 They are immutable and require rebuilding to update. 🧱

 Service objects can be attached to inherited widgets for dynamic data handling.

 Inherited widgets are essential for accessing global themes and services in Flutter. 🌐

 They streamline data access and management in complex widget hierarchies. 🚀

Key Insights

 Inherited widgets simplify data passing in Flutter by providing a centralized location for shared data. 🔄

 The ‘off’ method is a convenient way to access inherited data from descendant widgets. 🎯

 Immutability of inherited widgets ensures data consistency throughout the widget tree. 🧱

 Service objects attached to inherited widgets offer dynamic functionality for handling data & services.

 Understanding inherited widgets is crucial for efficient and organized Flutter app development. 🌟

 Utilizing inherited widgets for global themes and services enhances app consistency and scalability. 🌐

 Inherited widgets play a crucial role in managing state and data flow in complex Flutter applications. 🚀

Keys
When widgets move around in the widget tree, keys keep track of their state. They can be used to save a user's
scroll position or maintain state when modifying a collection. It also discusses different key types like
ValueKey, ObjectKey, UniqueKey, PageStorageKey, and GlobalKey, and their appropriate use cases.
The video introduces the topic of using the key parameter on widgets in Flutter. It mentions that keys preserve
state when widgets move around in the widget tree and can be used to maintain scroll location or state when
modifying collections of widgets.

When to Use Keys

So, when do you need to use keys? Most of the time, you don't really need them. But when you find yourself
needing to add, remove, or reorder a collection of widgets of the same type that are in some kind of state, that's
when it's key time. An example is a to-do list app. When using the app, you want to reorder widgets based on
priority in the to-do list and then remove them once they're done. To illustrate why you need keys in this
scenario, I've written a very simple app that has two widgets with random colors that can swap positions when
you click a button. So, there's this thing called PositionedTiles, which is like a widget that has some state. It
puts two stateless slices together in a row. When I click the "Float Action" button at the bottom, it swaps the
positions in the list as expected. But what happens if we make these colored slices stateful instead of stateless,
and store the colors in the state? Now, when I press the button, it looks like nothing changes. But if I add a key
to each slice widget, the widgets will swap positions as you'd expect. But remember, if the whole widget subtree
in the collection is stateless, you don't need keys. Actually, that's all you need to know about using keys in most
simple cases in your app.

How Keys Work Under the Hood

Now that everyone’s gone, we can dive into how keys work when Flutter renders these widgets. In the stateless
widget version, the row widget provides a set of ordered slots for its child widgets. As you saw in the earlier
episodes of this series, for each widget, Flutter builds a corresponding element. This element tree is very simple,
just storing information about each widget type and a reference to its child elements. You can think of the
element tree as the skeleton of your Flutter app. It shows the structure of your app, but you can find all other
information by referencing the original widgets.

When we swap around the slices in our rows, Flutter goes through the element tree to see if the skeleton
structure is the same. It starts with the row element, then moves to its child elements. The element tree checks if
the new widget matches the type and key of the old widget. If it does, it updates the reference to the new
widget. In this case, the widget doesn't have a key, so Flutter only checks its type. It's the same for the second
child as well. Now, let's look at the same scenario again, but this time with stateful slice widgets. You can see I
have the same widgets and elements as before, but now there's also a pair of state objects. And the color
information is stored there, not in the widget itself. So this time, when I swap the order of the two widgets,
Flutter traverses the element tree, checks the type of the row widget, and updates the reference. Then, the slice
element checks if the corresponding widget is the same type - a slice widget - and it is. The same goes for the
second child. Flutter uses the element tree and its corresponding state to determine what actually gets displayed
on your device. So from our perspective, it looks like your widgets didn't swap correctly. In the second version,
using stateful slices, I added a key attribute to the widgets. Now, if we swap the widgets, the row widget
matches as before, but the key of the slice element is different.

"The keys for the corresponding sliced widgets don't match. So, Flutter will disable these elements, moving the
reference to the sliced elements in the element tree, starting from the first mismatched element. Then, Flutter
looks at the mismatched children to find elements with the corresponding keys. It finds a match and updates its
reference to the corresponding widget. Then, Flutter does the same thing for the second child. Now, Flutter will
display the content we expect, with widgets swapping positions and updating their colors. So, in conclusion, if
you want to change the order or quantity of binding widgets in a collection, keys are very useful. For illustration
purposes, I stored colors as state in this example. However, states are often more subtle. Playing animations,
displaying user input data, and scrolling positions all involve state. So, you have a scenario where you need a
key for your application.
Where to Place Keys
Where do you put it? The answer is to specify a key that needs to be preserved at the top of the widget subtree.
Since we have been talking about states all along, you might think it's the first stateful widget. But you're
wrong. To tell you why, I wrapped my colored tile widget with a padding widget, but I left the key on the tile.
When I click the button, the slices turn into completely different random colors. What's going on? This is the
look of the widget tree and element tree with the added padding widget. When we swap the positions of the
children,..."

So, basically, Flutter's element-to-widget matching algorithm looks at one level of the tree at a time. I've grayed
out the children's children in the diagram so we can focus on one level at a time. At the first level of children,
everything matches up correctly. But at the second level, Flutter notices that the keys of the sliced elements
don't match the keys of the widgets. So, it disables those sliced elements and removes those connections.

The keys we're using in this example are local keys. This means that when Flutter is matching widgets to
elements, it only looks for keys that match at a specific level in the tree. Since it can't find a sliced element with
that key value at that level, it creates a new one and initializes a new state. In this case, it turns the widget
orange. Another sliced element runs into the same issue.

If you add keys at the level of filling the widgets, Flutter will notice the issue and update the connections
correctly, just like in the previous example. Order is restored in the universe. So now you know when to use
keys and where to place them.

But if you look at the Flutter documentation, you'll see there are several different types of keys. So, which one
should you use? In scenarios where you're modifying a collection of widgets, like swapping out colored
example slices, you only need to differentiate the keys of the other children. Look at the information stored in
those child widgets to help you understand which widget to use.

In a to-do list app, we might want the text of the to-do items to be constant and unique. If that's the case, it could
be a good candidate for a value key, with the text being the value.
Now, let's say instead, each widget stores a more complex combination of data. Maybe you have an address
book app that lists information for each user. Any single field, like a name or birthday, could be the same as
another entry, but the combination is unique.

In this case, an object key might be more appropriate. If there are multiple widgets with the same value in a set,
or if you want to ensure each widget is different from the others, you can use a UniqueKey.

I used a UniqueKey in the example app because we don't have any other constant data stored on our slices, and
we don't know what color the widget will be before building it. But one thing you don't want to use is a random
number in the key. Generating a new random number each time you build a widget will result in inconsistency
between frames. So you might as well not use a key at all. Page storage keys are used to store a private key for
the user's scroll position, so the app can retain it for later use. Global keys serve two purposes. They allow
widgets to change parents in any part of the app without losing state, or they can be used to access information
about another widget in a completely different part of the widget tree.

So, like, the first situation could be when you wanna display the same widget on two different screens, but you
want to keep all the same states. You wanna use a global key for that. In the second situation, maybe you wanna
check a password, but you don't want to share that state info with other widgets in the tree. But, like, usually,
global keys are kinda like global variables. There's usually a better way to keep the state using inherited widgets
or something like redux or bloc pattern. So, like, bottom line, when you wanna keep the state across widget
trees, use keys. This usually happens when you're modifying a collection of the same type of widgets, like in a
list. Put the key at the top of the widget tree you wanna keep the state in, then choose the type of key based on
the data you're storing in that widget.