(upbeat music)
Hi, I’m Diana Wong,
a product manager on the Android developer team
for foldables, tablets and large screens.
We're really excited about the innovations made in foldables
and tablets over the last year.
Android apps are getting used on larger and larger screens
and users are expecting more from these devices.
Let’s unfold what’s new in large screens.
In this talk, we’ll explain what app developers should do
to prepare their apps for large screens,
as well as recent updates we've made to make developing your app easier.
But first, let's talk about what we're seeing with large screens
and why you should optimize your app.
As we look at the evolution of the phone,
the three fastest periods of mobile growth have been driven by screen size increases.
Users are valuing larger screens
and the capabilities of doing more with a single device.
The ability to fold a screen
is enabling better ergonomics for larger devices.
Now you can fit a tablet-sized screen in your pocket,
unlocking utility users previously wouldn’t be able to get
on a device that they could easily carry around.
When we're thinking about our app ecosystem,
we’re excited because this is a huge hardware shift
that is driving new expectations
around what you can do from a phone. We see this demand for larger screens
extending to tablets as well.
Since the app experience is similar, we'll be talking about them together.
Over the past year,
we’ve seen device makers release exciting new foldable and tablet devices.
Demand has increased as users are doing more than ever
from these devices while at home.
Tablet sales grew 16% in 2020,
with analysts expecting more than 400 million Android tablets by 2023.
And foldables are redefining what’s possible on premium devices,
with an estimated 30 million foldable devices in the next two years.
Android apps can also run on Chrome OS, which has seen a surge of interest
and is now the second most popular desktop OS.
Altogether, an app today can reach more than 250 million
active foldables, tablets and Chromebooks by building for Android large screen devices.
We're excited about this momentum as large screens continue to grow in reach.
Now's the time to get your app ready.
Our data shows that users love large-screen devices.
The bigger the screen, the more time users tend to spend on the device
and the deeper their engagement.
More than 40% of users on the Samsung Galaxy Z Fold2
change their display settings to a resolution greater than 600 dp width,
giving them a full tablet experience in their apps
and making room for more content.
Being able to do more on the screen
is one of the top reasons users love these devices,
allowing them to increase their productivity both inside and outside the workplace.
Larger screens are also changing how users interact with their device.
These devices allow you to edit slide decks while looking at notes,
look up restaurant recommendations while planning a night out,
or watch a video while chatting with friends.
We see around a 10 X increase of users going into split screen or multi-window mode
when they use a foldable versus a typical smartphone.
Developers should expect their app won’t be the only one on the screen,
or the only thing a user can see anymore.
For example, use cases like drag and drop now become a more expected user experience.
Lastly, foldable devices also bring the ability
to place a screen in tabletop mode, a key use case for these devices,
perfect for hands-free activities like watching videos or taking calls.
Lots of apps are optimizing for large screens,
taking advantage of the larger real estate and enabling exciting new experiences.
For example, Disney+ updated their mobile app
for devices such as the Samsung Galaxy Z Fold2
to accommodate folding and unfolding
and optimizing the user experience for larger screens.
Viewers can take advantage of watching shows on full, larger screen
or set the foldable down in tabletop mode for a hands-free experience.
We've got new case studies so you can see how these apps have adapted
for the larger form factors.
Take a look at the link below for more information.
But what does it mean to optimize your app for a large screen?
Well, there are hero use cases like tabletop mode or advanced drag and drop,
but let's talk about base-level support, features an app has to support
to be considered large screen ready.
There are three main categories of features to support.
The first is to ensure that your app is designed for large screens.
To make this easier,
we’ve defined specific window size breakpoints and device classes
for developers to optimize for.
Add tablet layouts for resolutions greater than 600 dpi
and ensure your apps go edge-to-edge.
Developers should also plan for their app to be in portrait and landscape mode,
since larger screens are more likely to be used in landscape.
We've got material adoptive components that we’ll be talking about
to help apps make better use of the space.
Second, is that developers should plan for apps
to handle the updated multitasking experiences well
by having their apps be resizable.
Handling folding and unfolding,
as well as planning for your app to be in multi-window mode,
will prevent users from seeing your app in a letterboxed experience.
Supporting multi-instance and multi-resume is particularly useful for productivity apps,
so users can do more with your app side-by-side.
Lastly, since larger screens are being used more for productivity use cases,
basic keyboard, mouse and stylus support is required for tablet usage.
We've talked about how your app should support these devices.
Now, over to Ken to talk about how we've made it easier
for you to adapt your app.
Thanks Diana. Let’s start with components that’ll help you build a responsive UX
to take your phone UI to unfolded and larger tablet screens.
Common patterns such as list detail are an easy way
to optimize your current apps experience for these devices.
UIs that would normally lay on top of each other
can be placed side-by-side when you have the space for it.
We've updated SlidingPaneLayout in version 1.2.0
to try and do this for you out of the box.
SlidingPaneLayout will use the width of both panes
to determine if they can be placed side-by-side.
Let's say if you have a list,
a chat list pane that requires 200 dp of width,
and actual chat detail requires 400,
on any window size greater than 600 dp, those two panes will be placed side-by-side.
We’ve also added the feature of SlidingPaneLayout
being aware of display features such as folds and hinges
and will automatically place your content across them if possible.
A good example of this is if somebody is holding a foldable device half open,
we’ll determine if we can place your content
on each side of the fold, then do it out of the box.
We’ve also brought the idea of lock modes
to give you more control as a developer over the swipe gestures on each screen.
An example where this may be useful
is if you want your users to only access a message by pressing on it,
but you want them to have the ability to swipe back to go back to the list.
SlindingPaneLayout is currently in beta in 1.2.0.
Next up we're gonna talk about the new Navigation Rail component.
Navigation rail is a new material component
that will help you provide better ergonomics for navigation as your UI scales.
Reachability on some of these devices is a major key
due to most people holding tablets on the sides
versus holding their phone on the bottom,
and so Navigation Rail allows you to move your navigation
where people can access it.
It also allows your content to remain the main focus
since the navigation is out of the way.
Adding Navigation Rail should be very low impact,
as both Bottom Navigation and Navigation Rail support the same set of APIs.
Adding Navigation Rail to certain windows sides in your app
should be very, very small code changes.
Check out the materials session,
Five Things You Can Do Today to Prepare Your App for Large Screens for more info.
Another thing we've done is add max width properties
across multiple of the material components.
One of the major pitfalls that we see in apps on larger screens,
is UI elements being stretched across the entire screen,
as that's how you have it on a phone.
On bigger screens though, this tends to just look very stretched
and just gives a bad user experience.
You're kind of wasting screen real estate.
We’ve added max width properties
on some of the elements we see this happen the most
such as buttons, textfields and sheets.
This brings opinionated values to improve the UX of your app
out of the box with no changes for you to make.
Beyond components, we have also built the WindowManager Jetpack library
to help developers build great and differentiated experiences.
WindowManager Jetpack is a library to support new device form factors
and provide a common API surface for supporting different and new device types
starting with foldables and tablets.
It's currently in alpha and will soon move to beta and stable.
WindowManager Jetpack introduces the idea of display features
and provides callbacks to be notified if your app is impacted by a display feature,
such as a fold or a hinge.
A fold is generally a constant screen that bends
such as the Samsung Galaxy Fold2, whereas a hinge would be a scenario
where your app is actually spanned across two screens,
such as the Microsoft Surface Duo.
Both are encapsulated in our folding feature class.
It also gives information about how that feature impacts your app
such as if it’s actually separating content, like a device in tabletop mode,
or if it's actually occluding content like could be on a hinge device.
Adjusting your UI can be tough,
but ConstraintLayout 2.1 has a bunch of new features
to make this much easier.
2.1 introduces the ideas of shared values and ReactiveGuides
which allow you to inject the position of the fold at runtime.
From here, your layout adjusts to the ReactiveGuide
just as it would with the normal guideline.
MotionLayout also has updates
to allow you to automatically animate to the new fold position,
as well as allowing you to easily model these different device states.
In this example here, you can see this in action
where the device goes into half-folded mode,
the plant list slides in to allow the detail pane to be shown.
Let’s see how this would actually look in code.
Here you can see that we're looking at the display feature
and the properties of it, and then adjusting the ReactiveGuideline,
as well as starting our layout animations.
Check out the What’s New in Design Tools talk for more Constraint Layout information.
How to reliably develop for foldables is a question that we get a lot,
and we want to make sure you can ship these new experiences
and have confidence in both their quality and stability.
We’ve rebuilt the API’s provided in Jetpack Window Manager
to provide a better testing experience out of the box.
We are also working on a testing module for WindowManager Jetpack
to better help you write automated tests.
Our goal is to introduce test rules,
as well as the ability to model device state changes
such as going in and out of tabletop mode
to allow you to make sure that your UI is reacting correctly.
We’re planning to add more to the testing story as time goes on
so please let us know what you're looking for.
More information can be found in the documentation at the link below.
Now, as mentioned earlier,
multi-window is used more and more on larger screens
and you can’t always assume your app will be running in full screen.
In Android 11, we introduced the WindowMetrics APIs
to let you have the right information you need for your window
instead of focusing on display information.
In Android 12, we have deprecated the getRealSize
and getRealMetrics methods on display
to go along with the previous deprecations of getSize and getMetrics.
We’ve brought the Window Metrics APIs to Jetpack Window Manager,
to allow you to support older versions of Android with the same APIs,
as well as reducing the confusion around previous display APIs.
Current WindowMetrics gives you the current bounds of your window,
while maximum WindowMetrics will give the largest bounds available
in the current system configuration.
Now, an example of where maximum WindowMetrics will change
are scenarios with multiple-displays
where the maximum WindowMetrics value will change
depending on the display that your app's window is running on.
Neither of these API should be used for the direct layout of UI elements,
but these APIs are designed to be used
if you need to make decisions about which layout you want to show,
or calculations that need to be made for your UI,
and maximum can be a good indicator if you have specific parts of your UI
you don’t want to change regardless of the window size.
Both of these values are available to you in OnCreate
so that you can make these decisions before the first layout pass.
Those are some of the updates we’ve made. We've also updated developer.android.com
to make it easier for you to find the info you need.
Check out our new large screen hub with the URL on screen,
where you’ll find in-depth articles on getting large screen ready, case studies,
as well as samples for the things we've talked about today.
Here you can find all the resources we’ve talked about in this session,
and we’ve hoped you’ve had fun as we’ve unfolded
the amazing stuff we're working on.
Thank you for watching.
(upbeat music)