IAN LAKE: So there I was, building a great responsive UI,
when it hit me.
Multi-Window is going to change everything.
Well, OK.
Maybe not everything.
But there are some special considerations
when it comes to building and designing
for Split-Screen Multi-Window.
Now, one thing that hasn't changed
is the importance of a responsive UI.
A responsive UI is one that's able to adapt to the space
available.
So some of the same techniques you've used before just
become even more important when users can resize your app.
Check out our other video on the basics of building a responsive
UI and the patterns you can use to adapt your layout to changes
in size.
Thankfully, building a responsive app
for your existing users covers almost all
of the configurations you'll see in Split-Screen Multi-Window.
But there are two relatively unique configurations
you might consider when designing your app.
First is the 16 by 9 layout on mobile devices in portrait.
Here it's important to keep in mind the heavily constrained
vertical space.
Make sure users can actually see some content
between fixed navigation elements, like an expanded app
bar, and bottom navbar.
The others is the 34.15% layout on tablets.
Here you have an extremely wide aspect ratio
on portrait devices.
A technique we've found useful is
to start with your mobile device layouts
and stretch them to fit this new configuration.
Once you have a fully responsive UI,
now comes the fun part, taking advantage of Multi-Window.
By default, Multi-Window is enabled.
And it's enabled for your entire task stack.
That means if your root activity supports Multi-Window,
every activity started from that root activity also
needs to support Multi-Window.
This also applies to any exported activities you have.
They'll inherit the Multi-Window capabilities of the other app
and therefore should always support Multi-Window.
Now, when in Multi-Window mode, the minimal size
is 220 by 220 dp.
You can use minheight and minwidth
to set a larger minimum size, but in Split-Screen
Multi-Window, users can still resize you smaller.
You'll just get cropped off.
And no one likes an inaccessible button.
So try removing as much as possible
to get down to that minimum size.
Now, beyond the first priority of,
does my app run in Multi-Window mode,
it should come as no surprise that the best experience
here for users is the fast, smooth transition
from the biggest screen sizes, down to the smallest,
and vice versa.
If your tablet or mobile layouts are very similar,
you may find this to already be the case.
The important thing to remember is
you don't want the user to feel lost when they resize your app.
If your layouts are vastly different,
don't change between them.
Instead, try scaling your tablet UI down
to fit the smaller space.
That way your app will be consistent on all sizes.
Keep in mind that just like any other configuration change,
the default behavior is to kill and recreate your activity when
it's resized, reloading all of your resources for you.
Assuming you save your state using onSaveInstanceState
and use loaders or other techniques
to keep data across configuration changes,
this should be really fast.
However, if you want to take total control
and reload only the exact things you need,
you can handle configuration changes yourself
by adding the configChanges attribute to your activity
and then applying the changes in onConfigurationChanged.
Not for the faint of heart though.
Test thoroughly.
Now, if you're a fully immersive experience like a game,
I get it.
Maybe you want to disable Multi-Window.
If you aren't targeting API 24, adding Android orientation
or Android immersive to your manifest
will disable Multi-Window.
And, of course, the new resizableactivity attribute
can be added to your application or to your root activity
to opt out of Multi-Window.
Check out the blog post linked in the description
for all the details, and some other patterns,
like relying on edge swipes, that should be avoided
to best support Multi-Window.
Build a great responsive UI.
Build a great Multi-Window experience.
But most importantly, just continue to build better apps.
[MUSIC PLAYING]