♪ [music] ♪
When I was starting out in Flutter,
a scenario that always gave me trouble was juggling my layout
when the device's keyboard was visible--
which, unless I was careful,
would obscure half of my app's UI.
A common situation might involve me filling the whole screen with a stack,
giving a hero image the top 50%,
a text input the bottom 10%,
and maybe a scrollable list of comments
that remaining 40%.
Stacks are powerful,
so before long, my UI would be looking good,
and I'd be excited to start testing it out.
I'd tap on that text input,
and suddenly the keyboard appears and covers half the screen,
including the very text input it's supposed to power.
This is not what I wanted.
If you've been around the Flutter block a few times,
you've probably seen a device's virtual keyboard
cover half of your UI.
Understanding everything at play
requires getting cozy with the MediaQuery class.
So let's do it.
First of all, just like many classes in Flutter,
the value you get back from
is actually a
This is similar to how
returns a
And within that
which is flush with useful information,
are three attributes of particular interest for our quest.
They are
These variables are well-named and easy to keep straight.
Just kidding!
They're impossible to keep straight,
which is why we're talking about them.
The first line of documentation for
"The parts of the display that are completely obscured by system UI,
typically by the device's keyboard."
Okay, that's pretty straightforward.
In my head, I distinguish this from the other two
by thinking about how you have to press keys
viewInsets
For
"The parts of the display that are partially obscured by system UI,
typically by the hardware display 'notches'
or the system status bar."
Okay.
And lastly, the documentation for
"The parts of the display that are partially obscured by system UI,
typically by the hardware display 'notches'
or the system status bar"...
which sounds familiar.
So what's the difference between
Well, not much,
unless the device's keyboard is showing.
Then things get interesting.
You see,
that the operating system is holding on to
for its own devious purposes.
An example is the bottom of an iOS device,
which reserves a small area
to detect swipes that raise the system tray.
But what happens to those pixels when the keyboard is up?
They're no longer reserved for this purpose.
They're doing keyboard things now.
And so, when the keyboard is raised,
the value for
and drops to zero.
This makes sense.
But if you've used
then the keyboard's arrival will shift your UI down several pixels
toward the keyboard.
Also, not where you want.
So, what's a developer to do if they want consistent positioning
regardless of what shenanigans the keyboard is getting up to?
That's
The difference between
is that if a keyboard comes along
and tramples all over the edge of your device,
viewPadding
And what about
Well, if you wrap everything in a
then most of these numbers stay pinned to zero.
That's the job of the
Except
and
only when the keyboard is showing.
To review,
basically, the keyboard.
Padding
basically, notches.
And what about when a keyboard consumes the space behind a notch?
padding
but
If you find any of this hard to remember,
you're in good company--
at least, if you consider me good company.
While preparing for this video,
I had to relook up the difference between the three attributes
at least ten times,
which is why I made the DartPad linked below.
Check out that to see it all happening live,
right before your very eyes.
And whenever you forget which one is which,
pop back over to that DartPad.
For more info on Flutter,
head to
♪ [music] ♪