♪ [intro music] ♪ Alright. So you need to build an app, and you've heard about this Flutter thing
and made your way here. Maybe you have some wireframes
or some sketches of what you want your app to look like, or you're just getting started. Regardless of what
brought you here, welcome. Hi, I'm Fitz, and I'm going to be helping
you through the process of building apps in Flutter. Even though you're here
and on the other side of the screen, I can still hear you saying, "Okay, so I know Flutter is a thing
you can use to build apps, but what is it exactly?" Thank you for asking. That's a great place to start. Flutter's a tool kit for building apps. Like a real life toolkit has many
of the fundamental things you need to construct something. Screwdrivers, hammers, drills,
and on up through more specialized tools are all part of a standard toolkit. And if you're building a house,
you probably wouldn't start by building your own
screwdriver or hammer. Similarly, Flutter provides many
of those foundational things for you. We call them widgets. In Flutter, it's said
that everything is a widget. And these so called widgets
are the building blocks for any Flutter app. There are title bars, columns,
list of other widgets, buttons, icons, text input boxes,
and even the Flutter logo itself. Everything is a widget to the point
where most of them themselves are made up of other widgets--
even your app itself. So let's consider an analogy. Suppose you wanted to write a book. After sketching out the story arc,
the characters and their relationships, the setting-- you start to write. But you don't just write a book. You consider which words to use,
how they fit into sentences, how those fit into paragraphs or sections, and how they're composed
together to form chapters, which together form the book. And thus you end up
with a hierarchy of components. A book is composed of chapters,
chapters are composed of paragraphs, paragraphs of sentences,
sentences of words, words of letters and punctuation, all the way down to pixels
or dried up drops of ink smoothed together to form
the syllables we see on the page. But this exact pattern
isn't strictly required. A chapter doesn't just have paragraphs. It might, for example, start with a quote, which is really just a stylized sentence. And there are lots of different
presentations of a sentence. One character might speak
exclusively in all caps. The title of a book someone picked up
might be in italics. Or a song might be presented
as short sentences arranged like a poem
instead of a paragraph. Flutter's widgets are much the same. You can combine and customize
these common building blocks in new and interesting ways
to form your own unique app. Take the <i>AppBar</i> widget as an example, which is the header bar for many apps. It is composed of other widgets. It delegates the responsibility
of handling text to the <i>Text</i> widget, or button icons to the <i>IconButton</i> widget. In this way, just like
the various parts of a book, we end up building a hierarchy of widgets. As we go down the hierarchy
we get more specialized. The <i>AppBar</i>'s title is the <i>Text</i> widget, which in turn is composed of widgets specializing in different aspects
of handling text. All the way down to the handling
of dropping pixels of ink onto the screen. And if we went the other direction
up the hierarchy, widgets get more abstract
and more complex. An <i>AppBar</i> is typically within a <i>Scaffold</i>, which is itself some kind of app
like a <i>MaterialApp</i>, which in this case,
provides the basis for an app following the material design system. By putting widgets together
in different arrangements, we can do all kinds of different apps,
from simple to-do-list apps, to complex multimedia
and project management apps. Or really just about anything
you can imagine. So with that in mind,
let's go to actually building an app. How about... How about a space exploration
planning app? And all of these good space exploration
planning apps out there really have two things. All the different ones that I've seen
have these two things. A progress indicator--
telling us how close we are to exploring the entire universe-- and a checklist of things
remaining to discover. And so your first step
is really to sketch out what this app could look like. And as you do that, you might start
to see some common elements. <i>Text</i> for the labels,<i>
Checkboxes</i> for the to-do-list, an <i>AppBar</i> for the title of the app up top, and there are existing widgets
for all of these things, and so all you have to do
is throw them together into an app, right? But where in the app? And how does a widget know
where it needs to be on the screen? Remember that widgets exist
in a hierarchy of relationships to other widgets. They have parents, children,
siblings, niblings, grand niblings-- and so when you're looking
at an app sketch trying to figure out
which widgets your app will need, also think about
the relationships between them. If you look at the sketch again,
and consider the meaning of each section, you might start to see some groups. As the most generic, of course,
is the entirety of the app. And the <i>AppBar</i> is kind of
its own distinct thing at the top, with the title, and just kind of
a distinct section from the main part of the app,
which seems, itself, to have a section near the top
that indicates our progress, and the list of things to do
underneath it. Which itself is made of to-do items. And each of these groups need
to be arranged or laid out in a different way. The app at the very top follows
a similar structure as most apps. But we have a list of widgets
or widgets that are vertically oriented or widgets that are laid out horizontally,
like the to-do items. And so when widgets
are composed together to make apps, not all of them are things,
like buttons, icons, or text. When we say that everything is a widget,
it also applies to layout. As in where and how
things appear on the screen in relationship to other widgets. For example, there's a widget
responsible for arranging other widgets one after another from top to bottom. It happens to be called <i>Column</i>, and its responsibility
is to take its children and put them in a vertical layout. Back on the sketch of this app, you could then start to add in
some of the layout widgets too, like to say that the progress section
could actually be a column composed of a <i>Text</i>
and a <i>ProgressIndicator</i>. Or that a to-do item is in a row. And knowing which one
of these widgets to use gets easier with practice,
but let's start with what we know so far. All Flutter apps are written
in the Dart programming language. If you don't know Dart, don't worry. Most of what we write at first
is just mixing widgets together in different ways, and we'll slowly add in
new Dart features as we go. Like in many programming languages,
the main source file for a Flutter app starts with two things. A list of things the app depends on,
and the <i>main</i> function. The material part of the framework
gives you just about everything you need to start off with. For this introductory app, the only thing we'll need
to import is that library. And as the starting point for the app, <i>main</i> just needs to do one thing. It needs to run the app. <i>runApp</i> is a method
from the Flutter framework and takes whatever widget you give it
and puts it at the very top of that app's hierarchy of widgets. It's what we'll call the <i>root</i>
of the widget tree. From there, we could just put
our entire app into <i>runApp</i> and build our way down the widget tree. But something feels
kind of off about this. It's nice to have everything in one place, but it's generally considered
good code quality to break things up and encapsulate different ideas
or functionality into different things. This relates to a concept
in software engineering called <i>separation of concerns</i>, where every component in a system is responsible for its own
little part of the world and nothing else. Fortunately, Flutter has a construct for what one of these
little things can be-- a widget. And you can create your own
by creating a new class extending from <i>StatelessWidget</i>. And we'll get to what that stateless part
means in the next video. Every widget needs to have
one method in it. The <i>build</i> method describes
how to build this widget as described in terms of other widgets. Notice how <i>build's</i>
return type is a widget. From there, we can build up our app
using progressively smaller widgets, which we identified
from the sketch earlier. Many apps start off
with a MaterialApp on top, and then split out the homepage
as a separate widget. This is a great point to run the app
and see what it looks like. And of course, there
is nothing in the code to say that this is any more than an app,
so there's nothing there. So we can add in a <i>Scaffold</i>, a widget which provides some
of the common app patterns. Throw in an <i>appBar</i> and the page title
and start to construct the body. For the most part, all the widgets
I talked about earlier just kind of fall in line. The whole body is a <i>Column</i>
and the two subgroups we defined. First, the <i>Progress</i> section. This custom widget is similarly defined. <i>Progress</i> is just a text label,
and because I like lines, a <i>LinearProgressIndicator</i> underneath it. The <i>TaskList</i> has a couple
more layers to it. And right now, I'll define it as a <i>Column</i>
whose children are <i>TaskItems</i>. And in order to maximize
the reusability of this widget, I'll have it take in
a parameter for its label, and then it itself would just be a <i>Row</i>
with a <i>Checkbox</i> and the <i>Text</i> that we discussed earlier. And there you have it. It's not much, but it's a solid start
to your first app in Flutter. Before we part ways, you may have noticed
in the last couple of minutes that I only clicked
on the run button once. Yet the app magically updated
as we added things. There's no cinema magic
or sleight of hand here. This is all due to a feature
called <i>hot reload</i>, which picks up many
different kinds of code changes and updates the running app
with the new code. We'll dive a bit into this
in the next video. Until then, we covered a lot in this one. What Flutter is, how you can build apps
by combining widgets in different ways, and how it all comes
together in real code. But I also left some unanswered questions. What is the "state" in a <i>stateless</i> widget? Why is the checkbox
not checking when I tap it? And how can we make this app
actually look good? Check out the description below
for additional readings that go into more depth on some
of the things covered in this video, and then I'll see you in the next one
to start tackling some of those questions. ♪ [outro music] ♪
Good introduction. I'm curious about Flutter, and this video makes you feel closer to the matter indeed. Hey, an interesting thing I read about Flutter was that it also works for websites, something related to a large canvas. How is that?.