[MUSIC PLAYING]
KENNETH FORD: Hi, everyone.
Thank you for coming and watching
my session, which is going to be Android on large screens.
So as we all know, Android has evolved from just being a phone
platform.
It's available on watches and cars,
as we just heard, desktop, phones.
And specifically, the mobile space
has also changed pretty drastically.
Let's see what your mobile APK is running on today.
So starting off with the phone, it's
what we all develop for mainly, if not solely.
A couple of keys about the platform.
It's portrait first, touch first, and full screen first.
A lot of apps now even lock rotation.
Some users do obviously use multi-window
or stylus and things like that.
But majority of your users are using it
with regular touch screens and in full screen.
Moving on to tablets.
Both orientations here are kind of first class citizens.
If you do opt to portrait, users can still use your app
in the portrait landscape.
Larger screens do bring challenges design wise,
but also the ability to kind of do different things,
take more advantage of the real estate,
allow your users to do things faster.
But more importantly, the different medium
kind of brings a different focus on what apps are probably
going to be used more heavily--
content apps or media consumption apps,
productivity apps, things that can really take
advantage of the larger screen.
And then moving on to kind of the desktop platforms.
We have Chrome OS, we have some OEMs
that have made desktop platforms as well
like the Samsung [INAUDIBLE],, the [INAUDIBLE] [? make ?]
desktop mode.
Also, Android has now brought the ability
to really take advantage of having external displays.
So it's very possible that your app even if it's
running on a phone is actually being displayed
to an external monitor.
This is really where the biggest difference comes
in where it's landscape first.
All these environments have some sort of window resizing,
and multi-windows could be used a lot more often.
And you have new first class input methods
such as keyboard and mouse and track pads
that actually either ship with the device
or will be connected.
So what's the focus on when you're
thinking about kind of how to bring your apps to all
these platforms and have a good user experience?
Number one is design.
Again, if you've really been focusing on phones,
most of your designs are probably
very portrait based and kind of smaller screen based.
Window management is probably the biggest place
where we see issues with partner's apps.
Dealing with resizing, some multi-window consideration,
things like that are just problems we've never
had to focus before.
And then we're going to talk a little bit
about the tooling that's available from Google
to make sure that you're able to actually develop
for these platforms and bring it into your actual cycle.
So talking about design.
Raise your hands if you have layouts for large screens
or tablets at all.
That's a lot more people than I expected.
Cool.
So biggest thing is just thinking about larger screens,
again.
Probably for the last couple of years,
we've seen a lot more apps come out
that they may lock the portrait or are solely mobile
focused, which makes sense.
But with the more and more growing number
of platforms that are running your mobile APK but showing
a completely different form factor or platform,
it's time to start thinking again
about how to really bring the best experience to those areas.
A really bad example of design is actually Google Play Music,
which is always great.
So a couple things about this that really are not great
is super stretch layout.
There's tons of white space that could
be used to show more content to the user,
whether it's album descriptions, artist descriptions, album
art, things like that.
The biggest key here though is there's no line dividers, which
on a phone is fine because the screen is so small,
you can see what options menu you're clicking on.
When you take it to kind of a larger landscape layout,
it's really hard to actually follow the lines
and see what item you're pressing options menu for.
An external partner that we worked a lot with actually
is 1Password.
So looking at their phone layouts,
it's kind of your standard list of items
that you'll drill down into.
But when you move to a larger screen,
they really take advantage of the real estate going
to almost like a three panel layout,
allowing the user to really get whatever content they
need in a lot less clicks and a lot faster.
Also being able to showcase more information at the same time.
So kind of going back to the same point
is, again, just building layouts for both orientations.
And there's a couple of big keys for this.
Again, not all platforms are portrait first.
A lot of the desktop environments--
if you're only really building for portrait,
you're going to have a pretty bad user experience
when I want to use your app in, let's say, full screen,
or even just the top half of the screen
if I'm trying to multitask.
On top of that, resizing capabilities
allow the user to make your app whatever size,
orientation, or screen ratio that they really want to.
So you really want to let the user really decide
how they want to use your app.
Going back to kind of mainly the desktop platforms
is designing for input mediums other than touch.
Make sure your design is taken into consideration, like how
your app works maybe using a mouse or stylus, and things
like that.
On top of this, the UX patterns are
different for non-touch devices.
Things like right clicking is a little bit
different than what we kind of are used to with long pressing.
Most of the paradigms are long pressing to multi-select items.
Whereas when you right click on a desktop,
you're usually expecting some type of
pop up context menu and things like that.
So taking the time to really think
about how your app works for the different UX considerations.
The other big one that we notice is hover actions.
On the web or on desktop environments for the mouse,
you really expect some type of feedback
when you move your mouse over an action item
to let you know that there is actually
something you can do there, whether it's
clickable, or dragable.
There's some behavior, there's some feedback.
Myself, even if I use the app on a phone extensively--
Google Drive is a good example of this--
when I use it on, let's say, Android on Chrome OS,
I'll miss actions that I can actually
do because just natively on this platform,
I'm expecting some type of hover actions.
I'm going to go over two simple APIs.
There are many APIs that kind of help
handle a lot of these input methods and things,
such as mouse scrolling and things like that.
And there'll be resources when the slides get posted.
But right clicking, which is one of the usual kind of feature
blocks, is super easy.
You just set an on context with listener
and make sure that you're exposing whatever behavior
or functionality you have on long press in this method.
Again, also hopefully considering any type of UX
changes you need to make.
And then setting the hover listener to kind of
watch for the user's points.
You're hovering over the item and [? out. ?] Again,
this is really the biggest one we
see that will lead to kind of misfunctionality
or kind of really give you the desktop native feel,
or even just kind of the large screen native feel.
In terms of hovering, most of our native components
do handle this somewhat.
But depending on the colors you're using,
the contrast and change may not be
enough for you or your users, or especially accessibility,
things like that.
At the end of the day though, you
know how your users use the app, and you know the product.
So take some time and use your app
on kind of these different platforms
and think about how you would expect the app to behave,
things that you would expect the app to take advantage of.
Note taking out the stylus based--
may not really need to focus much on mouse input or keyboard
input, where a productivity app is really
going to want to take advantage of all the screen real estate
and find ways to let the users do what they
need to do as fast as possible.
So talking about window management.
This, again, is really the biggest area
where we see crashes happen because it's just challenges
that we've never had to face before and kind
of a mobile only environment.
I love harping on rotation because I
see so many apps that lock to portrait, which
is completely understandable.
But on these different platforms,
it really shows kind of where the experience falls.
If you do locked on portrait on Chrome OS specifically,
this is how your app will look like.
You'll get these super cool black bars on the side.
And it's really just a whole bunch
of wasted screen real estate.
On top of that, it also really shows the user
and gives this really non-native feel
just because it doesn't really conform to the platform well.
Now, why do we generally lock to portrait?
Usually to run away from handling configuration
changes because they've always been
rather difficult to deal with.
But on these larger screen platforms,
configuration changes are more important than ever.
Resizing and multi-window brings a lot
of new kind of configuration change paradigms
and challenges.
Chrome OS is probably one of the most complex
of the resizing strategies because it
does trigger configuration changes pretty frequently.
I know some of the other desktop platforms
don't cause as many configuration changes.
On top of that, with bigger screens,
multi-window is going to be used much more
frequently than before.
So any bugs that you do have in that
are going to start kind of being surfaced a lot more.
This is a quick GIF about just kind of how
resizing on Chrome OS works.
So anytime one of those labels changes,
it's going through a complete destroy and rebuild process.
So you can imagine that this can get triggered substantially
faster and substantially more often than on a phone
just because rotation is just kind of slow.
Jetpack helps with this.
Things like view model and being able to build
your own components that are lifecycle aware really
allows you to kind of take any of your business logic
that's in your activity, anything
you're doing to save state, and move it
there so that your activity destroy and rebuild process
is really quick.
Your app will not always be in focus.
Again, this isn't new.
With Android N, we brought multi-window.
But on these larger screens, you're
going to see this being the case a lot more often.
I know most of us that work with a large monitor
have multiple things up at once.
And you need to make sure that your content is
still visible and playing even if you're not the focused app.
So make sure that you're still displaying messages
if you're a messaging app, or your content is continuing
playing.
And then take advantage of the features
on these new and different platforms.
Larger screens and external monitors
bring new possibilities.
One of the things that we've seen a couple apps do,
such as email apps or word processing apps
that really kind of bring a better experience,
is allowing email composed windows or new documents
to be shown in different tasks so that the user can really
see their email plus this new email they're
creating in a different window.
Something that we released quite a bit ago
but is now really being used a lot more is drag and drop.
Again, these desktop platforms specifically,
users expect drag and drop to be a thing.
They're not really going to understand
that this is an Android app and we've never thought about it
before, so why doesn't this exist?
So think about if drag and drop kind of makes
sense in your app, and how you can kind of bring it
to these platforms.
And then not really window management,
but different features that are kind of new to some
of these ecosystems is just--
different info capabilities and specifically increased
stylus usage.
The biggest thing that we've seen
that users have logged on some of the apps
that we've worked with is the ability
to have keyboard shortcuts and keyboard navigation
so that if they're heavy power users
or there's things that people do often,
they're able to do these things faster in and out of the app,
get what they need to get done as quick as possible.
So this is great and all, but how do we actually
build for this?
And moving on to tooling.
It'd be awful if I came up here and talked about kind of you
should do all these things, yet there's no tools from us
to make this possible.
Most of the tooling examples that we do
have are around Chrome OS.
A, it's our platform, and then B,
it's also kind of the most all in one platform that we have.
Most devices ship with a keyboard and track pad.
Some don't even have a touch screen.
And then it has one of the more complex resizing strategies.
So it's kind of the best all in one platform to test on.
We were working on bringing some interest to the integration,
specifically around larger screens in Chrome OS.
Lint additions are coming soon.
It's actually my job once this event's over to finish this.
And then we're really looking at more things
that we can bring to the IDE.
It's really great to have devices that you can test on,
but we want to be able to give quicker feedback
and things to look for while you're actually
developing in the IDE.
So if you have ideas, please come let me know.
There's a Chrome OS emulator that's currently in preview.
So if you don't have devices, you can download the emulator
and start to kind of see where your app falls apart,
things that don't work, things that crash, et cetera.
One of the biggest complaints for developing
for Chrome OS in testing has been
having to use ADB over Wi-Fi, and the development cycle's
always been pretty crappy.
But on the HP Chromebook X2 and the Pixelbook,
you can ADB over USB, so you can actually bring the devices
into the same kind of development cycle
that you do with phones.
Other devices still require ADB over Wi-Fi,
but we hope to bring more and more devices to this feature.
But the easiest way really is just
to run Android Studio on Chrome OS.
This is available currently on the Pixelbook in preview,
and we're hoping to bring it to more devices in the future.
And we do have this setup at the Android and Chrome OS tables
as well as the Android Studio table.
Being able to just kind of build the app
and deploy it directly to the device
makes the whole development cycles substantially easier
and faster.
At the end of day, Android is always evolving.
There's more and more platforms that are running APKs,
whether they're different flavors or even just
your mobile APK.
So make sure that your app is too.
Thank you.
Again, please ask any questions.
Any suggestions that you have for tooling,
any things that you've run into when trying to develop for kind
of larger screen platforms, I would
love to hear about it so that we can tackle this.
Thank you.
[MUSIC PLAYING]