[MUSIC PLAYING]
DANIEL JACOBSON: Hi, everyone.
My name is Daniel Jacobson, and I'm
a product manager on the Android developer team specifically
focused on the developer experiences for large screens
and foldables.
CLARA BAYARRI: I'm Clara Bayarri, engineering manager.
I run most of the UI teams.
DANIEL JACOBSON: Before we get into this talk today,
first why don't we take a look at why you should
care about large screens.
Right now, there are more than a quarter
billion active large screen devices
running Android, meaning there's hundreds of millions of reasons
for you to improve your application experiences
to delight your users.
And when we talk about large screens,
we're specifically referring to tablets,
desktop-class devices like Chromebooks,
and large, foldable devices.
And one of the things that I'm really
excited about in this talk especially
is that many of the tips and tricks that we're
going to share that you should be able to use today
are actually learnings from when we did the work ourselves
in many of our first party applications.
We've made a lot of mistakes along the way.
We've learned from them.
We've updated our guidance.
And we want to share that with you
so that you can jump ahead and accelerate your development
and not make the same mistakes.
Additionally, if you're looking for inspiration
within your own applications, try out your favorite Google
app, see some of the things that we
have done to improve our experiences on these devices,
and you can kind of learn from that
and take that into your own application.
CLARA BAYARRI: But before we go into some practical dos
and don'ts, we thought we'd talk about design and quality
so that we set the stage for what we're trying to achieve
when we say we support large screens.
When an app does nothing to support large screen devices,
it may end up looking something like this.
And it basically means this UI has
done no effort to, for example, think of layouts.
We see a lot of the large screen support--
there's many aspects to it, but a huge part of it
comes down to UI and layouts and how your app
looks on a larger screen.
For that, we heard loud and clear
from both developers and designers
if you needed more guidance.
There's a lot more real estate to fill, for example,
when your app is running on a tablet or a desktop device.
So "how do you fill that space" is a hard question.
And so we've been working really hard on giving you
a lot of guidance.
And so the Material Design website
has a bunch of new information around adaptive design
and what are the different things
that you can think about to really
not just blow up your app, but use that space smartly.
One of the areas I really want to point out
because it's going to be really important is canonical layouts.
And we call canonical layouts an exercise
that we did of looking at apps that
support large screen in the wild,
and look at could we distill it into typical app structures
that we could then recommend back, right.
So what are the typical structures
that apps are actually using that really work and help you
place the information into the screen in a way that
makes sense?
For example, if you have your content
in more of a parent-child sort of relationship,
so say you have a list of emails, and then an open email,
that kind of relationship is very well described
by what we call a list detail layout where
when there's enough space, you could place these side-by-side,
and you convey the hierarchy of your information.
But also it allows us to say, well,
when there's less space we probably only show the detail,
right.
So this is one structure to think about and think
of that kind of hierarchical relationship
between your content.
If instead your content has more of a main content
and supporting content sort of relationship,
then you can use a supporting panel, and think,
for example, YouTube does this.
You have the main player, and that's
a really important piece.
But maybe you have playlists and other things.
And these are supporting content that when the space gets
more reduced, you may want to a deprioritize,
either hide or move somewhere else.
And then supporting panel helps you think of that.
How do we keep space for a main content
but still have supporting content that exists?
And finally, the third layout that we really came to
was feed.
And this comes out when you have different items
in your content, but they're all kind of siblings.
They're all similar things.
Sure, one may be something you want
to represent a bit bigger than the other,
but they're siblings.
They're all part of the same information hierarchy.
In that case, you end up with a feed, and think of a news app,
right.
You have different articles, and you want
to show them all on the screen.
And so you would end up using these kind of grid layouts
that really allow you to say, well, little space,
I'm going to do one column.
But if there's more space, we can show them side-by-side
and use more smart use of space.
Because we know there's a lot of developers in the room,
we've got to say, we did just announce
a new guide on developer.android.com that
goes into the three layouts I just mentioned
and then how to implement them, both views and compose.
So hopefully we're giving you a lot of pointers of,
if this makes sense and if this inspires you
on how to fill in the screen, well, here's
how you action on that and how you actually implement it.
OK.
So I've talked a lot about design,
but then I sat able to talk about quality.
All right.
And how does this relate to quality?
We've published what we call the large screen app quality
guidelines, and these are a set of tiers
that we define that helps us reason, how
does an apps support large screen, what is their support,
and what are the next steps to better support large screens.
So we defined three tiers, which you can find in the page, which
really help us talk about basic, better, and best,
is the nicknames we've given them,
of the different levels of support.
And I'll go quickly into these.
But before we get to those three tiers,
there's a sad place that goes before them, which
is large screen restricted.
And that's when an app does no kind of support at all.
We end up in this place where as a system,
we don't know what to do with the app.
We're not sure we can stretch you
to fill in the entire screen because we're not
sure you're going to actually be able to behave correctly.
And so we have to put a lot of apps
into this compatibility mode that we call restricted,
and this is a really, really sad place.
It's not a great user experience.
It's not a great experience for you
as a developer to know that your users are using this.
Play Store will warn users when installing an app on a larger
screen that this will happen.
And so hopefully no one in the room
has an app that will actually fall into this category.
But let me go through common things that
would put you into this category so that you're aware.
The very first one is, if you're declaring
your app is non-resizable, by definition we can't resize you,
right.
And so that's a clear signal to us of well,
we know you're not going to support this.
So you have to go into compatibility mode.
Please don't do that.
Another super common one is restricting the screen
orientation.
Apps that say they are portrait, well, it
turns out most tablets out there are used in landscape.
And so if you say that, surprise,
we have to put you in compatibility mode.
And then min and max aspect ratios.
Think as well, we're talking about desktops, Chromebooks,
the era of freeform Windows.
We want to be able to do all of that resizing.
If we can't be sure we can do that,
we'll end up in this state as well.
Those are the three more kind of layout-related ones,
but there's a couple more.
You want to think of app continuity
and how you store state.
For people who haven't seen a foldable device before,
it's very common to kind of start
using on the outside screen with a folded state.
Say you start filling in a form and halfway through,
you open your device to finish, if the app
loses all that state, that's a horrible user experience.
And so we want to really make sure you're avoiding that.
And you should be able to persist state
across changes in screen size.
And finally, we see quite a lot of camera compatibility issues,
and we'll go into those a bit later.
All of those things would put an app
into large screen restricted.
And we really, really want to avoid being in this place.
Hopefully that doesn't happen to any of you,
and so we can move on to the real three tiers.
And so as I said before, we nicknamed them basic, better,
and best.
Let me go quickly through them.
In basic, the main idea is your app does run on a large screen,
you do fill up all the screen space that you're given,
but it doesn't look nice.
It's usually we find a lot of blown up experiences.
And so we really want to avoid being in this state.
Use all of the guidance I mentioned earlier.
We have a bunch of layout guidance.
Think about the design so that you
can get into the happier place, which is tier two.
Tier two is what we consider apps
that are really thinking about large screen
and are making a good use of that space.
Maybe it's multi panel layouts, maybe
it's one of the canonical layouts I mentioned earlier.
And also you're starting to show some support
for, say, input devices.
This is the happy place.
This is where we would love to see
all apps reach because this is a good experience for the user.
It's not a huge amount of work, and it gets us
into that place where you really feel like you're
using the space smartly.
We do have a tier one, which is then
the differentiated tier, right, like hero experiences.
If you go above and beyond and say you support stylus,
you support folding devices can have postures,
maybe you do something special for that, keyboard shortcuts,
drag and drop.
All of these things where an app shows
that it goes above and beyond to support large screen,
well, that would put you into tier one.
And that is really kind of high-level hero experiences.
Which means we will also be probably encouraged
to feature those on the Play Store.
They will have higher rankings because users are more
interested in using these apps.
We do have a dedicated talk that goes much deeper in the tiers
because I've just kind of glanced through it.
So please check out the specific talk
on that if you want to know, or check back
the developer.android.com page I mentioned earlier
that has all of the detail.
CLARA BAYARRI: Cool.
With that, let's get into the practical tips
that hopefully you can take away and start
applying to your applications right away, starting
with reachability.
As Clara mentioned, most tablets or larger screen devices
are often used in landscape, and so the way
a user holds the device, interacts
with the device, interacts with the UI of your application,
is going to be different than on a typical phone device.
And that means some of the common placements of UI
elements may be more difficult to reach,
causing them to have to adjust their grip,
take their hand off, just to have less comfort
using the experience generally.
One example of this, and why we often
show the nav rail versus bottom nav bar example,
is thinking about the navigation of your application.
If we overlay the reachability chart,
you can see some of the more center-focused navigational
elements are pretty hard to reach, meaning that the user is
probably going to need to take their hand off or adjust
the way they're holding the device to actually reach
those elements.
And these are very commonly-used things.
Users are going to navigate around their app.
It's going to be something they're going to do frequently.
So when we recommend the nav rail,
we're doing so because, hey, generally
these are much more reachable.
If I do need to adjust my grip to reach the higher to reach
ones, I maybe need to move my hand slightly up
rather than completely taking it off
of the tablet to actually touch those navigational buttons.
And this provides generally a better experience.
While navigation is one example, you
should think about the most used UI elements in your application
and place them in the easy to reach areas.
Take a look at the next talk for more information
about just general large screen design principles
and philosophy so that you can design and build
a great UI experience for all devices and displays.
Just to summarize, don't make UI elements really difficult
to reach on these devices, and do intentionally
think about the design and placement of most-accessed UI
elements.
The next issue that we've seen a lot with applications
is exclusive hardware access.
Beginning in Android 12.0 and above,
all applications will run in multi-window mode.
And a lot of applications assume hey,
if I'm portrait only, if I'm unresizable,
I'm going to be the only application on the display
at any given time, meaning I don't have to worry about this.
That's no longer true.
And so this is an example of applications handling it OK.
You have two different camera applications.
When you tap on one, it requests access to the camera.
It actually uses it, and the other one gracefully
loses access to the camera without crashing.
Many of the issues we saw were application crashes.
So definitely make sure that you're
handling exclusive hardware resources gracefully.
The do here is check for access before actually using it.
Fail gracefully if you do randomly lose access to it.
Use Jetpack libraries if you can because we will obfuscate
much of this from you.
So we will do the work so you don't have to.
We know that doesn't solve all use cases, but if you can,
we recommend Jetpack.
And then last but not least, actually test this.
It can be so easily diagnosed using the resizable emulator
or the desktop emulators.
Place two applications side by side that are requesting access
to the same exclusive hardware resource
and see what happens when yours loses access, as an example.
Related to that but a little bit different
is thinking about activity lifecycle events
and how you handle them.
Again, this is about thoughtfulness and
intentionality.
A lot of what we saw, like--
here's the example.
I am watching a video app, and I want
to take notes on the video.
And maybe the video app on pause pauses all running content.
So every time I try to take a note, the video that I
was trying to watch to take notes on now pauses.
That's a very frustrating and annoying user experience.
In this example, we have the Photos app, which actually
intentionally chose to pause because they assume hey,
I'm watching my own photos, it would
be weird to pause my photo when using another app.
But when I browse through Chrome, it pauses the video.
Just think about these things.
Think about how you want your application experience
to behave when it's not the only application on the display.
Instead, what you should be doing is freeing up
any appropriate resources in onStop
and just thinking about the end-to-end experience
you want to provide when having multiple things on the display.
The next one is probably the one I experience most commonly
and the one I'm most passionate about.
And I was already having a conversation with somebody
here about this.
isTablet Boolean logic based off of arbitrarily
identified display metrics.
So what we're looking at here is a smallest width
qualified resource file where you have an isTablet Boolean
when the smallest dimension is 720 density-independent pixels.
I've seen everything from 600 to 720 to 800 to 840.
Like, people just pick arbitrary values.
If you research this on Stack Overflow,
there's some answer from 10 years ago with 800 upvotes.
It's not a great way to figure out
how to adapt your application experiences.
And I actually have a story from one of our first party apps.
We had this logic in one of our apps
that basically gated access to an experience
within an application to only phone devices.
And so on a foldable device, you could
enter into this application experience
on the outer display.
You could unfold the device, and that new display
registered as a tablet.
You could still use the experience
because you were already navigated to it,
but as soon as you left it you couldn't get back to it.
So you had to refold the device to get back
into that experience if you wanted to use it again.
It's just a terrible user experience.
It's because of this type of logic.
So please, please, please, avoid arbitrary isDevice type logic.
And I'll teach you on what to do instead.
So if you're thinking about UI and layout-related adaptivity,
use window size classes.
So these are our recommended break points.
They represent typical device usage patterns.
But they are device-agnostic, so if you're
running in multi-window mode, if you're
running in a freeform window, your UI and layouts
will still adapt appropriately without having
to think too much about this.
If it's not a UI-- or, sorry.
Before I jump into that, as previously mentioned as well
we now have a utility library called the Window Size Class
Library produced with the Compose Material 3
stable release that makes it super
easy to use this in Compose.
It's a single function call.
You get observable layout breakpoint states,
and you can adapt your layout as simple as that.
It's one of my favorite new libraries.
And if you're not thinking about UI and layout
and you're instead thinking about other things,
we've seen people use isTablet logic to date things related
to Telephony.
And it's like, hey like a tablet could actually
support those scenarios.
So why not?
So actually look for, what does my application experience
depend on in the device.
If that requirement or dependency is satisfied,
enable it.
Don't restrict it for no reason.
The next one is camera preview.
Clara mentioned on this briefly.
I'm actually not going to go into the solution for this
because we do have a dedicated talk.
I'm just going to describe a little bit more
about some of the problems that you may experience with camera
applications, again, related to every application
now runs in multi-window mode and you
can have very different kind of requirements or experiences
as a result.
And that comes down to alignment of different types
of orientation.
So every device has a natural orientation.
In most phones, it's portrait.
In most desktops, it's landscape.
Some tablets, it can vary.
But you have to align the display orientation
with the natural orientation of the device with the sensor
orientation.
And these things can get out of alignment
depending on the device your application is running on.
You'll learn a lot more about how
to solve that in the related talk, but one easy tip.
Use CameraX.
Like I mentioned, if you're using Jetpack libraries,
we will do a lot of this for you.
If you have requirements beyond what is supported in CameraX,
you'll learn a lot more on how to fix
these in the subsequent talk.
CLARA BAYARRI: Another common problem
we see is related to insets.
And we call it insets the relationship
between an edge-to-edge app and the system UI.
Think things like the notch, gesture nav, or the new taskbar
that was introduced in 12 L. All of these things cause
insets to change within your app.
And you want to be able to handle those gracefully.
When you don't handle these, especially
if you don't handle them dynamically,
you can find that things like the new taskbar from 12 L that
comes from the bottom may occlude very important parts
of your app.
For example, if you're using bottom navigation
and suddenly the taskbar comes up
and you're not reacting to those insets,
you're losing a huge part of functionality of your app.
So you want to make sure that you are handling insets
dynamically so that you can react and resize.
To do that, we have the window insets listener APIs.
These provide new callbacks every time the insets change.
So make sure you are using those instead of just assuming
that the first value you get is what you'll get
the entire runtime of the app.
And make sure you're then updating
your margins to move content appropriately and fixing this.
The next one we see a lot is apps that are clearly
not tested on large screens.
For example, blown up layouts.
Or we see a lot of broken behavior in multi-window.
And all of these can be easily solved
by using a bunch of the tools that we mentioned in the tools
talk.
So I highly recommend, if you haven't seen that, you go back
to the tools talk.
As a quick tip, definitely use resizable emulator
because it allows you to test your app in different screen
sizes really quickly.
It allows you to test multi-window as well.
You can launch into multi-window and make sure
that your app is behaving correctly.
And use reference devices while you're
developing because it allows you really quickly to see
how your app looks on different reference devices which
cover most of the ecosystem.
So I highly recommend that.
Otherwise, go look for the talk for more.
And finally to leave you with a good one, how many times have
you assumed that all of your users are using touch?
Well, that's not necessarily true.
We have a huge fleet of Chromebook devices
that can run your app.
And there will be a lot of users using
keyboard or mouse or trackpads in track with your app.
Also, accessibility users may be interacting with your app
with different accessibility devices.
And so it's really important to make sure
that you are supporting all of these inputs
and not just assuming that people
are going to touch your screen.
For that, we have a dedicated talk
that goes extremely in-depth on this.
The key to keyboard and mouse support
across tablets and ChromeOS.
Highly recommend if your app has any of these issues,
you look into all of that detail.
But obviously the do and don't is
don't assume there's only a touch input,
and support keyboard mouse and trackpad.
OK.
That was a lot of tips and information in 20 minutes.
I hope some of it sunk in.
Thank you so much.
[APPLAUSE]
[MUSIC PLAYING]