MURAT YENER: One of the biggest UI changes coming to Android Q
is gestural navigation.
You may have already seen various gestures for navigation
on some of our partners' devices.
Android Q is supporting a new out-of-the-box navigation
experience.
Navigation gestures are supported
as a new mode, separate from the traditional three-button
experience in the bottom nav bar.
This lets your app use the entire screen,
which provides a more immersive display experience.
Android Q has gestures for going home and going back.
Swiping up from the bottom edge takes the user
to the home screen.
Swiping inwards anywhere on the left or right just
takes the user back to the previous screen.
With these two gestures, your app
can take advantage of the valuable screen real estate
on the bottom of the display.
However, if your app uses gestures or has controls
in the system gesture areas, it might create conflict
with the system-wide gestures.
For example, if your app relies on gestures
for sliders or draggable items in any of the system gesture
areas, your users might accidentally
trigger a navigation gesture.
This results in a broken experience in your app.
There are two gestural conflicts your app might encounter.
The first conflict is with the swipe
up gesture on the bottom edge of the screen,
which takes the user to the home screen.
You should avoid having any critical controls rely
on vertical swipe gesture in the bottom parts of your app
because the home gesture is designed
to be a reliable escape mechanism for users
and will always get priority for touch events.
Examples of UI conflicts with the home gesture
are bottom draggable sheets or other swipe
up to perform actions.
To steer clear of the bottom swipe conflict,
we edit WindowInsets.get MandatoryGestureInsets,
which returns all swipe recognition thresholds
for the device.
Using this information, apps can shift conflicting content
from the edges of the screen.
The second conflict is with the H swipe gesture,
which takes the user back.
The system back gesture occupies the entire length
of the left and right screen edges,
so apps should make sure that key touch and motion
functionality isn't stolen by system back gesture.
Examples of interaction conflicts with the back gesture
include drawers, sliders, sheets,
and other controls which require a swipe
or drag to perform an action.
In order to handle touch events at the edges of the screen,
apps can tell the system which areas
they need to exclude from the back gesture
with the new gesture exclusion rect
API in Q. If back gesture interferes with your app
controls, use the gesture exclusion rect
API to create gesture exclusion zones for the controls that
might be affected.
On the other hand, do not disable the back gesture
by creating a gesture exclusion zone which spans
entire edge of the screen.
This creates a broken, non-consistent behavior
with the system and other apps.
The new API is a part of the View class, which
expects a list of rect objects that represent
gesture exclusion zones.
This API lets your app intercept horizontal swipes
only between the desired areas.
The gesture exclusion rects API call
should be performed in the onLayout or onDraw
methods of the view, as shown in this example.
DrawerLayout and SeekBar components
already have this opt-out behavior
built in, so no additional work is needed,
other than updating the jetPack dependencies
and/or build against the new SDK, respectively.
And that's it.
To ensure the best user experience,
make sure the gestures in your app
do not conflict with the system-wide gestures.
If they do, use system gesture exclusion rects
API to fix any problems before targeting
your app to Android Q.
If you're interested in gestural navigation,
make sure you also watch the edge-to-edge dev bite, which
is linked in the notes below.
Thank you for watching.
Make sure to subscribe to the channel for more awsome Android
videos.
See you next time.
[MUSIC PLAYING]