
Indonesian: 
CHRIS BANES: Halo.
Saya Chris Banes, engineer
di Tim Android Developer Relations.
ROHAN SHAH: Saya Rohan,
Project Manager di Tim Android System UI.
Kami akan membahas tepi ke tepi.
Bagi yang belum 
tahu maksud dari istilah ini,
kami akan akan
membahasnya lebih lanjut,
tetapi saya ingin memberi
gambaran sedikit tentang navigasi.
Jadi, sekitar lima bulan lalu
di Google I/O
kami membahas navigasi gestur,
lalu memperkenalkannya 
sebagai versi awal dalam beta.
Sejak saat itu, kami terus
menyempurnakannya tanpa henti.
Kami bekerja sama 
dengan banyak pembuat perangkat
untuk menstandardisasi navigasi gestur
di seluruh ekosistem.
Saya ingin memberi kabar
terbaru untuk Anda yang ada di sini.
Dengan adanya Q,
hampir semua pembuat perangkat besar
akan menyediakan
gestur di perangkat mereka.

English: 
[MUSIC PLAYING]
CHRIS BANES: Hello.
My name is Chris Banes, and
I'm an engineer on the Android
Developer Relations Team.
ROHAN SHAH: I'm Rohan.
I'm a PM on the
Android System UI Team.
We're going to be talking to
you about going edge-to-edge.
So for those of you who
don't know what the term is,
we'll get into
that, but I kind of
want to set the stage a little
bit and talk about navigation.
So about five months
ago at Google I/O,
we talked about
gesture navigation,
introducing it as an
initial version in beta.
And since then, we've done
a lot of work to improve it.
We've worked with a
lot of device makers
to basically standardize
a lot of that
across the entire ecosystem.
So I just kind of want
to give you an update.
Basically, with Q, almost all
of our major device makers
will be shipping with
gestures on their device.
I just want to give
you a quick idea

Portuguese: 
Olá, sou Cris Banes,
engenheiro de Relações
com Desenvolvedores do Android.
Sou Rohan, PM da Equipe
de IU do Sistema Android.
Vamos explicar como ir 
para a versão 'de ponta a ponta'.
Para quem não sabe o que
o termo significa,
vamos explicar.
Antes disso, vou falar
um pouco sobre navegação.
Há uns cinco meses, no Google I/O,
falamos sobre navegação por gestos.
Lançamos a versão inicial em beta.
Desde então, trabalhamos
para melhorar o recurso.
Trabalhos com vários
fabricantes de dispositivos
para padronizar muitos desses aspectos
em todo o ecossistema.
Quero contar as novidades.
Na versão Q, quase todos
os principais fabricantes
vão incluir gestos nos dispositivos.
Vou explicar um pouco sobre
a dimensão do problema.

Korean: 
[음악 재생중]
안녕하세요
저는 크리스 배인즈이고
Android 개발 관련 팀의
엔지니어입니다
저는 로한이고
Android 시스템 UI 팀의 PM입니다
오늘은 Going Edge-to-Edge에 대해
이야기해보겠습니다
이게 무슨 뜻인지 잘 모르시는 분들께는
나중에 더 자세히 알려드리죠
먼저 준비를 한 후에 내비게이션 이야기를 하고 싶군요
약 5달 전 Google I/O에서
제스처 내비게이션을 주제로 
이야기한 적이 있습니다
당시에는 베타 상태인 초기 버전으로 소개했었죠
그때 이후로 시스템을 개선하기 위해
많은 작업을 했습니다
생태계 전반에 걸쳐
이를 표준화하기 위해
수많은 기기 제조사와 협업했죠
그래서 이에 대한 근황을 알려드리려 합니다
기본적으로 Android 10에서,
거의 모든 주요 기기 제조사가
자사 기기에
제스처 기능을 탑재할 것입니다
저는 여러분에게 이 문제의 범위를

Chinese: 
大家好 我是 Chris Bane
我是 Android 开发者关系团队的一名工程师
我是 Rohan
我是 Android 系统 UI 团队的 PM
我们要和大家讲讲我们是如何实现全屏体验的
有的人可能不明白这个"从边到边"是什么意思
我们稍后会详细介绍的
不过我想先讲的是 导航
大约5个月前 在 I/O 大会上
我们讨论了手势导航
我们在 beta 版本的时候把这个功能
作为最初版本给推出来了
从那时起 我们花了大量的精力来改进它
我们和很多设备制造商合作
主要目的是在整个生态系统内
实现这个功能的标准化
现在为大家提供一下最新的信息
随着 Android Q 的推出
我们的合作设备制造商几乎都会推出带有手势操作功能的设备
先让大家了解一下这个问题的规模

Spanish: 
[música sonando]
Hola.
Soy Chris Banes, ingeniero de Relaciones
con Desarrolladores de Android.
Soy Rohan.
Soy PM en el equipo de IU de Android.
Vamos a hablar sobre
cómo trabajar de borde a borde.
Para aquellos que no conocen el término,
vamos a explicarlo
pero quiero preparar el camino
y hablar sobre navegación.
Hace unos 5 meses, en Google I/O
hablamos sobre la navegación por gestos
y la presentamos
como una versión inicial en beta.
Desde entonces,
trabajamos mucho para mejorarla.
Trabajamos con muchos
desarrolladores de dispositivos
para básicamente
estandarizar gran parte de eso
en todo el ecosistema.
Solo quiero darles una actualización.
Básicamente, con Q casi todos
nuestros grandes fabricantes
de dispositivos harán envíos
con gestos en sus dispositivos.
Solo quiero darles una idea rápida

Japanese: 
こんにちは
デベロッパーリレーションズの
クリス・ベインズです
システムUIチーム PMの
ローハンです
エッジツーエッジ化について話します
この用語を知らない人のために
その説明もしますが
ナビゲーションについて話したいと思います
約５か月前 Google I/Oで
ジェスチャーナビゲーションについて話し
ベータ版の初期バージョンとして紹介しました
それ以来 多くを改善してきました
多くのデバイスメーカーと協力し
基本的にエコシステム全体で
その多くを標準化しました
最新情報をお伝えしたいと思います
基本的にQでは 主要デバイスメーカーが
デバイスにジェスチャーを付けて出荷します

Spanish: 
sobre el alcance del problema.
Es muy emocionante para nosotros
y el sistema de gestos principal
que enviarán es
el que vieron en I/O
donde deslizan el dedo desde abajo
para ir al Inicio
deslizan desde los bordes para ir Atrás
y deslizan y mantienen apretado desde
la parte inferior para ir a Recientes.
¿Qué significa esto para Android Q?
Básicamente, verán
dos modos de navegación en Q.
Este es el modo de 3 botones
que la mayoría de usuarios ama
y está el modo
de navegación con gestos,
que es un poco más rápido 
y con mayor capacidad de respuesta.
Uno de los grandes cambios en Q, 
es que el modo de 3 botones
será necesario en todos los dispositivos.
Hay muchas necesidades de accesibilidad
y, francamente,
algunas personas odian los gestos.
Definitivamente lo reconocemos.
Y creo que es algo que queremos
mantener como esencia en Android.
La navegación con gestos
estará disponible como opción
y gran parte de nuestros fabricantes
la está empezando a usar.

Portuguese: 
Estamos animados. O sistema
que eles vão usar é aquele que vocês
viram na I/O. Deslizar para cima
para ir ao início.
Deslizar para esquerda
ou direita para voltar.
Deslizar para cima
e segurar para ir aos recentes.
O que isso significa para o Android Q?
O Q tem dois modos de navegação.
O modo de três botões,
que muita gente adora,
e o novo modo de navegação por gestos,
mais rápido e responsivo.
Uma das grandes mudanças do Q,
talvez vocês tenham ouvido falar,
é que o novo modo
será obrigatório em todos os dispositivos.
Existem questões de acessibilidade,
e algumas pessoas odeiam gestos.
Nós sabemos disso.
Acho que vamos manter isso
como uma característica do Android.
A navegação por gestos será opcional,
e a maioria dos fabricantes
vai implementar.

Indonesian: 
Saya ingin menyajikan
ide singkat dari batasan masalahnya.
Ini hal yang menyenangkan bagi kami,
dan sistem gestur utama
yang akan mereka sediakan di sini
sama dengan yang Anda lihat di I/O.
Anda menggeser dari bawah ke beranda.
Anda menggeser dari
tepi kiri dan kanan untuk kembali,
dan Anda dapat menggeser lalu tahan
dari bawah untuk membuka yang terbaru.
Jadi, apa arti semua ini untuk Android Q?
Ini artinya, Anda
akan melihat dua mode navigasi di Q.
Jadi ada mode tiga tombol
yang disukai pengguna Android,
lalu ada mode navigasi gestur baru
yang dibuat agar navigasi
lebih cepat dan responsif.
Mode tiga tombol,
salah satu perubahan besar Q,
seperti yang pernah
Anda dengar sebelumnya,
kini akan diwajibkan di seluruh perangkat.
Ada banyak kebutuhan aksesibilitas,
dan tidak dipungkiri
bahwa banyak orang tidak suka gestur.
Kami mengakuinya.
Dan saya rasa inilah yang kami
inginkan untuk
tetap ada di Android.
Navigasi gestur akan
tersedia secara opsional
dan sebagian besar 
pembuat perangkat akan menggunakannya.

Korean: 
간략히 전하려고 합니다
정말 기대가 되는 일인데
주요 제조사에서 탑재할 메인 제스처 시스템은
여러분이 I/O에서 보신 시스템입니다
홈으로 돌아갈 때 아래에서 위로
밀어 올리면 되죠
왼쪽에서 오른쪽 화면 끝으로 밀면 뒤로 가기가 되고
아래에서 위로 밀어 올린 뒤 
멈춰있으면 최근으로 돌아가죠
이게 Android 10에 무슨 의미가 있을까요?
Android 10에서 두 가지 내비게이션 모드를 
사용할 수 있다는 의미죠
이것은 Android 사용자 대부분이 사랑하는
세 버튼 모드입니다
그리고 새로운 제스처 내비게이션 모드는
속도와 반응성에서
더욱 앞섭니다
세 버튼 모드가 Android 10에서 가장 달라진 점은
전에도 들어보셨겠지만
이 모드가 이제 모든 기기에 필요하다는 것입니다
이 기능을 중심으로 한 접근성 요구도 많습니다
사실 그냥 제스처를 쓰기 싫은 사람들도 있죠
저희도 그 부분을 인지하고 있으며
세 버튼 모드를 Android의
주요 기능으로 유지하려고 합니다
제스쳐 내비게이션은 선택적으로 사용할 수 있고
주요 제조사에서는 대부분 
이 기능을 포함할 것입니다

Chinese: 
我们很兴奋地看到 这些设备制造商准备发布的功能
正是大家在 I/O 大会上看到的样子
从底部向上轻扫即可返回主屏幕
从左侧和右侧开始向对侧轻扫即可返回
从底部向上轻扫并按住即可查看最近使用的应用
那么 这对于 Android Q 来说意味着什么？
简单地讲 大家会在 Q 中见到两种导航模式
一种是 Android 用户非常喜爱的三键式导航
另一种就是这个全新的手势导航模式
这种模式在理论上应该拥有更快的速度 响应更灵敏
正如大家之前可能听说过的
三键模式是 Q 的一个改动重点之一
现在我们要求所有设备上都支持这个模式
很多可访问性需求与它相关
而且 说实话 有的人就是很讨厌手势操作
这一点我们很清楚
我们希望把它保持为 Android 的标志性功能
我们将会把手势导航作为一种选项提供给大家
大多数合作制造商都正在采用这种导航方式

English: 
of the scope of the problem.
This is super exciting for us,
and the main gesture system
that they will be
shipping here is the one
that you saw at I/O, where
you swipe from the bottom
to go home.
You swipe from the left
and right edge to go back,
and you can swipe and hold from
the bottom to go to recents.
So what does this
mean for Android Q?
Basically, you'll be
seeing two nav modes in Q.
So this is the three-button mode
that most Android folks really,
really love, and then
this new gesture nav
mode, which is meant to be
a little faster and more
responsive.
So three-button mode, one
of the big changes for Q,
as you may have heard
before, is that it will now
be required on all devices.
There's a lot of
accessibility needs around it,
and frankly, some people
just hate gestures.
So we definitely
acknowledge that.
And I think that's
something we want
to keep as a staple in Android.
Gesture nav will
optionally be available
and most of our device
makers are picking it up.

Japanese: 
問題の範囲について簡単に説明します
とても刺激的です
I/Oで紹介した
ジェスチャーシステムです
下からスワイプして
ホームに戻ります
左右の端からスワイプして元に戻り
下からスワイプして長押しすると
最近見たページに移動します
これはAndroid Qでは
どうなるでしょう？
Qには２つのナビモードが表示されます
多くのAndroidユーザーが大好きな
３ボタンモードです
この新しいジェスチャーナビモードは
より高速で反応も速いです
Qの大きな変更点の1つの
３ボタンモードは
全てのデバイスで必須になりました
アクセシビリティへのニーズはありますが
一部の人がジェスチャーを嫌うのは
わかっているので
これはAndroidの基本として
維持したいと考えています
ジェスチャーナビはオプションで利用でき
多くのメーカーが採用しています

English: 
But it can be the default,
like out-of-box experience,
or it can be just another
mode that a user can
pick from settings.
So now, kind of putting this
into context for this talk,
going edge-to-edge, what
does all this mean to you?
Like, why is any of this
really important for you?
So a lot of the reasoning or
motivation behind gesture nav
came from users wanting
more immersive experiences
on their phones.
And one way we did that was
approaching it from a system
perspective by introducing
gestures, getting rid
of the nav bar a
little bit more,
and now, it's kind
of more up to apps
to bring that delightful
experience to users.
It's something that
users see as competitive
and generally a good
user experience.
A second part of why you
should care is gestures, well,
gestures are going to have
some level of conflict
with your app.
So we want to make sure
you're well-prepared.
So this talk will
kind of be going
into how you can make sure
your app is nav ready.

Portuguese: 
Mas pode ser a experiência de fábrica
ou pode ser algo que o usuário define
nas configurações.
Colocando tudo em contexto,
o que significa 'de ponta a ponta'?
Por que é importante para vocês?
A motivação da navegação por gestos
é que os usuários queriam maior imersão
nos celulares.
Uma maneira de fazer isso
da perspectiva do sistema
foi lançar os gestos,
reduzir a barra de navegação
um pouco mais.
Agora cabe aos apps
dar uma experiência
agradável aos usuários.
Os clientes acham isso competitivo
e geralmente uma boa experiência.
Outro motivo para 
se importar com os gestos
é que existe um pouco de conflito
com apps.
É preciso estar preparado para isso.
Nós vamos mostrar
como preparar seu app para a navegação.

Japanese: 
すぐ使えるようにデフォルトにすることも
ユーザーが設定から選択できる
モードにすることもできます
この文脈から見て エッジツーエッジとは
どんな意味があるでしょうか？
なぜ皆さんにとって重要なのでしょうか？
ジェスチャーナビ開発の多くの理由や動機は
スマホでもっと没入感のある体験をしたいという
ユーザーの希望です
そのために システムの観点からは
ジェスチャーを導入し
ナビバーを減らしました
あとは ユーザーに楽しい体験を
提供できるかどうかは
アプリ次第です
ユーザーはアプリで
優れた体験ができるかどうか
判断します
考慮すべき第２の点はジェスチャーです
ジェスチャーは多少
アプリと多少競合するので
ちゃんと理解してほしいのです
そこで今から 皆さんのアプリを
ナビ対応にする方法について説明します

Korean: 
하지만 새로운 경험을 위해 
이를 기본 모드로 설정하거나
사용자가 필요하면 설정에서 변경한 후 사용하는
부가 모드가 될 수도 있습니다
그러면 이 주제를 위해 설명을 더 드리죠
Going Edge-to-Edge, 여러분에겐 어떤 의미인가요?
왜 이것이 여러분에게 중요할까요?
제스처 내비게이션 개발의 동기나 이유를 꼽자면
사용자가 자신의 기기에 
더 몰입하고 싶어 한다는 점에서
출발했습니다
그리고 우리는 이를 해소하고자 제스처를 도입하고
내비게이션 바를 제거하는 등
시스템 측면에서 접근하였습니다
이제 사용자에게 즐거운 경험을 선사하는 건
앱에 달렸습니다
사용자는 이를 경쟁력 있고
바람직한 사용자 경험으로 여깁니다
여러분이 관심을 가져야 할 두 번째 이유는
제스처가 여러분의 앱과
일정 수준의 충돌이
발생할 수 있기 때문입니다
그래서 우리는 여러분이 준비를 잘하길 바랍니다
이 주제는 이제 여러분의 앱이 어떻게 해야
내비게이션과 조화를 이루느냐로 들어갑니다

Spanish: 
Puede ser la opción predeterminada
o solo otro modo que el usuario puede
elegir desde la Configuración.
Entonces, lo voy a poner en contexto
para esta charla.
¿Qué significa trabajar de borde a borde?
¿Por qué es esto importante para ustedes?
Gran parte del razonamiento o motivación
detrás de la navegación con gestos
proviene de los usuarios que
quieren experiencias inmersivas
en sus teléfonos.
Y una forma en que lo hicimos
fue abordarlo desde una perspectiva
del sistema incorporando gestos 
y eliminando la barra de navegación.
Y ahora le corresponde a las aplicaciones
brindarles esa experiencia a los usuarios.
Los usuarios la ven como competitiva
y, generalmente,
como una buena experiencia de usuario.
Una segunda parte de por qué
les deberían importar los gestos
es porque tendrán algún 
nivel de conflicto con su aplicación.
Queremos asegurarnos
de que estén bien preparados.
Esta charla les va a explicar
cómo asegurarse de que su aplicación
esté preparada para la navegación.

Indonesian: 
Mode dapat dijadikan default,
seperti jadi pengalaman baru,
atau mode ini bisa jadi mode lain
yang dipilih pengguna dari setelan.
Mari membahasnya lebih lanjut.
Dari tepi ke tepi.
Bagi Anda, apa artinya hal ini?
Mengapa hal ini sangat penting bagi Anda?
Banyak alasan atau
motivasi di balik navigasi gestur
datang dari pengguna yang 
menginginkan pengalaman lebih imersif
di ponsel mereka.
Salah satu cara yang kami tempuh adalah
melakukan pendekatan
dari perspektif sistem
dengan memperkenalkan gestur,
meniadakan keberadaan menu navigasi,
dan kini terserah developer,
apakah mereka ingin memberikan 
pengalaman mengagumkan kepada pengguna.
Sesuatu yang
kompetitif di mata pengguna
dan umumnya memberikan
pengalaman pengguna yang baik.
Alasan kedua mengapa Anda
harus peduli dengan gestur adalah
gestur akan mengalami
beberapa level konflik
dengan aplikasi Anda.
Jadi kami ingin 
memastikan bahwa Anda sudah siap.
Kali ini kami akan membahas
tentang bagaimana memastikan bahwa 
aplikasi Anda kompatibel untuk navigasi.

Chinese: 
在有些厂商那里 它可能会作为默认设置 开箱可用
在另一些厂商那里 它可能只是一个需要用户在设置中激活的模式
那么 这些东西和今天的主题“从边到边”有何关系？
这些东西对大家而言意味着什么？
它的哪些方面值得我们这么关注？
手势导航这个创意的灵感和动机来自用户的呼声
用户想要让他们的手机拥有更具沉浸性的体验
我们的做法之一就是 从系统的角度来解决这个问题
通过引入手势 尽量减少导航条出现的频率
现在就看应用开发者们的了
他们要把赏心悦目的体验带给用户
这样的做法会提升应用的竞争力和用户体验
你之所以需要关注这个问题 第二个原因在于
手势操作和你的应用是存在一定的冲突的
所以 我们想帮助大家做好准备
在这次的演讲中 我们会向大家介绍
你可以怎样做来确保你的应用做好导航方面的准备
我们主要谈两点

Chinese: 
第一点是 如何实现“从边到边”
这个会交给 Chris 来讲
第二点是 如何处理手势冲突
这个我来讲
下面有请 Chris
谢谢 Rohan 刚刚提到了“从边到边”这个说法
这个说法有点奇怪 那么它的确切含义是什么？
如果你使用 Android Studio 和新模版创建出了 Android 应用
就会得到这样的效果：
你的应用会填满状态栏以下 导航栏以上的所有地方
在“从边到边”设想中 我们想要实现的效果是：
导航栏消失 让应用内容显示出来
当用户拖动屏幕时 看起来就会像是这样
你的内容会在导航条后面滚动
内容从设备屏幕底部开始 一直填充到顶部
Android 10 现在强推的一个功能就是在导航栏后面绘制
我们并不是要强制大家采用这个功能 但很希望大家能试试
在 Q 也就是 Android 10 以前的版本中 这个功能是可选的

Indonesian: 
Ada dua hal yang akan kami bahas.
Pertama adalah navigasi tepi ke tepi,
yang akan dibahas oleh Chris,
dan yang kedua adalah
menangani konflik gestur,
yang akan saya bahas.
Baiklah, saya oper ke Chris.
CHRIS BANES: Terima kasih, Rohan.
Jadi Rohan tadi 
menyebutkan istilah tepi ke tepi.
Kedengarannya memang aneh,
tetapi apa maksud dari istilah ini?
Jadi maksudnya, jika Anda
membuat aplikasi Android menggunakan
Android Studio dengan template baru,
Anda akan mendapatkan
yang seperti ini, yakni batas aplikasi
di bawah status bar
dan di atas menu navigasi.
Yang ingin kami 
lakukan dengan tepi ke tepi adalah
menghilangkan menu navigasi 
agar konten Anda lebih menonjol,
sehingga saat pengguna men-scroll,
akan terlihat seperti ini--
konten Anda di-scroll
di balik menu navigasi,
hingga langsung 
ke bawah layar perangkat.
Menampilkan
isi di balik menu navigasi
kini sangat direkomendasikan di Android 10
Kami tidak bilang ini wajib, 
tetapi sebaiknya Anda menerapkannya.
Sifatnya opsional sebelum Q.
Saat menjalankan perangkat
sebelum Android 10, opsional.
Tetapi banyak yang harus dilakukan

Portuguese: 
Vamos falar sobre duas coisas.
Primeiro, como ir para 
a versão ponta a ponta,
que o Chris vai explicar, e segundo,
como resolver conflitos de gestos,
que eu vou explicar.
Vou passar a fala para Chris.
Obrigado. Rohan usou o termo
ponta a ponta.
O que essa expressão
esquisita quer dizer?
Se você criar um app Android
no Studio com o modelo novo,
as bordas do app vão ficar
abaixo da barra de status
e acima da barra de navegação.
A partir de agora, queremos
que a barra de navegação
desapareça e o conteúdo
do app fique em destaque.
Quando o usuário rolar,
vai ficar assim.
O conteúdo rola atrás
da barra de navegação
chegando até a borda inferior da tela.
Recomendamos exibir atrás da barra
de navegação no Android 10.
Não é obrigatório, mas é algo
que vocês devem considerar.
É opcional antes da versão Q,
em dispositivos anteriores ao Android 10.
Mas muito do trabalho para usá-lo

Korean: 
이 부분에서는 두 가지를 말할 겁니다
첫째는 Going Edge-to-Edge으로
크리스가 설명할 것이고,
둘째는 제스처와 앱의 충돌을 처리하는 법으로
제가 설명해드릴 겁니다
좋습니다
이제 순서를 크리스에게 넘기죠
고마워요, 로한
자, 방금 로한이 Edge-to-Edge라는 말을 했습니다
다소 이상해 보이는 용어인데
정확히 무슨 뜻일까요?
여러분이 Android 스튜디오의 새 템플릿을 사용해서
Android 앱을 만든다고 가정하죠
앱의 가장자리는 상태 바 아래와
내비게이션 바의 위입니다
저희가 Edge-to-Edge로 이루고 싶은 것은
내비게이션 바가 사라지고 앱 콘텐츠가
내비게이션 바 자리까지 차지하는 것이죠
스크롤하면 이런 모습이 될 겁니다
내비게이션 바가 있던 자리에도 콘텐츠가 들어갑니다
기기 화면의 가장 밑 부분도 앱 콘텐츠를 표시하죠
그래서 Android 10에서는 내비게이션 바 자리까지
콘텐츠를 표시하는 걸 적극적으로 권장합니다
필수 사항은 아니지만
여러분은 그렇게 하는 것도 고려하셔야 합니다
Android 10 이전 버전까지는
선택 사항이었죠
Android 10에 적용하기 위해 해야 할 작업이 많지만

Japanese: 
今日は２つの点を説明します
１つ目はエッジツーエッジについてで
クリスが説明します
２つ目はジェスチャーの競合の処理方法で
私が説明します
まずクリスからです
ローハンがエッジツーエッジと言いましたが
実際何を意味するのでしょうか？
新しいテンプレートを使って
Android Studioで
アプリを作成すると
アプリの境界はステータスバーの下
そしてナビゲーションバーの上にきます
エッジツーエッジ化では
ナビゲーションバーが隠れて
アプリのコンテンツが
透けて表示され スクロールすると
ナビゲーションバーの背後で
画面の下部に向かって
引き込まれていきます
Android 10では
ナビゲーションバーの背後に描画することを
推奨します
必須ではありませんが
ご検討ください
Q以前はオプションです
Android10以前のデバイスでは
オプションです

Spanish: 
Aquí, hablaremos de dos cosas.
La primera es 
cómo trabajar de borde a borde
que explicará Chris,
y la segunda
será sobre cómo
manejar conflictos con gestos,
de la cual me encargaré yo.
Genial.
Los dejo con Chris.
Gracias, Rohan.
Rohan acaba de mencionar
el término borde a borde.
Es un término algo raro.
Entonces, ¿qué significa?
Si crean una aplicación de Android
con Android Studio y la plantilla nueva
obtendrán algo como esto,
donde los límites de su aplicación
están debajo de la barra de estado y
encima de la barra de navegación.
Ahora, lo que queremos con borde a borde
es que la barra de navegación desaparezca
y el contenido de la aplicación
se vea atrás, para que cuando
el usuario se desplace
se parezca algo a esto...
su contenido desplazándose
detrás de la barra de navegación,
abajo de la pantalla del dispositivo.
Dibujar atrás de la barra
de navegación
es recomendable en Android 10.
No es obligatorio
pero deberían considerarlo seriamente.
Si se ejecuta en dispositivos
con versiones anteriores a Q,
antes de Android 10, es opcional.
Gran parte del trabajo necesario

English: 
There are two things that
we'll be talking about here.
The first one will be
going edge-to-edge,
which Chris will go
into, and the second one
will be handling
gesture conflicts, which
I'll take over.
Cool.
So I'm going to hand
it over to Chris.
CHRIS BANES: Thanks, Rohan.
So yeah, so Rohan just
mentioned the term edge-to-edge.
Now, it's a kind of weird term,
so what does he actually mean?
So by this, if you create
an Android app using
Android Studio using
the new template,
you'll get something like this,
where the bounds of your app
are below the status bar and
above the navigation bar.
Now, what we want going forward
with edge-to-edge is for that
navigation bar to disappear and
for your app's content to shine
through behind it, so that
when the user scrolls,
it looks a bit like this--
your content scrolling
behind the nav bar,
drawing right to the bottom
of the device screen.
So drawing behind
the navigation bar
is now strongly
recommended on Android 10.
We're not saying it's
mandatory, but really, you
should be looking at doing it.
It's optional before Q.
When you run on the devices
before Android
10, it's optional.
But a lot of the
work you need to do

Spanish: 
para que funcione para Android 10
se aplica a versiones anteriores.
Es su elección, pero, de cierto modo,
ya lo pusieron en práctica.
Para la parte superior de la pantalla
queremos algo similar,
donde el fondo de la barra de estado
desaparezca y permita
que el contenido brille.
Algo diferente aquí… nuevamente,
el contenido que se
muestra atrás mientras se desplazan,
pero las recomendaciones
no son muy sólidas.
Y depende del tipo
de contenido que tengan.
Si suelen tener muchas imágenes
arriba de la pantalla, funcionará.
Si solo tienen listas de cosas,
probablemente no.
Nuevamente, es opcional
para versiones anteriores a Q.
Hablamos sobre qué es borde a borde.
Ahora, hablemos sobre
cómo realmente llegamos allí.
Hay 3 pasos para trabajar 
de borde a borde,
que explicaremos ahora.
El primero es cambiar
los colores de la barra del sistema.
Lo primero que deben saber
es que Android 10 les ayudará 
de ahora en adelante.
Aquí, pueden ver que
mientras el usuario se desplaza
la barra de navegación
detrás cambia de color

Korean: 
새 버전이 나오기 전에 적용할 수 있으니
선택은 여러분의 몫이지만
여러분은 이미 열심히 작업하고 계실지도 모릅니다
마찬가지로 화면 가장 위쪽에는
배경의 상태 바를 없애고
그 자리를 앱 콘텐츠가 대신하는 식으로 나타내려고 합니다
약간 다른 점이 있는데
화면을 스크롤하면 뒤에 콘텐츠가 보입니다
하지만 권장하는 정도에는 미치지 못하죠
그리고 이것은 여러분의 콘텐츠 유형에 따라 달라집니다
화면 위쪽 근처에 이미지가 많다면
잘 어울리겠지만
아이템 목록이 많다면 그렇지 않겠죠
다시 말씀드리지만
Android 10 이전에는 선택 사항이었습니다
방금 Edge-to-Edge가 무엇인지 알아보았으니
이제 어떻게 구현하는지 이야기해보죠
Going Edge-to-Edge의 주요 단계는 세 가지입니다
순서대로 살펴볼 건데요
첫째는 시스템 바 색상 변경입니다
우선 Android 10 시스템이
수정 작업을 도와준다는 점을 알려드립니다
사용자가 화면을 스크롤하면
뒤의 내비게이션 바 색상이
보이는 콘텐츠에 따라
달라지는 것을 볼 수 있습니다

Japanese: 
Android 10で動作させるために必要な
多くの作業は
以前のバージョンにも適用できます
同様に画面の上部でも
ステータスバーの背景が消えて
コンテンツが透けて見えるようにしました
少し違うのは
スクロールするとコンテンツが
背後に表示されますが
そこまで強く推奨しません
コンテンツの種類によります
画面上部に多くの画像がある場合は
良いですが
項目のリストだとイマイチです
これもQ以前ではオプションです
エッジツーエッジについて話したので
実際にどうやるのか説明します
エッジツーエッジ化には３ステップあります
１つ目はシステムバーの色の変更です
Android 10のように
システムが先に進むのを手助けしてくれます
ここでユーザーがスクロールすると
後ろのナビゲーションバーの色が
コンテンツに応じて変化し

Indonesian: 
agar berfungsi di Android 10
juga berlaku di versi sebelumnya.
Itu adalah pilihan Anda,
tapi cepat atau lambat
Anda akan mengerjakannya.
Sama halnya untuk bagian atas,
kami ingin
latar belakang status bar hilang
sehingga konten Anda makin menonjol.
Ada yang sedikit berbeda di sini--
konten terlihat 
di belakang saat Anda men-scroll,
tetapi tidak terlalu disarankan.
Dan semuanya bergantung jenis konten Anda.
Jika konten punya banyak gambar
di dekat atas layar, gunakanlah.
Jika hanya daftar item, sebaiknya jangan.
Sekali lagi, ini bersifat
opsional untuk sebelum Q.
Barusan kita membahas tepi ke tepi.
Kini mari kita bahas
cara menerapkannya.
Jadi ada tiga cara
untuk menerapkannya,
akan dijelaskan satu-satu.
Pertama adalah
mengubah warna kolom sistem.
Yang harus diketahui dahulu adalah sistem,
dalam konteks ini sistem Android 10,
akan membantu Anda ke depannya.
Anda dapat melihat
saat pengguna men-scroll,
menu navigasi di belakangnya berubah warna
sesuai isi di belakang,
memungkinkan pengguna

Chinese: 
不过 你需要在 Android 10 版本中做的很多工作
在更早些的版本中也适用
所以 虽然这个功能只是可选功能 
但你可能在之前的版本里已经把该做的工作都做好了
与此类似 在屏幕顶端 我们也要做类似的事情
状态条背景消失 让你的内容显示出来
只做出了一点细微的色差
内容会在你滚动的时候在背景中显示出来
但是我们没那么强推这个功能
具体要取决于你的内容是什么样的
如果你在屏幕顶部附近有很多图片 这样做就行得通
如果你只是有一些物品清单的话 就未必好用了
这些在 Q 版本之前都是可选的
刚才我们谈了“边到边”的含义
现在我们来谈谈我们是如何做到这一点的
实现“边到边”主要包含3个步骤
下面我们来逐一讲解
第一 更改系统栏颜色
首先 Android 10 系统会帮你做到这个
大家可以看到 随着用户的拖动
它后方导航条的颜色会根据它后面的内容而改变

Portuguese: 
no Android 10 também
vale para versões anteriores.
É opcional, mas você vai
ter que fazer de qualquer forma.
Na borda superior da tela
é igual. A barra de status vai sumir
e seu conteúdo vai ficar em destaque.
Um pouco diferente aqui...
O conteúdo aparece atrás quando você rola,
mas a recomendação não é tão forte.
Depende do tipo de conteúdo.
É bom quando há muitas imagens
na parte superior da tela.
Quando só há listas de itens, nem tanto.
É opcional antes do Q.
Explicamos o que é borda a borda.
Agora vamos explicar como fazer.
Existem três etapas
para usar o ponta a ponta.
que vamos ver agora.
Primeiro, mudar as cores
da barra do sistema.
O sistema vai ajudar vocês
a partir do Android 10.
Vejam que quando o usuário rola,
a barra de navegação atrás muda de cor
com base no conteúdo, para que o usuário

English: 
to make it work for Android 10
is also applicable before that.
So it's your choice, but you
kind of already put in the work
anyway.
Similarly, for the
top of the screen,
we just want something similar,
where the status bar background
disappears, again allowing
your content to shine through.
Slightly different
here-- oh again,
the content showing
behind as you scroll,
but the recommendation's
not quite as strong.
And it depends on the
type of content you have.
If you tend to have
a lot of imagery
near the top of the
screen, it works.
If you just have lists
of items, probably not.
Again, optional before Q.
So we just talked about
what edge-to-edge is.
Now, let's talk about how
we actually get there.
So there's three main steps
to going edge-to-edge, which
we'll go through now in turn.
The first one is changing
the system bar colors.
So the first thing to know
is that the system, as
in Android 10, the system,
will help you going forward.
So here, you can see
that as the user scrolls,
the navigation bar behind it
is actually changing color
based on that content
behind, allowing the user

Indonesian: 
melihat dengan jelas
menu di balik konten yang gelap.
Inilah yang kami sebut
dengan adaptasi warna dinamis.
Ini salah satu bentuk perlindungan
untuk konten,
yang disediakan sistem untuk Anda.
Tipe kedua adalah layar transparan,
yang dapat dilihat di bagian bawah.
Jadi saat pengguna
men-scroll, ada latar belakang transparan
di balik navigasi untuk melindungi isi,
jadi pengguna dapat lihat isi di baliknya.
Sekarang, ini terlihat di mode tombol.
Jika perangkat diatur ke mode tombol,
inilah yang terlihat.
Tapi satu hal yang penting
adalah layar transparan
hanya akan terlihat
jika SDK target 29 ke atas.
Ini juga salah satu alasan mengapa Anda
harus mulai menguji di semua mode navigasi
dan di berbagai level API.
Kita juga harus beri tahu sistem bahwa
kita ingin mengubah warna kolom sistem.
Anda sebagai aplikasi
dapat mengatur warna tersebut,
dan secara default, warna utama menu
navigasi adalah warna gelap atau hitam.
Untuk melihat isi di belakangnya,

Portuguese: 
veja a barra atrás do conteúdo escuro.
Isso é adaptação de cor dinâmica.
É uma das proteções de conteúdo
que o sistema oferece a vocês.
O segundo tipo é a tela translúcida,
que está aqui na parte inferior.
Quando o usuário rola a tela,
há um fundo translúcido
atrás da barra protegendo o conteúdo,
para o usuário conseguir ver.
Isso é exibido no modo de botão.
Com o celular no modo de botão,
só isso é exibido.
Mas a tela translúcida só aparece
quando o SDK de destino é 29 ou superior.
Por isso é necessário
testar em todos os modos de navegação
e vários níveis de API.
Também é preciso informar ao sistema
que as cores da barra vão mudar.
Vocês, os apps, controlam a cor.
Por padrão, a cor é escuro ou preto
na barra de navegação.
Para ver o conteúdo atrás,

Chinese: 
从而让用户看清内容上的导航条
我们把这个功能称为“动态色彩适应”
这是系统提供的用来保护内容的一种方式
第二个类型是位于底部的半透明蒙层
随着用户的拖动 导航栏后面会出现一个
半透明的背景蒙层 来保护内容
让用户能够看清
这是选择按钮模式后才会出现的现象
设备被设置为按钮模式
显示出来的结果就是这样
但是这件事给我们的启发在于
半透明屏幕只有在你的目标 SDK 为29或更高的时候才会显示
所以 你需要针对所有导航模式以及各种 API 等级进行测试
我们还需要让系统得知 我们想要更改系统栏的颜色
应用本身可以控制这个颜色
在默认状态下 它会在导航栏上使用 
color primary dark 或 black 
为了看清它后面的内容
我们需要告知系统 我们希望它是半透明的

Japanese: 
コンテンツの背後にバーが表示されます
これがダイナミックカラーアダプションです
これはシステムが提供する
コンテンツの保護形式の１つです
２つ目のタイプは半透明のスクリーン用で
これは下部にあります
ユーザーがスクロールすると
ナビゲーションバーの背後に
半透明の背景が表示され
コンテンツを保護します
端末がボタンモードに設定されていると
これが表示されます
１つの注意が必要なのは
ターゲットSDKが29以上の場合のみ
半透明の画面が表示される点です
これが すべてのナビゲーションモードと
様々なAPIレベルで
テストをする必要がある理由の１つです
システムバーの色を変更することを
システムに伝える必要もあります
アプリはその色を制御しており
デフォルトではナビゲーションバーは
暗色または黒です
背後のコンテンツを見るには

English: 
to actually see that bar
behind that dark content.
That is what we call
dynamic color adaption.
So that's one of the
forms of protection
for the contents, which the
system provides for you.
The second type is for
translucent screen, which
you can see here at the bottom.
So as the user scrolls, there's
like a translucent background
behind the navigation bar
to protect the content,
allowing the user to see it.
Now, this is shown
on button mode.
So if the device is
set to button mode,
this is all that is shown.
But the one gotcha to this is
that the translucent screen
will only be shown if your
target SDK is 29 or above.
So this is one
reason that you also
need to start testing
on all navigation modes
as well as different API levels.
We also then need to tell
the system that we actually
want to change our
system bar colors.
You as apps are in
control of that color,
and by default, it goes to
color primary dark or black
for navigation bar.
So to actually see
that content behind,

Korean: 
사용자는 여기서 바 뒤의 어두운 콘텐츠도 볼 수 있죠
이것을 동적 색상 적응이라고 합니다
이것은 시스템이 제공하는
콘텐츠 보호의 한 형태입니다
다음 유형은 반투명 화면입니다
지금 아래쪽에서 보이는 기능인데요
사용자가 화면을 스크롤하면
내비게이션 바 뒤에 있는 배경이
반투명으로 변하면서 콘텐츠를 보존해줍니다
이 기능은 화면 아래에서 나타나므로
기기가 내비게이션 모드를 버튼으로 설정하면
보이는 것은 이게 전부입니다
하지만 반투명 화면은 대상 SDK가
29 이상일 때만 보인다는 사실을
명심하셔야 합니다
이것이 바로 여러분이 
모든 내비게이션 모드를 비롯해
추가로 서로 다른 API 수준도
시험해야 하는 까닭이죠
그리고 우리는 시스템에
우리가 시스템 바 색상을 변경하고 싶다는 사실도
알려주어야 합니다
기본적인 내비게이션 바 색상은 보통 짙거나
검은색이죠
그래서 바 뒤로 콘텐츠를 보려면

Spanish: 
con base en el contenido,
lo que le permite al usuario
ver la barra detrás del contenido oscuro.
Eso es lo que llamamos
adaptación de color dinámica.
Esa es una de las formas de proteger
el contenido, que el sistema les brinda.
El segundo tipo es la pantalla traslúcida,
que pueden ver en la parte inferior.
Mientras el usuario se desplaza,
hay un fondo traslúcido
detrás de la barra de navegación
para proteger el contenido
y permitir al usuario verlo.
Esto se muestra
en el modo de botones.
Si el dispositivo está en ese modo
esto es todo lo que se muestra.
Un reproche a esta función
es que la pantalla traslúcida
solo se mostrará si el
SDK de destino es superior a 29.
Esta es otra razón de por qué
deben hacer pruebas
en todos los modos de navegación
y diferentes niveles de API.
También debemos decir
al sistema que queremos
cambiar los colores de la barra.
Las aplicaciones controlan ese color
y, por defecto, la barra de
navegación está en negro
o un color primario oscuro.
Para ver ese contenido de fondo,

Korean: 
시스템에 바를 투명하게 해야 한다고 알려주어야 합니다
이것은 navigationBarColor 속성에서
바꿀 수 있습니다
그리고 저희가 Android 10에 대해서만
이야기하므로
이 부분을 강력히 추천합니다
폴더에는 값을 values-v29로 설정했지만
Android 10 이전도 지원한다면
예전 값을 사용해야 할 수도 있습니다
이제 Android 10 이전 버전의 경우는
시스템에 배경 보호 책임이 없기 때문에
직접 설정해주어야 합니다
이 부분을 반투명 색상으로 설정하면 되죠
보통 밝은 테마일 때는 흰색 반투명으로 설정하고
어두운 테마에서는 검정 반투명으로 대신 사용하면
될 것입니다
설정값은 70%로 시작하면 무난하지만
이는 앱 콘텐츠에 따라 달라질 수 있죠
앱이 이미지를 많이 포함한다면
알파 값을 올려야 할 겁니다
반대로 글씨가 많다면 값을 적절히 내리면 됩니다
필요한 대로 조정하시면 됩니다
두 번째 단계는 전체 화면으로 표시하도록
요청하는 것입니다
아까 말씀드렸듯이
대개 콘텐츠는 상태 바 아래와 
내비게이션 바 위에 나타나며
우리는 콘텐츠가
기기 화면의 세로 높이 전체에 나타나게 하고 싶죠

Japanese: 
ナビゲーションバーの色属性を使用して
透過性を設定します
Android 10では
これはvalues-v29フォルダに
設定しましたが
10以前もサポートしている場合は
古い値を使用している可能性があります
Android 10以前では
システムは背景の保護を行わないので
自分でする必要があります
その際に半透明の色を使用します
明るいテーマでは通常 半透明の白を使用し
暗いテーマでは半透明の黒を使用します
70％をお勧めしますが
アプリのコンテンツによって異なります
画像がたくさんある場合
アルファ値を上げます
テキストのみの場合は問題ありませんが
必要に応じて調整してください
次は リクエストの
フルスクリーンレイアウトです
通常はステータスバーの下と
ナビゲーションバーの上に表示され
デバイス全体で
フルスクリーンにします

Spanish: 
debemos decir al sistema que
queremos que sea transparente.
Podemos hacerlo con el atributo
de color de la barra de navegación.
Como solo estamos hablando de Android 10,
que es lo que más se recomienda,
se insertó en la carpeta values-v29.
Pero, si también usan una
versión anterior a Android 10,
podrían estar usando los valores viejos.
En versiones anteriores a Android 10, 
como el sistema
no es responsable de
la protección de fondo,
deben hacerlo ustedes mismos.
Pueden lograrlo
si usan un color traslúcido.
En un tema claro, generalmente,
usarían blanco traslúcido
y, en cambio, en un tema oscuro
usarían negro traslúcido.
El 70% tiende a ser
un buen valor para comenzar,
pero depende
del contenido de la aplicación.
Si tienen muchas imágenes,
podrían tener que subir el valor alfa.
Si es solo texto, pueden bajarlo
y jugar con eso según sea necesario.
El segundo paso es que necesitan
usar la pantalla completa.
Como ya dijimos, normalmente,
se muestra debajo de la barra de estado
y sobre la barra de navegación.
Y queremos usar la altura total
del dispositivo.

Indonesian: 
beri tahu sistem bahwa
kita ingin kolom jadi transparan.
Caranya dengan
menggunakan atribut warna menu navigasi.
Karena kita hanya membahas Android 10
yang merupakan rekomendasi penting,
kita menetapkannya di folder values-v29,
tetapi jika Anda juga
mendukung OS sebelum Android 10,
Anda mungkin perlu nilai lama.
Sebelum Android 10, karena sistem
tidak berkewajiban untuk
melindungi latar belakang,
Anda harus melakukannya sendiri.
Dan Anda dapat
melakukannya dengan warna transparan.
Pada tema terang, warna yang
biasanya digunakan warna putih transparan
sedangkan di tema gelap,
yang biasa digunakan
adalah warna hitam transparan.
70% cenderung jadi nilai
transparansi yang bagus untuk memulai,
tetapi semuanya
bergantung konten di aplikasi.
Jika gambarnya banyak,
Anda harus menaikkan nilai alfa.
Jika hanya teks, turunkan nilainya,
atur sesuai kebutuhan.
Langkah kedua. Permintaan harus
ditampilkan dalam layar penuh.
Seperti yang kami jelaskan sebelumnya,
biasanya tampilan di bawah status bar
dan di atas menu navigasi,
dan kita ingin aplikasi terlihat jelas
sesuai ukuran layar perangkat.

English: 
we need to tell the system that
we want it to be transparent.
We can do that using the
navigation bar color attribute.
Now, because we're only talking
about really Android 10 here
and that's the strong
recommendation,
we've set it in our
values-v29 folder,
but if you're supporting back
to pre-Android 10 as well,
you might be using
the old values.
Now, before Android
10, because the system
isn't responsible for that
background protection,
you need to do it yourself.
And you can do that using
a translucent color.
In your light theme, you'd use,
typically, a translucent white,
and on your dark theme,
you'd use a translucent black
instead.
70 percent tends to be a
good value to start from,
but it depends on the content
that you have in your app.
If you have a lot
of imagery, you
might need to bump
that alpha value up.
If it's just text, you
can appropriate it down,
but play with it as you need.
The second step is that
you need the request
to be laid out fullscreen.
As we said earlier,
normally, it would
be displayed below
the status bar
and above the
navigation bar, and we
want to go full bleed into
the whole device height.

Chinese: 
我们可以使用 navigationBarColor 来做到这一点
我们在这里讨论的其实只涉及 Android 10 系统
我们强烈推荐大家使用 Android 10
我们在 values-v29 文件夹中设置了它
不过 如果你支持 Android 10 之前的版本
那么你可以使用旧值
在 Android 10 之前 
系统不负责保护背景
所以这部分工作需要你自己来做
你可以使用半透明颜色来解决这个问题
在浅色主题中 通常可以使用半透明白色
在深色主题中 通常可以使用半透明黑色
你可以先从70%值开始
不过这要取决于你的应用中的内容
如果你有很多图片内容
那么你可能需要提高 alpha 值
如果你的内容全都是文本 你可以适当降低这个值
根据情况采取适合自己的做法就好
第二步是 你需要把这个细节也体现在全屏上
我们之前说过 通常它会显示在
从状态栏下方到导航栏上方的位置
而我们希望它填满整个设备的屏幕高度

Portuguese: 
é preciso deixar essa parte transparente.
Podemos usar o atributo de cor
da barra de navegação.
Como estamos falando de Android 10 aqui
e recomendamos o uso dele,
configuramos na pasta values-v29.
Se for compatível
com versões anteriores também,
talvez você use os valores antigos.
Antes do Android 10, o sistema
não é responsável pela proteção do fundo,
então cabe a você fazer.
Você pode usar uma cor translúcida.
Em um tema claro,
use um branco translúcido.
Em um tema escuro,
use um preto translúcido.
70% é um bom valor para começar,
mas depende do conteúdo do app.
Se houver muitas imagens,
aumente o valor de alfa um pouco.
Se for só texto, pode diminuir.
Vá testando para ver.
A segunda etapa é solicitar
o modo de tela cheia.
Como dissemos, normalmente, o app
fica atrás da barra de status
e acima da barra de navegação.
Queremos usar toda a altura do celular.

Spanish: 
Vamos a usar un set de API
systemUIVisibility
que ha existido por muchos años
usando 3 marcas especiales.
Está Layout_Hide_Navigation
que le dice al sistema
que la disposición debe ser
como si la barra de navegación
no estuviera allí.
Los resultados se muestran atrás.
La segunda es Layout_Fullscreen,
que es similar, excepto que se refiere
a la barra de estado.
Y está la marca especial
Layout_Stable.
Voy a señalar los documentos
y veremos qué hace de especial la marca
pero el conjunto de API 
para ver la IU del sistema,
necesita muchas marcas.
Y esto puede afectar el funcionamiento.
La moraleja es que
estas tres marcas especiales
son las que necesitan usar.
Entonces, ya fuimos desde esto
al algo como esto.
Pueden ver que el Botón de acción flotante
abajo a la derecha
ahora se muestra detrás de la barra
de navegación, lo que no está bien.
Eso nos lleva al paso 3, que es evitar
superposiciones en la IU.

Indonesian: 
Kita akan gunakan API visibilitas
UI sistem yang ditetapkan,
yang sudah ada selama bertahun-tahun,
menggunakan tiga flag khusus.
Terdapat layout hide navigation,
yang memberi tahu
sistem bahwa kita ingin tampilan
seakan-akan menu navigasi tidak ada.
Jadi menu navigasi sembunyi di baliknya.
Yang kedua adalah layout fullscreen,
ini serupa tapi untuk bagian atas layar,
status bar.
Dan ada flag khusus bernama layout stable.
Saya akan tunjukkan di dokumen dan
melihat apa fungsi
flag khusus ini, tetapi API,
yaitu API visibilitas UI sistem
yang ditetapkan, butuh beberapa flag.
Dan ini dapat
memengaruhi performanya, coba lihat.
Intinya, tiga flag khusus
inilah yang Anda butuhkan.
Setelah berhasil melakukannya,
hasilnya dari ini, menjadi ini.
Anda dapat lihat FAB--
Tombol Tindakan Mengambang
di kanan bawah--
kini ditampilkan di balik menu navigasi,
dan ini tidak bagus.
Dan ini membawa kita
ke langkah ketiga, yakni
menghindari
tumpang tindih dengan UI sistem.

Japanese: 
UIの可視性を設定するAPIを使用します
このAPIは長年３つの特別なフラグを
使用してきました
レイアウト非表示ナビゲーションがあり
これがシステムに
ナビゲーションバーを非表示にしたいと伝えます
２つ目はフルスクリーンレイアウトです
似ていますがこれは画面上部に
ステータスバーがあります
レイアウト固定というフラグがあります
詳細はDocsをご覧ください
APIは
システムUI可視性APIの設定同様
いくつかのフラグを使います
これは機能に影響を与えます
ポイントはこれら３つの
特別なフラグを使用する必要があることです
さて 次です
右下の
フローティングアクションボタンが
ナビゲーションバーの後ろに表示されていますが
これはよくないです
そこでステップ３に移ります
システムUIとの重複を避けることです

Chinese: 
我们会使用 systemUiVisibility API
这个 API 已经出现了很多年 使用3个特别的值
这个 LAYOUT_HIDE_NAVIGATION
告诉系统：我们想要完全地展开 就像是导航栏不存在一样
它后面的东西就是它的结果了
第二个是 LAYOUT_FULLSCREEN
情况类似 但针对屏幕顶端的状态栏
还有一个特殊的 flag 名为 LAYOUT_STABLE
请大家去相关文档中查看这个特殊设置值的作用
这套 systemUiVisibility API 有很多这种值供选择
它会影响最终运行效果 请大家看看吧
值得留意的是 这三个特殊值是你需要使用的
做完这个之后 我们就从这样 变成了这样
大家可以发现 位于底部右侧的悬浮操作按钮 (FAB)
现在显示在导航栏后面 这可不太好
讲到这里 正好来谈谈第三步
也就是避免和系统 UI 重叠
因此 我们要来谈谈 Inset

Portuguese: 
Vamos usar a
API UI Visibility que existe,
há muitos anos no sistema,
usando três sinalizadores especiais.
O sinalizador "layout hide navigation"
configura o layout como se a barra
de navegação não existisse.
O resultado fica atrás.
O sinalizador "layout fullscreen"
faz o mesmo na borda superior da tela,
na barra de status.
E o sinalizador especial "layout stable".
Vocês podem ver o que ele faz
na documentação.
API UI Visibility, que vem no sistema,
aceita vários sinalizadores.
E eles podem afetar a aparência.
O mais importante aqui é usar
esses três sinalizadores especiais.
Então o app passa disto...
...para isto.
Mas agora o botão
de ação flutuante, ou FAB,
no canto inferior direito,
aparece atrás da barra de navegação,
o que não é legal.
A etapa três é evitar sobreposições
na IU do sistema.

Korean: 
이 부분은 꽤 오래된 기능인
System UI 가시성 API의
세 가지 플래그를 사용할 겁니다
여기에는 LAYOUT_HIDE_NAVIGATION이 들어가는데
이 구문은 시스템에 내비게이션 바가 없는 것처럼 표시해달라고
요청하는 역할입니다
그래서 바 뒤에 내용이 표시되는 거죠
두 번째 플래그는 LAYOUT_FULLSCREEN입니다
상단의 상태 바에 적용하는 것 말고는
내용이 비슷합니다
그리고 LAYOUT_STABLE이라는
특별한 플래그가 있습니다
이 특별한 플래그가 어떤 역할을 하는지
문서에서 보여드리겠습니다
하지만 설정 시스템 UI 가시성 API에는
플래그가 많이 들어갑니다
그리고 이는 동작 방법에도 영향을 미치죠
같이 보겠습니다
여기서 기억할 핵심 사항은
여러분이 세 가지 특별한 플래그를
꼭 사용해야 한다는 점입니다
이 과정이 끝나면 화면은 이렇게
달라집니다
오른쪽 밑에 떠 있는 액션 버튼(FAB)이
지금은 내비게이션 바 뒤에
나타나는 것이 보이실 텐데요
썩 보기 좋지 않습니다
여기서 셋째 단계에 접어듭니다
시스템 UI와 겹치는 것을 피하는 작업이죠

English: 
We're going to use a set
system UI visibility API, which
has been around for
many, many years,
using three special flags.
There's layout hide
navigation, which
tells the system that
we want to be laid out
as if the navigation
bar wasn't there.
So behind it is
what it results in.
The second one is
layout fullscreen,
and that's a similar
story but for the top
of the screen, the status bar.
And there's a special flag
called a layout stable.
I'll point you to
the docs and look
at what this special
flag does, but the API,
as in the set system
UI visibility API,
takes a number of flags.
And it can affect how it
works, so have a look.
But the key takeaway
from this is
that these three special flags
are what you need to use.
So once we've done that, we
go from this to something
like this.
But you can see that the FAB--
the Floating Action Button
in that bottom right--
is now being displayed
behind the navigation
bar, which isn't great.
And that leads them to step
three, which is avoiding
overlaps with the system UI.

Chinese: 
很多开发者都非常害怕 inset 这个说法
简单地讲 inset 就是一系列值 用来告诉你如何把其他东西移进来
inset 的反面就是安全区
会移动哪些东西 取决于 inset 的类型
我们有很多类型 下面来为大家介绍一下
我们还会介绍 应该如何使用它们 如何进行应用更改
那么 我们来一一说明一下
第一个叫做系统窗口 inset
它们从 API1 的时候就开始在框架中可用了
很久之前的事
它会告诉你
系统 UI 会在你的应用上显示在屏幕上的什么位置
按照字母表顺序
它们的用途通常是将可点击的视图移开
在我们之前谈过的一个 FAB 例子中 
通常看起来会是这样的
在右下角这里有一个 FAB
通常会有 16dp 的空白 如图表示
可以看到 它有一小部分和导航栏重叠
虽然这不算太难以接受 但仍然不够好

Spanish: 
Eso nos lleva al tema de inserciones.
Las inserciones tienden a infundir miedo
a los desarrolladores.
En su mayor simpleza,
son un conjunto de valores que
les dice cómo mover algo.
Lo contrario a una inserción
sería un área segura,
y lo que el contenido mueve
depende de la inserción.
Hay diferentes tipos
y los explicaremos ahora
junto a cómo se usan
y cómo se aplican cambios.
Empecemos.
El primer paso son las
inserciones de ventanas del sistema
que han estdo disponibles desde API 1…
son muy antiguas…
y les dicen en qué parte de la pantalla
se muestra la IU del sistema
como en el orden z.
Por lo general, se usan
para apartar vistas cliqueables.
Entonces, en el ejemplo
que mencionamos sobre FAB,
generalmente tenemos esto.
Aquí, abajo a la derecha,
tenemos un FAB
y, generalmente,
tienen un margen de 16 dps
que están señalando las flechas.
Aquí, pueden ver 
que la barra de navegación
se superpone levemente, y aunque
no es el fin del mundo,
tampoco está bien.

Korean: 
그리고 여기서 인셋이 등장합니다
개발자들은 인셋을 두려운 마음이 들게 하는
용어로 간주합니다
인셋은 간단하게 말하면
여러분에게 물체를 어떻게 움직일 것인지
말해주는 값의 모음입니다
인셋의 반대말은 안전지대이죠
그리고 이동할 콘텐츠는 인셋 유형에 따라 달라집니다
수많은 유형이 있는데 이것들을 어떻게 사용하고
변화를 적용할 것인지 함께 보겠습니다
같이 보시죠
첫 번째 단계는 시스템 윈도우 인셋입니다
API 1부터 프레임 워크에서 사용한
아주 오래된 인셋으로
앱 위에 표시할 시스템 IO를 z 순서로
화면 어디에 나타낼 것인지
말해줍니다
이 인셋은 보통 클릭할 수 있는 뷰를
치우는 데 사용하죠
이 FAB 예시를 보면 말씀드렸지만
보통 이런 게 있습니다
오른쪽 밑에 FAB이 있는데
화살표가 나타내는 것처럼
Margin의 16dps 정도로 되어 있습니다
여길 보면 화살표가
내비게이션 바를 살짝 걸치고 있는데
중요한 건 아니지만 보기 좋지 않죠

Indonesian: 
Oleh karena itu, kita akan membahas inset.
Inset adalah istilah
yang cenderung membuat
para developer ketakutan.
Sebenarnya inset hanya
kumpulan nilai yang memberi tahu Anda
seberapa jauh harus memindahkan sesuatu.
Kebalikan dari inset adalah area aman.
Konten yang dipindahkan
tergantung tipe inset.
Kita akan bahas beberapa tipe,
beserta cara menggunakannya
atau cara menerapkan perubahannya.
Mari kita mulai.
Langkah pertama: inset jendela sistem.
Sudah ada di framework kira-kira sejak
API 1--
sangat, sangat lama--inset ini
memberi tahu di bagian layar yang mana
posisi UI sistem di atas aplikasi Anda,
berdasarkan urutan z.
Biasanya dipakai untuk
memindahkan tampilan yang dapat diklik.
Jadi contoh FAB yang kita bahas tadi,
kita akan melihat ini.
Di sini kita punya FAB di kanan bawah,
dan margin 16 dps, yang
ditunjukkan oleh anak panah.
Seperti yang kita lihat, tombol sedikit
tumpang tindih dengan menu navigasi,
bukan error yang fatal,
tetapi ini tidak bagus.

English: 
And that brings onto
the topic of insets.
Now insets as a term
tends to strike fears
into the hearts of developers.
Insets at their
most simple are just
a collection of
values that tell you
how to move something in by.
The inverse of an inset
would be like a safe area.
And what contents move
depends on the inset type.
We have a number of types,
which we'll go through now,
and how you use or how you
actually apply them changes.
So let's go through them.
The first step is called
system window insets.
Now, these have been available
in the framework since
about API 1--
very, very old-- and they
tell you where on screen
that the system UI is being
displayed above your app,
as in in the z order.
They are typically used to move
clickable views out of the way.
So that FAB example
we spoke about earlier
we typically have this.
So here, we've got a
FAB at the bottom right,
and you typically have 16
dps of margin on it, which
are denoted by the arrows.
Now, you can see here
that it's slightly
overlapping the
navigation bar, which
isn't the end of the
world but it's not great.

Portuguese: 
Isso nos traz ao tema dos insets.
O termo costuma causar medo
aos desenvolvedores.
Insets são apenas uma coleção
de valores que determinam
como inserir algo.
O contrário do inset
é a área de segurança.
O tipo de inset determina
o conteúdo movido.
Vamos ver vários tipos de inset
e como usá-los para aplicar mudanças.
Vamos lá.
Primeiro, insets de janela do sistema.
Eles estão disponíveis na estrutura
desde a API...
Muito antigos. Informam onde na tela
a IU do sistema é exibida
acima do app no eixo z.
Servem para mover exibições clicáveis.
No exemplo do FAB que vimos antes,
geralmente é assim.
Há um FAB no canto inferior direito.
Ele tem 16 dps de margem, como indcam
as setas.
Ele está um pouco
acima da barra de navegação.
Não é grave, mas não é legal.

Japanese: 
トピックはインセットについてです
インセットという言葉は開発者に
恐怖を呼び起こす傾向があります
最も単純なインセットは
何をどう移動させるかを示す
値の集合です
インセットの逆は安全な領域です
移動するコンテンツは
インセットの種類によって違い
様々な種類があります
使用方法と実際の変更の適用方法を説明します
見てみましょう
まず初めは システムウィンドウインセットです
これはAPI 1以降の
フレームワークで利用でき
zオーダーのように
アプリの上のシステムUIが
表示されている場所を示します
クリック可能なビューを移動するために
使用します
先ほどのFABの例では
通常これがあります
右下にFABがあり
通常16 dpsの余白があります
これは矢印で示されています
ここで ナビゲーションバーと
わずかに重なっています
ダメではないけど良くもありません

Chinese: 
我们想把它向上移动 让这个 FAB 远离导航栏
在按钮模式中 它看起来会更加明显 如大家所见
因为在这里 FAB 几乎完全和导航栏重叠了
而用户无法点到它
所以 我们需要把它往上移动
这里使用的工具正是系统窗口 inset
这就是你使用的值
下一个 inset 类型叫做系统手势 inset
这是 Android 10 中才出现的东西
它代表着 在窗口的某个区域中
也就是 Rohan 之前提到过的区域中
系统手势会覆盖你应用里的操作
视觉上 它看起来有点像这个
在竖直边缘 我们拥有返回手势
所以 当你在这里从左或从右开始滑动的时候
后退箭头会出现 用户就可以后退了
用户还可以从屏幕底部向上滑动返回主屏幕
至于用途 它们通常的用途就是
把可拖动的视图移到安全的地方
稍后我们再举一个这方面的例子

Portuguese: 
Vamos mover para cima, para o FAB ficar
longe da barra.
É mais evidente no modo de botão.
Vejam aqui.
O FAB está totalmente escondido
pela barra de navegação.
O usuário não pode clicar nele.
O botão vai subir um pouco.
Vamos usar insets de janela do sistema.
Vamos usar esse valor.
Próximo tipo, insets de gesto do sistema.
São novidade do Windows 10 e representam
as áreas da janela
em que os gestos do sistema,
que Rohan mencionou antes,
têm prioridade sobre o app.
Eles são assim.
Nas bordas verticais, há o gesto "voltar".
Quando o usuário
desliza para um dos lados,
a seta aparece e ele pode voltar.
Ou ele passa o dedo para cima
para ir para o início.
Costumam ser usados para
mover exibições arrastáveis.
Vamos ver um exemplo depois.

Japanese: 
上に移動して
FABをナビゲーションバーから離します
ご覧の通りボタンモードではFAB全体が
ナビゲーションバーと
ほぼ重なり合っているため
ユーザーはクリックできません
これを上に上げたいので
インセットを使用します
それが使用する値です
次のタイプは
システムジェスチャーインセットです
Android 10の新機能で
システムジェスチャーが
アプリよりも優先される
ウィンドウの領域を表します
見た目はこういう感じで
縦の端に「戻る」ジェスチャーがあり
左または右端からスワイプすると
戻る矢印が表示され
ユーザーは戻ることができます
または画面の下から上にスワイプすれば
ユーザーはホームに戻れます
これは通常ドラッグ可能なビューを
邪魔にならないよう
移動するために使用しますが
その例は後で説明します

Korean: 
우리는 FAB를 조금 위로 옮겨서
내비게이션 바에서 떨어지게 하려고 합니다
버튼 모드에서는 더 분명하게 드러납니다
FAB가 내비게이션 바에
너무 겹쳐 있어서
사용자가 클릭할 수 없기 때문이죠
그래서 FAB을 위로 올리려고 합니다
이때 시스템 윈도우 인셋을 사용할 수 있죠
여러분은 이 값을 사용하면 됩니다
다음 제스처 인셋 유형은 시스템 제스처 인셋이라고 합니다
이건 Android 10에서 새로 나온 건데
아까 로한이 말한 것처럼
시스템 제스처가 있는 윈도우 구역을 나타내며
여러분의 앱보다 우선하는 인셋입니다
화면에서는 이렇게 보입니다
세로 가장자리에는 뒤로 가기 제스처가 있죠
그래서 이를 왼쪽에서 오른쪽 가장자리로 밀면
뒤로 가기 화살표가 나타나면서 뒤로 갈 수 있습니다
아니면 화면 아래에서 위로 밀어 올리면
홈으로 돌아갈 수 있죠
여러분이 이것을 어떻게 사용하는지 보면
보통 움직일 수 있는 뷰를 치우는 데 사용합니다
이 예는 나중에 보겠습니다

Indonesian: 
Kita ingin memindahkannya ke atas
sehingga FAB
tidak tumpang tindih dengan menu navigasi.
Error ini lebih terlihat
mengganggu di mode tombol,
seperti yang kita lihat di sini,
karena hampir seluruh
bagian FAB tumpang tindih
dengan menu navigasi
dan pengguna tidak dapat mengkliknya.
Jadi, kita harus menaikkannya
dengan inset jendela sistem.
Itu adalah nilai yang akan Anda gunakan.
Tipe inset gestur
selanjutnya disebut inset gestur sistem.
Inset ini baru di Android 10, dan mewakili
area jendela tempat gestur sistem--
gestur yang dibahas Rohan sebelumnya--
diutamakan ketimbang aplikasi.
Jadi, tampilannya
kurang lebih seperti ini.
Di tepi vertikal,
kita punya gestur kembali.
Jadi saat menggeser
dari tepi kiri atau kanan,
panah akan terlihat dan
pengguna dapat kembali.
Atau, pengguna dapat membuka beranda
dengan menggeser bagian bawah ke atas.
Untuk cara penggunaannya, gestur
digunakan untuk
memindahkan tampilan yang dapat ditarik
tapi kita akan membahasnya nanti.

English: 
Really, we want to move it up
and so that the FAB is nowhere
near the navigation bar.
It's much more obvious in button
mode, as you can see here,
because the FAB is being
pretty much overlapped
by the navigation
bar in its entirety
and the user can't click on it.
So really, what we
want to do is push up.
And we do that using the
system window insets.
That's the value that you use.
The next gesture inset type is
called system gesture insets.
And now, these are new in
Android 10 and they represent
the areas of the window
where the system gestures--
the gestures that Rohan
spoke about earlier--
take priority over your app.
So visually, they
look a bit like this.
On the vertical edges,
we have the back gesture.
So as you swipe in from
the left or right edge,
the back arrow comes in
and the user can go back.
Or from the bottom
of the screen,
the user can go home by
swiping up from the bottom.
In terms of how you
use them, they're
typically used to move
draggable views out of the way,
but we'll go through an
example of that later.

Spanish: 
Querremos moverlo hacia arriba
para que el FAB no esté
cerca de la barra de navegación.
Es mucho más obvio en el modo de botones,
como pueden ver aquí,
porque el FAB está prácticamente debajo
de la barra de navegación
y el usuario no puede hacer clic allí.
Lo que querremos hacer es subirlo
con las inserciones del sistema.
Es decir, el valor que usan.
El siguiente tipo
es inserciones con gestos del sistema.
Son nuevas en Android 10 y representan
las áreas de la ventana
donde los gestos del sistema
los gestos que mencionó Rohan
tienen prioridad en su aplicación.
Entonces, visualmente, se ven así.
En los bordes verticales,
está el gesto Atrás.
Si deslizamos el dedo
del borde izquierdo al derecho,
la flecha Atrás aparece
y el usuario puede ir hacia atrás.
Desde abajo de la pantalla,
el usuario puede ir al inicio
si desliza el dedo desde abajo.
En cuanto a su uso,
se usan para sacar vistas
que se pueden arrastrar
pero veremos un ejemplo más adelante.

Chinese: 
最后一个手势系统 inset 是强制系统手势
它们是手势 inset 的子集
你通常不会直接使用它们
不过 Rohan 一会儿会告诉大家
应用会影响到手势的工作范围
你可以使用它们的 API 告知系统
我不想让它在这里运作
强制系统手势 inset 会告诉你 
这个 API 在哪里是不能用的
系统会让这些手势区域仅对用户保持可用状态
目前在 Android 10 中 
底部区域负责“返回主屏幕”这个功能
原因是 用户在想要退出时总会去操作那个区域
任何应用都不该把用户困在应用里
简要总结一下 系统窗口 inset 
可点击视图 手势 inset 可拖动视图
强制系统手势 inset 这些通常都是不需要直接使用的
我们刚刚谈了手势 inset
现在我们来谈谈如何避免遮挡现象

Japanese: 
最後に説明するインセットは
必須のシステムジェスチャーです
ジェスチャーインセットのサブセットで
通常は直接使用しません
ローハンが話すアプリは
ジェスチャーが機能する場所に影響しますが
機能しないように設定できる
APIがあります
必須のシステムジェスチャーインセットは
APIが機能しない場所を示します
システムはジェスチャー領域を
ユーザーのみが
利用できるようにします
10ではそれが下部
ホームジェスチャーです
そこはユーザーにとっての
脱出用ハッチです
アプリはユーザーを
アプリ内に閉じ込めてはいけません
まとめると システムウィンドウのインセット
ジェスチャーのインセット
ドラッグ可能なビューなどについて話しました
次に オーバーラップの回避方法を説明します

Indonesian: 
Inset sistem gestur
terakhir yang akan kita bahas
merupakan gestur sistem yang wajib.
Terdapat subset inset gestur,
dan Anda tidak akan
menggunakannya secara langsung
Tapi aplikasi,
yang nanti akan dibahas Rohan,
memiliki dampak
di mana gestur dapat berfungsi.
Aplikasi punya API tempat
Anda memberi tahu sistem
bahwa aplikasi
tidak ingin berfungsi di sini.
Inset gestur sistem wajib memberi tahu
Anda tempat API tidak berfungsi.
Sistem menjaga
area gestur ini agar hanya tersedia
untuk pengguna.
Saat ini, di Android 10,
ini mewakili area bawah,
gestur beranda.
Ini karena gestur beranda harus
selalu jadi jalan keluar bagi pengguna.
Aplikasi tidak boleh
menjebak pengguna di aplikasi mereka.
Singkatnya, inset
jendela sistem, tampilan yang diklik,
inset gestur,
tampilan yang dapat ditarik, inset gestur
sistem wajib, Anda
tidak akan menggunakannya secara langsung.
Kita tadi membahas inset gestur.
Kini mari bahas cara
menghindari tumpang tindih.

Korean: 
마지막으로 다룰 제스처 시스템 인셋은
필수 시스템 제스처입니다
이것들은 제스처 인셋의 서브셋인데요
보통 직접 사용하지 않습니다
로한이 곧 말씀드리겠지만
앱은 제스처가 동작하는 부분에서 영향을 받습니다
여기에는 시스템에 기능이 동작하지 않게 해달라고
말해주는 API가 있죠
필수 시스템 제스처 인셋은
API가 작동하지 않는 부분을 말해줍니다
시스템은 이 제스처 영역을 사용자만 쓸 수 있게
유지하죠
현재 Android 10은 밑 부분은
홈 제스처를 나타냅니다
사용자에게
탈출구를 마련해주어야 하기 때문이죠
앱은 사용자가 앱에서 빠져나오지 못하게 
해서는 안 됩니다
요약해보자면 시스템 윈도우 인셋과 클릭할 수 있는 뷰
제스처 인셋, 움직일 수 있는 뷰
필수 시스템 제스처 인셋
등을 직접 사용하지는 않을 것입니다
지금까지 제스처 인셋을 이야기했는데요
이제 어떻게 겹치는 현상을 피하는지 
이야기하겠습니다

Spanish: 
La inserción del sistema
de gestos final que vamos a ver
es Gestos obligatorios del sistema.
Son un subconjunto de inserciones
que generalmente no usarían directamente.
Pero las aplicaciones,
de las que Rohan va a hablar,
afectan en dónde funcionan los gestos.
Tienen API que pueden decirle al sistema:
"No quiero que funcione aquí".
Las inserciones de gestos obligatorias
les dicen dónde las API no funcionan.
El sistema mantiene estas áreas de gestos
disponibles solo para el usuario.
En Android 10,
eso representa el área inferior,
el gesto de Inicio.
Y se debe a que siempre debe ser
un plan de escape para el usuario.
Una aplicación nunca debe poder
atrapar a un usuario en ella.
Las inserciones de ventanas del sistema,
vistas cliqueables,
inserciones de gestos, vistas arrastrables
y las inserciones de gestos obligatorios
no se usan directamente.
Recién hablamos de inserciones de gestos
Ahora, hablemos 
de cómo evitar superposiciones.

Portuguese: 
O último inset de sistema de gesto
são os gestos de sistema obrigatórios.
São um subconjunto dos insets de gesto.
Você não os usa diretamente.
Mas, como Rohan vai explicar depois,
apps podem
influenciar o funcionamento dos gestos.
Algumas APIs permitem
desativar o funcionamento.
Os insets de gestos obrigatórios
mostram onde essa API não funciona.
O sistema mantém essas áreas
disponíveis apenas
ao usuário.
No Android 10, é a área inferior,
o gesto de início.
Porque ele deve sempre ser
uma rota de fuga para o usuário.
O app não pode prender o usuário.
Então insets de janelas
do sistema, exibições clicáveis.
De gesto, exibições arrastáveis.
De gestos obrigatórios,
você não usa diretamente.
Falamos sobre insets de gestos.
Agora vamos ver como evitar sobreposições.

English: 
The final gesture system inset
we're going to talk about
is the mandatory
system gestures.
Now, these are a subset
of gesture insets,
and you wouldn't typically
use them directly.
But apps, which Rohan
will talk about in a bit,
apps have an, actually, effect
on where the gestures can work.
They have APIs where you can
actually tell the system,
I don't want it to work here.
The mandatory system
gesture insets tell you
where that API doesn't work.
The system keeps these
gesture areas available only
to the user.
Currently, in Android 10, that
represents the bottom area,
the home gesture.
And that is because
it should always be
an escape hatch for the user.
An app should never be able
to trap a user in their app.
So as a quick summary, system
window insets, clickable views,
gesture insets, draggable
views, mandatory system gesture
insets, you wouldn't
typically use directly.
So we just talked
about gesture insets.
Now, let's talk about how
you actually avoid overlaps.

Japanese: 
ApplyWindowInsetsメソッド
専用の
ViewCompat APIを使用します
APIのウィンドウインセットで
ビューにリスナーを設定でき
次のインセット反転で
リスナーが呼び出され
そこから インセットを使えます
１つのコツは
ViewCompatメソッドを
常に使うことです
インセットのAPIは年々変更されており
これは10のものと同じになりました
フレームワークから同じAPIを取得し
API 14に戻ります
フレームワークのバグの修正もいくつかあります
ぜひ試して使ってください
ウィンドウインセットには３つの使用方法があり
先ほどの様々なインセットに直接マップされます
戻り値の型はInsetsオブジェクトで
上下左右を持つ
単なる値の型です
値はIntsで 端からの
インセットサイズのピクセル値です
一番上は 例えば

Spanish: 
Vamos a usar la API de ViewCompat,
en especial, el método ApplyWindowInsets.
Las inserciones de ventanas en API
existen hace tiempo.
Pueden establecer 
un objeto de escucha en una vista.
¿Qué sucederá con la inversión
de la inserción? Ese objeto será llamado.
Desde allí, podemos hacer algo
con esas inserciones.
Un consejo… vamos a ir atrás.
Un consejo:
siempre deben probar y usar
el método ViewCompat.
La API para inserciones de ventanas
cambió con los años.
La API ahora coincide
con los que tenemos en Android 10.
Tendrán la misma API
desde la infraestructura
que tenían con la API 14
con la solución de algunos errores.
Entonces, asegúrense de probarla y usarla.
Hay 3 métodos principales
de inserciones de ventanas
que van a usar y se aplican
a los diferentes tipos de inserciones
que mencionamos.
El retorno es un objeto de inserciones
que es solo un tipo de valor
que tiene izquierda,
arriba, derecha y abajo.
Los valores son inserciones,
valores de píxeles del tamaño
de la inserción desde ese borde.
Digamos que el borde superior

Chinese: 
我们会使用 ViewCompact API
特别是针对 ApplyWindowInsets 方法
WindowInsets API 已经出现了一段时间
你可以在视图上设置 listener
然后在下一个 inset 转换中这个 listener 被调用
然后 我们就可以使用这些 inset 了
一个小技巧 倒回一下
一个小技巧是 你应该经常试着使用 ViewCompact 方法
WindowInsets API 多年来已经变了很多
现在的 API 和 Android 10 中的 API 是匹配的
你可以从框架中得到相同的 API
一直回溯到 API14
它还修正了框架中的一些 bug
所以请大家务必试用一下它
至于 WindowInsets 有三个主要方法
它们直接指向我们之前提到的不同种类的 inset
返回类型是 Insets 对象
这是一个值类型 拥有左侧 顶部 右侧 底部四个值
都是 Int 值 代表从边缘起始的 inset 所拥有的像素值
顶部值应该是 比如说 从顶端向下40像素

Portuguese: 
Vamos usar a API ViewCompat,
especificamente o método
ApplyWindowInsets.
Insets de janela na API
existem há muito tempo.
Coloque um listener em uma exibição.
Na inversão de inset seguinte,
o listener será chamado.
Então podemos fazer algo com os insets.
Vamos voltar.
Uma dica é sempre usar
o método ViewCompat.
A API de inserts de janela
sofreu mudanças.
A API agora corresponde ao Android 10.
Então a API é a mesma na estrutura
desde a versão 14.
Também tem algumas
correções de erros na estrutura.
Então é melhor usá-la.
Você vai usar três métodos
de insets de janela, correspondendo
aos tipos de insets que mencionamos.
O tipo de retorno é um objeto Insets.
É um valor que tem lados esquerdo,
superior, direito
e inferior.
Os valores são ints. Eles representam
valores em pixel do tamanho
do inset a partir daquela ponta.
O primeiro seria, por exemplo,

Indonesian: 
Jadi kita akan menggunakan ViewCompat API,
khususnya untuk metode ApplyWindowInsets.
Inset jendela di API,
yang sudah ada sejak lama,
mungkin Anda dapat
menetapkan pemroses di tampilan.
Kemudian pada pembalik inset
selanjutnya, pemroses akan dipanggil.
Dari sana, kita dapat
melakukan sesuatu dengan inset tersebut.
Tipsnya--kita akan kembali.
Tipsnya adalah selalu coba gunakan
metode ViewCompat.
API untuk inset jendela
berubah selama bertahun-tahun.
API kini cocok dengan apa
yang kita punya di Android 10.
Jadi Anda mendapatkan
API yang sama dari framework
dengan yang didapat pada API 14.
Selain itu, ada juga
perbaikan bug di framework.
Pastikan Anda mencobanya.
Untuk inset jendela,
ada tiga metode utama yang akan digunakan.
Inset dipetakan langsung ke tipe
inset berbeda yang kita bahas sebelumnya.
Tipe yang ditampilkan itu objek Insets,
yakni tipe nilai yang memiliki
bagian kiri, atas, kanan, dan bawah.
Nilainya Int, dan ia mewakili
nilai piksel ukuran inset
dari tepi tersebut.
Jadi bagian atas kira-kira

Korean: 
이제 ViewCompat API를 사용할 것이고
특히 ApplyWindowInsets 메서드를 위해서 말이죠
API의 윈도우 인셋은 추가한 지 꽤 된 기능입니다
이미 뷰에 listener를 설정할 수 있을 텐데
그다음에는 인셋 반전으로 listener를 호출했을 때
어떤 게 될지 보는 겁니다
그 부분부터 이런 인셋으로 뭔가 할 수 있을 겁니다
다시 돌아갈 건데요
팁을 하나 드리자면 항상
ViewCompat 메서드를 사용하셔야 합니다
윈도우 인셋을 위한 API는 몇 년에 걸쳐 바뀌었습니다
현재 API는 Android 10에 있는 기능을 지원합니다
즉, 여러분은 API 14에서 다룬 프레임워크와 같은
API를 얻을 수 있죠
프레임워크의 버그도 수정했습니다
그러니까 꼭 사용해보세요
윈도우 인셋에는 여러분이 사용할 주요 메서드는
세 가지이며 이 메서드는
전에 말한 다양한 유형의 인셋과 직접 연결됩니다
Return 유형은 인셋 객체이며
왼쪽과 위, 오른쪽 아래 등의 유형을
값으로 갖습니다
값은 Int이고
이것은 가장자리 인셋 크기의 픽셀값을 나타냅니다
그래서 위쪽은.. 잘 모르겠네요

English: 
So we're going to use
the ViewCompat API,
specifically for the
ApplyWindowInsets method.
So window insets in API, which
have been around for a while
now, maybe you can set
a listener on a view.
And then the next
inset reversal,
what will happen, that
listener will be called.
And from there, we can do
something with those insets.
One tip-- we'll
actually go back.
One tip is that you
should always try and use
the ViewCompat method.
The API for window inserts
has changed over the years.
The API now matches what
we have in Android 10.
So you'll get the same
API from the framework
that you would all the
way back to API 14.
And it also has some fixes
for bugs in the framework.
So make sure you
try and use that.
On terms of window insets,
there are three main methods
you're going to use,
and they map directly
to the different types of
insets we spoke about earlier.
The return type is
an Insets object,
which is just a value type which
has a left, a top, a right,
and a bottom.
The values are Ints,
and they represent
pixel values of the size of
the inset from that edge.
So the top one would
be, say, I don't know,

Japanese: 
上端から内側に40ピクセルです
他の端についても同じです
簡単な例を挙げます
非常にシンプルなアプリがあり
変更を適用します
まず
ナビゲーションバーの色を変更します
ナビゲーションバーが見えなくなりました
次に フルスクリーンに設定したいので
システムUIの
可視性メソッドを使用します
すると背後に配置されます
でも下のナビゲーションで
ビューがナビゲーションバーに重なっているので
修正します
OnApplyWindowInsetsListener
を設定し
インセットを取得し
パディングを追加します
その後パディングを行うと
このようになります
良さそうですね
実際のビュー自体ではなく
コンテンツを移動したいので
パディングはビューで使用します
マージンも使えます
FABの例では
パディングを実際に使用するのではなく

Korean: 
위쪽 가장자리에서 안쪽으로 40픽셀 정도이고
다른 가장자리도 마찬가지입니다
간단한 예시를 보겠습니다
여기 단순한 앱이 있고
우리는 변경사항을 전부 적용할 것입니다
먼저 내비게이션 색상을 바꿔야 하는데
이렇게 바뀝니다
내비게이션 바가 사라진 것을 보실 수 있죠
다음으로 설정할 것은
전체화면을 표시할 겁니다
시스템 UI 가시성 메서드를 사용할 것이고요
그러면 바 뒤로도 콘텐츠가 표시됩니다
하지만 아래 내비게이션 바에서는
뷰가 내비게이션 바 위에 걸쳐져 있습니다
이 부분을 고쳐야겠죠
여기서 OnApplyWindowInsetsListener를 설정할 것입니다
그리고 인셋을 얻고 나면
Padding을 추가하겠습니다
Padding까지 넣어 줍시다
여기까지 마치고 나면
화면이 이렇게 바뀝니다
훨씬 보기 좋죠
Padding은 보통 뷰에서 여러분이 사용하고 싶은 것이 됩니다
여기서는 실제 뷰 자체보다는
콘텐츠를 옮기려고 하니까요
물론 Margin도 사용할 수 있습니다
이전에 본 FAB 예에서는
Padding을 쓰는 것보다는 전체 뷰를 통째로

Spanish: 
es de 40 píxeles desde el borde superior.
Y lo mismo para los demás bordes.
Veamos un ejemplo rápido.
Tenemos una aplicación muy simple
y vamos a aplicar estos cambios.
Lo primero que vamos a hacer
es cambiar el color
de la barra de navegación.
Pueden ver que la barra
de navegación desapareció.
En segundo lugar, vamos a…
queremos usar la pantalla completa
para usar el método systemUIVisibility.
Y aparecerá detrás.
Pero pueden ver
que la navegación inferior
está superpuesta
en la barra de navegación
por lo que debemos arreglarlo.
Vamos a establecer
un OnApplyWindowInsetsListener
y cuando tengamos las inserciones
solo vamos a agregar relleno.
Luego, cuando terminemos,
vamos al relleno,
y, luego de eso,
vamos de esto a esto,
lo que se ve bastante bien.
El relleno se suele usar en una vista,
ya que quieren mover el contenido,
no la vista en sí.
Pero también pueden usar márgenes.
En el ejemplo del FAB,
quizás quieran
mover toda la vista hacia arriba

Chinese: 
对于其他边缘 也是一样
我们来举个简短的例子
这里有一个非常简单的应用
我们要在这里应用我们的更改
首先 我们要更改导航栏颜色 我们得到了这个
可以看到 导航栏不见了
然后 因为我们想要全屏效果 所以
我们要使用 systemUiVisibility 方法
把内容布局到导航条后面
可以看到 底部的导航栏视图
在导航条重合了
而我们想要解决这个问题
我们要设定一个 OnApplyWindowInsetsListener
在获取了一些 inset 之后 再添加一些偏移值
完成之后 我们开始补充 Padding
然后 我们就会从这样 变成这样 看起来还不错
通常你应该在视图上使用 Padding
因为你想移动内容 而不是视图本身
不过你也可以使用 margin
在我们之前举出的 FAB 例子中
你大概想要把整个视图向上移动 而不是使用 Padding

Portuguese: 
40 pixels desde a ponta superior.
O mesmo para as outras pontas.
Vamos ver um exemplo rápido.
Temos aqui um app muito simples e vamos
aplicar todas essas mudanças.
Primeiro, nós mudamos a cor
da barra de navegação.
Vejam que a barra sumiu.
Segundo, para que o app
fique em tela cheia, vamos usar
o método de visibilidade de IU do sistema.
O conteúdo fica atrás.
Vejam que, na parte inferior, a exibição
ficou sobre a barra de navegação.
Vamos corrigir isso.
Definimos OnApplyWindowInsetsListener.
Quando recebermos alguns insets,
vamos aplicar espaçamento.
Depois disso, espaçamento.
Depois disso,
o resultado é este, que ficou bom.
Geralmente usamos espaçamento
em uma exibição para mover o conteúdo
e não a própria exibição.
Ou você pode usar margem.
No exemplo de antes do FAB,
seria melhor mover a exibição para cima

Indonesian: 
40 piksel dari tepi atas ke dalam.
Begitu pula dengan tepi lainnya.
Saya beri contoh singkat lain.
Ini ada aplikasi simpel,
dan kita akan menerapkan
semua perubahan tersebut.
Hal yang pertama dilakukan
yakni mengganti
warna menu, dan ini hasilnya.
Seperti yang terlihat,
menu navigasinya hilang.
Yang kedua--
kita akan menampilkan layar penuh,
jadi kita akan
menggunakan metode visibilitas UI sistem.
Lalu kita akan memunculkannya di baliknya.
Dapat dilihat bahwa navigasi bawah,
tampilannya tumpang
tindih di menu navigasi,
jadi kita akan memperbaikinya.
Kita akan menetapkan
OnApplyWindowInsetsListener,
setelah mendapatkan beberapa inset,
kita akan menambahkan beberapa padding.
Setelah menambahkan padding,
jika selesai, hasilnya
dari ini, menjadi ini.
Bagus, bukan?
Padding cenderung digunakan pada tampilan
karena Anda ingin memindahkan isi
ketimbang tampilan itu sendiri.
Tapi margin juga bisa.
Pada contoh FAB sebelumnya,
Anda mungkin ingin
menaikkan tampilan ketimbang

English: 
40 pixels from the
top edge inwards.
And same for the other edges.
So let's go for a
very quick example.
Here we have a very simple
app, and we're going
to go apply all those changes.
So the first thing
we're going to do
is change our navigation
bar color, and we get this.
So you can see that the
navigation bar is gone.
Secondly, we're
going to set-- we
want to be laid out
full screen, so we're
going to use the system
UI visibility method.
And then we get
laid out behind it.
But you can see that the
bottom navigation, the view
has been overlapped
on the navigation bar,
so we want to fix that.
So we're going to set an
OnApplyWindowInsetsListener,
and from there, once
we get some insets,
we're going to just
add some padding.
And once we've done
that, we go padding,
and then once we've
done that, we'll
go from this to this,
which kind of looks good.
Padding tends to be what
you want to use on a view
because you want to move
the content in rather
than the actual view itself.
But you could also use margin.
So in the FAB example
we showed earlier,
you'd probably want to just move
the whole view up rather than

Chinese: 
你还可以使用 LAYOUT
最后看起来会是这个样子
下面来举一个稍微复杂一些的例子
也就是按钮栏
通常 你会在 Google Photos 之类的地方看到它
它看起来大概是这样的 背景是这样
它的实现方式是非常简单的水平线性布局 带 32dp padding
应用了所有更改之后 我们会得到这个结果
显然 它看起来和之前并不一致
按钮 padding 全部不见了
原因在于 我们在 listener 中的 OnApplyWindowInsets 里
使用了 updatePadding
所以我们从布局中删除了那 32dp 的 padding
而这并非我们的本意
我们本来是想为布局添加 32dp 的 padding 的
设计方案就是这样
所以我们想要保留它
另外一种可行的方法是 你可以在 listener 外部
重新调用这个 padding
然后把它们在 listener 内部添加到一起
然后我们就会得到这个结果
之后 我们就可以看到 32dp 的padding 还在那里

English: 
actually use padding.
So you can also use layout.
And it will look like this.
So let's go for a slightly
more complicated example, which
is the button bar.
Typically, you might have seen
this from, like, Google Photos.
Visually, it looks
a bit like this
in terms of it's background,
and how it's implemented
is a very simple
horizontal linear layout
with 32 dps of padding.
But after applying
all of our steps,
we get this instead,
which obviously
doesn't look the same.
We've lost all of
our button padding.
And the reason for this
is that because we're
using updatePadding in
our OnApplyWindowInsets
in our listener, we're
actually wiping out
that 32 dps from
the layout, which
is not what we want to do.
The 32 dps of padding for
the layout is our intention.
It's what the design is.
So we want to keep it.
So one way around this is
that you could actually
record the padding
outside the listener
and then just add them
together within the listener.
And we get this instead.
So once we've done that, you can
see that the 32 dps of padding

Indonesian: 
menggunakan padding.
Anda juga dapat menggunakan tata letak.
Dan penampakannya akan seperti ini.
Saya beri contoh yang sedikit rumit, yakni
kolom tombol.
Tombol ini biasanya ada di Google Foto.
Latar belakangnya kurang lebih
seperti ini, dan cara menerapkannya
yakni dengan tata letak linier horizontal
sederhana dengan padding 32 dps.
Tapi setelah menerapkan semuanya,
hasilnya ini, yang tentu
tidak terlihat sama.
Kita kehilangan semua padding tombol.
Alasannya adalah karena kita menggunakan
updatePadding di OnApplyWindowInsets
pada pemroses, sehingga menghilangkan
32 dps tersebut dari tata letak,
dan ini bukan hasil yang diharapkan.
Padding 32 dps untuk
tata letak adalah tujuan kita.
Inilah desainnya.
Kita ingin mempertahankannya.
Salah satu cara mengatasinya adalah
mencatat padding di luar pemroses
lalu menambahkannya
bersama dalam pemroses.
Dan inilah hasilnya.

Japanese: 
ビュー全体を上に移動するだけです
レイアウトも使えます
このようになります
もう少し複雑な例である
ボタンバーを見てみましょう
Googleフォトなどで
見たことがあると思います
背景はこのような外観です
32 dpsのパディングを持つ
とてもシンプルな水平のリニアレイアウトです
全てのステップの適用後
こうなりますが
明らかに違います
ボタンのパディングが全部失われました
これはリスナーの
OnApplyWindowInsetsで
updatePaddingを使用しているため
32 dpsを消去しているからです
レイアウト用の
32 dpsのパディングをしたいのです
これを回避する方法の１つは
リスナーの外側にパディングを記録し
リスナー内で一緒に追加することです
するとこうなります
32 dpsのパディングが

Korean: 
옮기고 싶을 수도 있습니다
그래서 Layout도 사용할 수 있는 거죠
그러면 이런 모습이 됩니다
이제 더 복잡한 예인
버튼 바를 살펴보죠
보통 이런 건 Google 사진 등에서 보입니다
시각적으로 보면 이런 모습인데
배경과 이것을 적용하는 건 LinearLayout과
32dps로 설정한 Padding이면
간단하게 해결됩니다
하지만 앞서 설명한 단계를 모두 적용하고 나면
이런 결과가 나와버립니다
예상과 다르죠
버튼 패딩이 남아 있지 않습니다
그 이유는 우리가
Listener의 OnApplyWindowInsets에
updatePadding을 사용했기 때문입니다
우리가 한 작업이 의도와 다르게 레이아웃에서
32dps를 제거해버린 것이죠
레이아웃에 Padding을 32dps로 설정하는 것이 목적이고
그 디자인을 만들고 싶으니
이를 유지해야겠죠
이걸 할 수 있는 방법은
Padding을 Listener에서 뺀 후
Listener 안에 함께 추가하는 것입니다
그러면 이렇게 되겠죠
이렇게 하고 나면 Padding 32dps를

Spanish: 
y no usar relleno.
También pueden usar la disposición.
Y se verá así.
Veamos un ejemplo un poco más complicado:
la barra de botones.
Probablemente,
la hayan visto en Google Photos.
Visualmente, se parece a esto
en términos de fondo.
Se implementa muy fácilmente
con una disposición en
lineal horizontal muy simple
con 32 dps de relleno.
Luego de aplicar todos los pasos,
obtenemos esto que, obviamente,
no se ve igual.
Perdimos todo el relleno de los botones
porque estamos usando updatePadding
en las OnApplyWindowInsets
en el objeto de escucha.
De hecho, vamos a quitar
esos 32 dps de la disposición
que no es lo deseado.
Queremos llegar a los 32 dps de relleno.
Así es el diseño.
Queremos mantenerlo.
Una forma de hacerlo 
es registrar el relleno
fuera del objeto de escucha
y agregarlo dentro del objeto.
En cambio, obtenemos esto.
Al terminar,
pueden ver que los 32 dps

Portuguese: 
em vez do espaçamento.
Ou use o layout.
O resultado ficará assim.
Vamos ver um exemplo mais complicado,
a barra de botões.
Talvez vocês tenham
visto no Google Fotos.
Ela é assim visualmente.
O segundo plano é implementado
como um simples layout linear horizontal
com 32 dps de espaçamento.
Mas depois de seguir as etapas,
o resultado é este, ou seja,
não é igual.
O espaçamento dos botões sumiu.
O motivo para isso é que
usamos updatePadding 
em OnApplyWindowInsets
no listener, o que acaba eliminando
os 32 dps do layout. Não era esse
nosso objetivo.
O objetivo era 32 dps de espaçamento.
Esse é o design.
Queremos mantê-lo.
Uma maneira de resolver
é registrar os espaçamentos
fora do listener e adicionar depois.
O resultado é este.
Depois disso, vejam que os 32 dps

Indonesian: 
Setelah melakukannya,
kita lihat padding 32 dps masih ada,
tapi kita juga menaikkan
tampilan dari menu navigasi.
Kami punya postingan blog
yang membahas lebih
detail beberapa cara
untuk mengatasi hal ini.
Cara yang lebih baik, misalnya memakai
data binding atau
menyalin fungsi ekstensi.
Jangan lupa untuk membaca artikel
tersebut jika ingin tahu lebih banyak.
Saya kembalikan ke Rohan
yang akan membahas konflik gestur.
ROHAN SHAH: Terima kasih, Chris.
Baiklah.
Chris tadi membahas tentang tepi ke tepi.
Saya akan membahas bagian kedua, yakni
menangani konflik gestur.
Pembahasan akan
fokus pada navigasi gestur,
bukan mode navigasi lainnya.
Yang ingin saya bahas
adalah konflik tepi kanan
dan tepi kiri.
Topik yang paling menarik bagi developer.
Ada banyak konflik yang orang-orang
laporkan saat proses beta kami.
Jadi saya ingin Anda
memahami ini dengan baik.
Dalam navigasi gestur,
seperti yang kita bahas tadi,
menggeser dari tepi mana pun
akan membawa pengguna kembali.
Dalam mode imersif, ini sedikit menarik,

Korean: 
계속 유지하면서
뷰를 내비게이션 바에서 위쪽으로 움직입니다
저희는 블로그에
이 작업을 다양한 방식으로 할 수 있는 자세한 내용과
데이터 바인딩이나
심지어 확장 함수 복사처럼
더 나은 방법을 담은 포스팅을 올렸습니다
그러니 더 알아보고 싶으신 분은
그 글을 꼭 확인해주시기 바랍니다
이제 제스처 콤플렉스는 로한에게 넘기겠습니다
크리스 고마워요
좋습니다
크리스가 Edge-to-Edge를 짧게 말해줬는데요
저는 이 내용의 두 번째 부분인 제스처 충돌 처리를
이야기하겠습니다
다른 내비게이션 모드와 달리
제스처 내비만 집중적으로 다룰 것입니다
제가 이야기하고 싶은 부분은
왼쪽과 오른쪽 가장자리의
충돌입니다
개발자에게는 가장 흥미로운 문제이죠
베타 버전에는 사람들이 요청한 충돌이
정말 많았습니다
그래서 이 부분을 여러분이 잘 이해하셨으면 합니다
전에 말했듯이 제스처 내비게이션에서는
몰입 모드에서 가장자리에서 가장자리로 화면을 밀면
뒤로 가기 기능을 사용할 수 있습니다, 꽤 흥미롭죠

Chinese: 
但我们把视图从导航栏上移开了
我们发表了一篇博客
详细讲解了各种更优的替代方法
你可以使用 DataBinding 甚至复制扩展函数
如果你想了解更多 请务必查阅那篇文章
下面有请 Rohan 来谈谈手势冲突
谢谢 Chris
Chris 简要地介绍了什么是“边到边”
我想讲第二部分 也就是如何处理手势冲突
这部分的话题主要围绕着手势导航展开
而不会讨论其他类型的导航模式
我想讲的是 左侧和右侧的冲突
对于开发者而言 这个冲突是最有意思的
大家为我们指出了很多 beta 版本中存在的冲突
我想让大家好好理解这些
正如我们所说 在手势导航中
从任意一侧开始向另一侧滑动 都会让用户返回
在沉浸模式中 这种做法也相当有意思

English: 
is still there, but
we've also moved
the view up from the actual
navigation [INAUDIBLE]..
And we actually
wrote a blog post
that goes into far more
detail over the kind of ways
you can work around this.
And better things,
like you can use data
binding or even copying
extension functions.
So make sure you
check out that article
if you want to know more.
And I'll hand it to Rohan to
talk about gesture complex.
ROHAN SHAH: Thanks, Chris.
Cool.
So Chris quickly talked
about edge-to-edge.
I'm going to cover the
second part of it, which
is handling gesture conflicts.
So this is going to be
hyper-focused on gesture nav
now, as opposed to just
any sort of nav mode.
But the one I want to talk
about is the left and right edge
conflicts.
Those are the most
interesting ones for devs.
There's a lot of
conflict that folks
have called out in our beta.
So I want to make sure you
get a good picture of this.
So in gesture nav, as
we've kind of talked about,
swiping from either edge
will take the user back.
In immersive mode, it's a
little interesting, too,

Japanese: 
まだ残っていますが
実際のナビゲーションから
ビューを上に移動しました
ブログ記事で
この問題を回避する方法を
詳しく説明しています
データバインディングの使用や
拡張機能のコピーもできますので
記事をご覧ください
次はローハンが説明します
ありがとう
エッジツーエッジの次は
ジェスチャーの競合を処理する
２番目の部分について話します
ナビゲーションモードではなく
ジェスチャーナビゲーションに焦点を当てます
私が話したいのは 左右の端の競合で
これは開発者にとって興味深い点です
ベータ版では多くの人が指摘している
競合があります
皆さんにはこれをよく理解してほしいです
ジェスチャーナビゲーションでは
説明したように
いずれかの端からスワイプすると
ユーザーが戻ります
没入モードも面白いので

Portuguese: 
ainda estão aqui, mas movemos
a exibição inteira para cima.
Nós escrevemos um blog
explicando as várias maneiras
de resolver isto.
Coisas melhores, como vínculo
de dados ou cópia de funções de extensão.
Confiram o artigo para saber mais
Agora, Rohan vai falar
sobre complexo de gestos.
Obrigado, Chris.
Chris falou um pouco sobre ponta a ponta.
Vou falar sobre a segunda parte,
resolver conflitos de gestos.
Vamos focar na navegação por gestos,
não em qualquer modo de navegação.
Vou falar sobre conflitos
das pontas direita e esquerda.
São mais interessantes
para desenvolvedores.
As pessoas identificaram
muitos conflitos no beta.
Por isso, quero explicar bem.
Na navegação por gestos,
quando o usuário passa o dedo
a partir de uma ponta, a tela volta.
O modo imersivo é interessante também.

Spanish: 
aún están allí, pero movimos
la vista hacia arriba desde
[inaudible] de navegación real.
Escribimos una entrada de blog
que profundiza más en
las diferentes formas de evitar esto.
Y cosas mejores, como el uso
del enlace de datos
o cómo copiar funciones de extensiones.
Lean el artículo si quieren saber más.
Voy a dejar a Rohan
que hable sobre el complejo de gestos.
Gracias, Chris.
Genial.
Entonces, Chris habló
sobre borde a borde.
Yo voy a hablar
sobre la segunda parte
que es cómo manejar conflictos con gestos.
Me voy a enfocar
en la navegación de gestos
en vez de cualquier modo de navegación.
Quiero hablar sobre los conflictos
de los bordes derecho e izquierdo.
Son los más importantes
para desarrolladores.
Hay muchos conflictos
que se encontraron en la versión beta.
Entonces, lo que quiero
es que comprendan bien esto.
En la navegación de gestos,
como ya hablamos,
deslizar desde cualquiera de los bordes
va a llevar al usuario hacia atrás.
En el modo envolvente,
también es interesante.

Indonesian: 
saya akan membahasnya nanti.
UI apa pun yang ada di tepi
dapat menjadi masalah.
Jadi dalam contoh ini,
saya punya Foto dengan empat tuas pangkas.
Jika pengguna ingin memangkas gambar,
mereka tiba-tiba akan kembali
ketimbang dapat memangkas gambar.
Ini ide utamanya. Kami ingin memastikan
bahwa beberapa elemen kecil
yang dapat digeser punya cara
mengambil alih ruang gestur kembali.
Untuk itu ada exclusion rect API.
Kami memperkenalkan hal ini
di Android Q atau Android 10.
API ini memungkinkan
Anda mengecualikan bagian kecil
tiap tepi untuk penggunaan aplikasi.
Dalam kasus ini,
kelihatannya akan seperti ini,
kita punya kotak hijau sebagai area
yang ingin Anda kecualikan.
Satu hal yang
sangat penting adalah API ini
sebaiknya digunakan
dengan sangat hati-hati.
Penggunaannya tidak bebas
atau tidak untuk digunakan
dengan, misalnya, carousel.

Spanish: 
Voy a hablar de eso después de esto.
Básicamente, cualquier clase de IU
que tengan en el borde
puede ser un problema.
En el caso de este ejemplo
tengo fotos con cuatro
puntos de anclaje recortados.
Si un usuario quiere recortar una imagen,
comenzaría por ir hacia atrás
en lugar de poder recortar una imagen.
Esta es la idea principal.
Queríamos asegurarnos que los elementos
movibles puedan
revelar el espacio de los gestos.
Entonces, Q en la API de rectángulos 
de exclusión,
lo vamos a presentar en Android Q o 10.
Básicamente, les permite
excluir una pequeña parte
de cada borde para usar la aplicación.
En este caso, podría verse así,
donde tienen los rectángulos verdes
como las áreas
que pueden eliminar.
Ahora, algo realmente importante
es que se debe usar
esta API con moderación.
No es para usarse libremente
o, por ejemplo, para carruseles.

Portuguese: 
Vou falar dele depois.
Qualquer tipo de IU que exista nas bordas
pode ser um problema.
Neste exemplo, há algumas fotos
com alças para cortar.
Se o usuário tentasse cortar a foto,
ele voltaria na tela
em vez de cortar.
Essa é a ideia principal.
Elementos pequenos deslizáveis precisam
assumir o espaço de gestos de fundo.
Na API Exclusion Rect do Q,
há algo que lançamos no Android Q ou 10.
É o recurso de reservar uma pequena parte
de cada ponta para uso do app.
Neste caso, ficaria assim.
Os retângulos verdes são as áreas
que foram reservadas.
É muito importante usar a API
com moderação.
Não usem para qualquer coisa,
ou coisas como carrosséis.

Japanese: 
これについては後で説明します
基本的に 端にあるあらゆるUIが
問題になる可能性があります
この例では
４つのトリミングハンドルのある写真があります
ユーザーが写真をトリミングしたい場合
トリミングできず
突然前に戻ってしまいます
これが中核となる考えです
一部のスワイプ可能な要素に
戻る動作を引き継ぐ方法があることを
確認したかったのです
Qの除外Rect APIでは
Android Qまたは10でこれを導入しています
アプリの使用のために
各端の小さな部分をオプトアウトできます
この場合 オプトアウトできる領域は
このように緑色の長方形で表示されます
重要な注意点の１つは
このAPIはとても慎重に使う必要があることです
制限をなくしたり
カルーセルなどに使用することを
意図したものではなく

English: 
and I'll cover that after this.
But basically, any sort of
UI that you have at the edge
can become a problem.
So in the case of
this example here,
I have photos with
four crop handles.
If a user wants
to crop a picture,
they would suddenly
start going back
instead of being able
to crop a picture.
So this is kind
of the core idea.
We wanted to make sure
that some small swipable
elements had some way of taking
over the back gesture space.
So Q, in the exclusion
rect API, we're
introducing this in
Android Q or Android 10.
And basically, it allows
you to opt out a small part
of each edge for app use.
So in this case, it
might look like this,
where you have the green
rectangles as the areas
that you may opt out of.
Now, one really important
note is this API
should be used super sparingly.
This is not meant to
be like a free-for-all
or meant to be used
for, like, carousels.

Chinese: 
稍后我会讲给大家
基本上 位于边缘的任何 UI 都有可能出问题
在这里的例子中 这张照片有4个截图控制点 (handles)
如果用户想要截一张图
应用就会突然后退 用户无法完成截图
我们的核心思路是
确保一些较小的可滑动元素
可以通过某种形式占据“后退”手势的空间
我们在 Android Q 或 Android 10 中
通过 exclusion rect API 加入了这个功能
它可以让你在每个边缘中“切出”一小部分不响应系统手势 方便应用使用
在本例中 它看起来可能是这样的
可以切出的部分以绿色方块表示
很重要的一点是 这个 API 千万不能多用
不要到处用它 不要把它用在多图轮播控件这种地方

Korean: 
이 부분은 나중에 다루겠습니다
하지만 기본적으로 어떤 종류의 UI이든
가장자리 사용으로 문제가 생길 수 있습니다
여기 나온 사례를 보면
이 사진에는 자르기 점 네 개가 있습니다
사용자가 사진을 자르려고 하면
사진을 자르지 않고
뒤로 가기 기능이 동작할 수 있죠
이게 핵심입니다
우리는 뒤로 가기 제스처 공간을 우선 점유하도록
밀 수 있는 작은 요소를 추가하고 싶었습니다
그래서 우리는 안드로이드 10의 exclusion rect API에
이 기능을 도입했습니다
이 기능은 앱이 각 가장자리의
작은 부분을 선택하여 제외하게 해주는데요
이 예에서는 이렇게
여러분이 배제한 영역에
초록색 사각형이 생깁니다
정말 중요한 점은 이 API를 최소한으로만
사용해야 한다는 거죠
너무 여기저기 사용한다거나
과도하게 사용하는 용도가 아닙니다

Chinese: 
它更适合用在拖动编辑点 进度条 小小的开关
这些用户肯定会滑动操作的地方
这样做的原因有很多
不过大体上讲 用户喜欢 Android 的“返回”功能
使用这个功能的次数是“返回主屏”功能的两倍多
也就是每天近300次
当然这里说的是平均到每位用户的数据
我们很重视这个数据 我们想要维持这个一致性
继续让“返回”作为 Android 的标志性功能
那么它看起来是怎样的呢？
它是 View 类里的一个新方法 名叫 
setSystemGestureExclusionRects
很长的一个名字
它的功能大概是 把方块列表放进用户坐标空间里 
视图会让这些方块区域正常处理触摸事件
而不是响应系统手势
你也可以在 onLayout 中使用它
如果你更想获得逐帧的更新
那么你也可以在 onDraw 中使用它

Portuguese: 
É para alças de arraste,
barras de busca, botões
que o usuário vai deslizar.
Há muitos motivos,
mas basicamente
os usuários adoram "voltar"
Os usuários usam "voltar"
mais que "início",
quase 300 vezes por dia.
É muito importante...
Por usuário, claro.
É muito importante para nós.
Queremos manter consistência
do recurso "voltar" no Android.
Qual é o recurso?
É um novo método da classe View.
É setSystemGestureExclusionRects.
Difícil de falar.
Ele recebe uma lista de retângulos
no espaço de coordenadas
da exibição, que são as áreas
em que a exibição recebe eventos de toque
em vez do sistema.
Pode ser usado em onLayout.
Para ter maior taxa de atualização,
use em onDraw.

Japanese: 
ドラッグハンドルやシークバー
小さなトグルなど
ユーザーがスワイプしたい部分のためのものです
この裏には多くの理由がありますが
ユーザーはよく「戻る」動作をします
ユーザーはホームの２倍
１日に約300回「戻る」動作をします
これはユーザーにとって
とても重要です
私たちにとっても重要で
その一貫性を維持し
Androidの定番として維持したいです
どんなものかというと
Viewクラスの新しいメソッド
setSystemGestureExclusionRectsです
簡単に言うと システムで使用する代わりに
ビューがタッチイベントを
取得する領域を反映または中継する
使用座標空間内の四角形のリストを
取り込みます
これはonLayoutで使用でき
フレームごとの更新がさらに必要な場合は
onDrawでも使用できます

Spanish: 
Es más para arrastrar puntos de anclaje,
buscar barras y pequeños botones
donde el usuario podrá deslizar el dedo.
Hay muchos motivos,
pero, principalmente, los usuarios
aman ir hacia atrás en Android.
Creo que los usuarios 
van más hacia atrás que al Inicio,
casi 300 veces al día.
Y eso es muy importante…
…por usuario, obviamente.
Es muy importante para nosotros y queremos
mantener esa coherencia
y esencia de Android.
Entonces, ¿cómo se ve?
Es un nuevo método en la clase de Vista.
Es setSystemGestureExclusionRects.
Parece un trabalenguas.
Pero toma una lista de rectángulos
en el espacio de coordinación de uso que
refleja o transmite las áreas que la vista
debería contactar
en lugar de usarse en el sistema.
Pueden usarlo en onLayout
y si quieren más
de una actualización por cuadro,
pueden usarlo en onDraw.

English: 
It's more for drag handles,
seek bars, little small toggles
where the user
will want to swipe.
There's a lot of
reasoning behind this,
but roughly, users
love back in Android.
I think users go back over
twice as much as Home,
almost 300 times a day.
And that's super important--
per user, of course.
It's super important
for us and we
want to maintain
that consistency
and keep back as a
staple of Android.
So what does this look like?
It's a new method
in the View class.
It's
setSystemGestureExclusionRects.
Kind of a mouthful.
But roughly, it takes in a
list of rectangles in the use
coordinate space that reflect
or relay which areas the view
should get touch
events for, instead
of being used for the system.
And you can use
this in onLayout,
and if you want more
of a per frame update,
you can also use this in onDraw.

Korean: 
끌기 핸들이나 찾기 바, 작은 토글처럼
사용자가 밀어내고 싶은 곳을 위한 것이죠
다른 이유가 더 있지만
간단히 말하면 사용자들은
Android의 뒤로 가기 기능을 사랑합니다
아마 홈 버튼보다 뒤로가기 버튼 사용 횟수가
두 배는 많을 겁니다
하루에 거의 300번 정도이죠
정말 중요한 건데요
물론 사용자 한 명당이죠
우리에게는 이게 정말 중요합니다
그리고 우리는 이 빈도를 유지하면서
뒤로가기를 Android에 계속 포함하려고 합니다
그러면 이것은 어떤 모습일까요?
이건 뷰 클래스의 새로운 메서드입니다
setSystemGestureExclusionRect라고 하죠
꽤 길죠
이 기능을 요약하면 시스템에 사용하는 대신
뷰에서 이벤트가 일어나야 하는 영역을
반영하거나 전달하는 사용 좌표 공간에
일단의 사각형을 받아들이는 것입니다
그리고 onLayout에서도 이걸 사용할 수 있고
프레임 업데이트 당 더 넣고 싶다면
onDraw에서도 사용할 수 있습니다

Indonesian: 
Namun lebih ke
tuas penarik, kolom pencari, tombol kecil
tempat pengguna ingin menggeser.
Ada banyak alasan di balik ini,
kurang lebih,
pengguna suka tombol kembali di Android.
Pengguna menekan kembali
dua kali lipat dibanding tombol Beranda,
hampir 300 kali per hari.
Dan itu penting sekali--
tentu saja tiap pengguna berbeda.
Itu sangat penting bagi kami dan
kami ingin mempertahankan konsistensi
dan menjaga agar tombol kembali
tetap ada di Android.
Jadi seperti apa kelihatannya?
Ini adalah metode baru di kelas View.
setSystemGestureExclusionRects.
Sedikit berjubel-jubel memang.
Kasarnya, metode mengambil daftar kotak
dalam ruang koordinat penggunaan yang
mencerminkan atau menyiarkan area mana
yang harus disentuh, ketimbang
yang digunakan untuk sistem.
Dan Anda dapat menggunakannya di onLayout,
dan jika lebih suka update per frame,
Anda juga dapat menggunakannya di onDraw.

English: 
And I want to talk about that
restriction from earlier.
I mentioned that
we don't want this
to be used for every
single large scale UI.
So one of the things
with Q is there
is a restriction on this API.
Basically, apps can only opt
out of 200 dps on either edge.
Or rather, on each edge, you can
opt out of a total of 200 dps.
So if apps do opt out of
more, then only the bottom 200
would get respected.
I did want to visually
explain this really quick.
So in the photos
example, you can
see the blue areas are
where I as a developer
decided to use that
exclusion rect API.
What the system will do
is it will only count--
oh, it's updating.
Here we go.
Here we go.
It'll only count the bottom 200,
which are highlighted in green.
The top blue part-- the
rest of what I requested--
will just get dropped off.
OK.
Now, switching
tracks a little bit,
I want to talk
about immersive mode

Japanese: 
先ほどの制限について説明します
これをすべての
大規模UIで使用したくないと言いました
QではこのAPIに
制限がある場合があります
アプリはどちらの端でも
200 dpsのみオプトアウトできます
または 各端で合計200 dps
オプトアウトできます
それ以上オプトアウトした場合
下の200のみが考慮されます
これを視覚的に説明します
写真の例では
青い領域が
開発者がその除外rect APIを
使用することにした場所です
システムが行うのはカウントのみです
おっと更新中です
大丈夫かな
緑色で強調表示されている
下の200のみがカウントされます
上部の青い部分
つまり要求した残りの部分は
ドロップオフされます
さて話題を変えて
没入型モードと

Indonesian: 
Saya ingin membahas batasan yang tadi.
Saya bilang, sebaiknya kita tidak
menggunakannya untuk tiap UI skala besar.
Salah satu ciri Q adalah
terdapat batasan di API ini.
Biasanya aplikasi hanya dapat
mengecualikan 200 dps di tepi mana pun.
Atau, di tiap tepi, Anda
dapat mengecualikan total 200 dps.
Jadi, jika aplikasi mengecualikan
lebih dari itu, hanya 200 ke bawah
yang akan dipatuhi.
Saya ingin menjelaskannya
secara visual dengan cepat.
Jadi di contoh Foto ini, saya
memutuskan untuk
menggunakan exclusion rect API
di area biru tersebut.
Yang sistem lakukan hanyalah menghitung--
oh, masih mengupdate.
Ini dia.
Sistem hanya menghitung 200
ke bawah, yang disorot dengan warna hijau.
Bagian biru di atas--
bagian yang saya minta--
akan hilang.
Baiklah.
Kita akan membahas yang lain,
yakni mode imersif

Portuguese: 
Quero falar da restrição de antes.
Não queremos que o método
seja usado para toda
IU em larga escala.
Por isso, a versão Q impõe
uma restrição à API.
Apps podem reservar
apenas 200 dps por borda.
Ou seja, em cada ponta,
dá para reservar um total de 200 dps.
Se o app reservar mais,
o sistema respeitará
apenas os 200 inferiores.
Vou explicar visualmente.
No exemplo das fotos,
eu reservei as áreas em azul
usando a API Exclusion Rect.
O sistema vai contar...
Ah, está atualizando.
Pronto.
Ele só conta os 200 de baixo,
destacados na cor verde.
A parte azul em cima,
o resto que reservei,
será ignorada.
Mudando de assunto,
vou falar do modo imersivo

Korean: 
그리고 저는 전에 말했던 제한 범위도 이야기하려고 합니다
저희가 이것이 대규모 UI 하나하나에
빠짐없이 사용하지는 않기를 바란다고 했었죠
Android 10에서는
이 API에 제한이 있습니다
앱은 양 가장자리에 최대 200dps만 배제할 수 있죠
또는 각 가장자리에 총 200 dps만 배제할 수 있습니다
앱에서 배제하는 dps를 더 높게 넣어도
밑의 200dps만 받아들입니다
이걸 시각적으로 간단하게 설명하겠습니다
사진의 예에서 파란 영역은
제가 개발자로서 exclusion rect API를 사용해 결정한 부분입니다
여기서 시스템은 전부가 아니라
이런, 업데이트 중이군요
됐습니다
이제 됐군요
시스템은 초록색으로 표시한 밑의 200만 인식할 겁니다
제가 요청한 영역인
위쪽의 나머지 파란 부분은
사라져 버리는 거죠
됐습니다
이제 주제를 바꿔보죠
이번에는 몰입 모드와

Chinese: 
我想谈谈之前提到过的那个限制
我提到过 我们不想在所有 UI 中大规模使用它
Q 带来的一个改进是 我们限制了这个 API
大体上讲 应用只能在单个边缘切出 200dp
或者说在每个边缘总共消除 200dp
如果应用消除了大于 200dp 的空间
那么只有底部消除的 200dp 会被保留下来
我想用可视化的方式展示给大家看
在这个图片案例中 可以看到 蓝色区域
是我作为开发者想要使用 exclusion rect API 的地方
这时 系统只会计入...哦 动画在更新 好了
系统只会计算底部的 200dp 用绿色表示
上方的蓝色部分 虽然也是我向系统请求过的
会直接被系统忽略掉
好 现在谈点别的
我想谈谈沉浸模式

Spanish: 
También quiero hablar sobre
la restricción que mencioné antes.
Dije que no queremos que se
use para cada IU individual a gran escala.
Entonces, una de las cosas con Q
es que hay una restricción en esta API.
Básicamente, las aplicaciones
solo excluyen 200 dps en cada borde
o, mejor dicho, en cada borde,
pueden excluir un total de 200 dps.
Si las aplicaciones excluyen más,
entonces, solo se considerarán
los últimos 200.
Quería explicar esto realmente rápido.
En las fotos pueden ver
que las áreas azules
están donde yo, como desarrollador,
decidí usar esa API
de rectángulos de exclusión.
Lo que el sistema hará es solo contar…
oh, se está actualizando.
Aquí vamos.
Aquí vamos.
Solo cuenta los últimos 200,
que se resaltan en verde.
La parte azul superior,
el resto de lo que pedí,
se eliminará.
Bien.
Ahora, cambiando de tema,
voy hablar del modo envolvente

Spanish: 
y cómo esta API interactúa con él.
En la navegación con gestos, aquí
figura cómo funciona el modo envolvente.
Cualquier deslizamiento desde un borde
se originará en la barra de estado
y la barra de navegación.
Entonces, si se desliza
desde la izquierda, derecha,
arriba o abajo, verán que aparece
la barra de estado
y navegación con gestos.
Luego de que aparecen las barras,
cualquier otro desplazamiento
hará el gesto en sí.
El desplazamiento desde abajo los llevará
al Inicio y, desde la izquierda
o derecha, los llevará Atrás.
Ahora, la forma en que trabaja con esa API
es que la restricción aún se aplica aquí.
Por ejemplo,
si están en la aplicación Fotos,
pueden usar esa API de 200 dps
y eso evitará que el usuario deslice
la barra de navegación o estado.

Portuguese: 
e da interação entre ele,
"voltar" e a API.
Na navegação por gesto,
o modo imersivo funciona assim.
Deslizar para qualquer lado
faz aparecer
as barras de status e de navegação.
Se você deslizar para a esquerda,
direita, para cima ou para abaixo,
as barras de status
e de navegação vão aparecer.
Quando as barras aparecem,
o usuário desliza de novo
para fazer o gesto real.
Deslizar para cima é "início",
deslizar para esquerda
ou direita é "voltar".
Vamos ver como funciona
com a API de "voltar".
Basicamente...
A restrição ainda vale aqui.
No app Fotos, você pode
usar a API dos 200 dps
e impedir que o usuário
deslize nas barras de navegação ou status.

Indonesian: 
dan bagaimana tombol kembali
dan API berinteraksi dengannya.
Dalam navigasi gestur,
inilah perilaku mode imersif.
Geseran mana pun dari tepi akan
memicu status bar dan menu navigasi.
Jadi penampakannya jika
Anda menggeser dari kiri, kanan,
atas, atau bawah,
Anda akan melihat status bar
dan menu navigasi gestur akan muncul.
Setelah menu ini
muncul, geseran selanjutnya
akan mengaktifkan gestur itu sendiri.
Menggeser dari bawah
akan membuka Beranda,
Anda akan kembali jika
menggeser dari kiri atau kanan.
Bagaimana cara
kerjanya dengan API belakang,
pada dasarnya,
batasannya masih diterapkan di sini.
Misalnya, jika Anda membuka aplikasi Foto,
Anda dapat menggunakan API 200 dps
dan tindakan ini juga akan
mencegah munculnya menu navigasi
dan status bar.

English: 
and how back and this API
kind of interact with it.
So in gesture nav, here's kind
of how immersive mode behaves.
Any swipe from an
edge will first
trigger in the status
bar and navigation bar.
So what this looks like is if
you swipe from the left, right,
top, or bottom, you'll
notice that the status
bar and the gesture
nav bar will come in.
After these bars come
in, any subsequent swipe
will actually do
the gesture itself.
So swiping from the
bottom will go Home,
swiping from the left
or right will go back.
Now, how this kind of
works with that back API,
basically, the restriction
still kind of applies here.
So for example, if
you're in the Photos app,
you can use that 200 dp
API and that will also
stop the user from swiping in
the navigation bar and status
bar.

Korean: 
뒤로가기 및 이 API가 어떤 식으로
상호작용하는지 이야기하겠습니다
제스처 내비게이션에서 몰입 모드가 어떻게 행동하는지
여기에 보여드릴 겁니다
가장자리에서 미는 동작이 발생하면
상태 바와 내비게이션 바가 반응하죠
그래서 왼쪽이나 오른쪽 아니면
위나 아래에서 화면을 밀었을 때
상태 바와 제스처 내비게이션 바가
나타나는 게 보이실 겁니다
바 두 개가 나타난 후에는 화면을 밀면
제스처 내비게이션이 동작합니다
그래서 밑에서 위로 밀면 홈으로 돌아가고
왼쪽이나 오른쪽에서 반대 방향으로 밀면 뒤로 가죠
이게 뒤로 가기 API와 같이 작동하는 것은
제한 사항을 여기에도 적용하기 때문입니다
사진 앱을 이용한다고 하죠
200 dp API를 여기에 사용하면
내비게이션 바와 상태 바가 있을 때
사용자가 화면을 밀어도 작동하지 않게 합니다
Sticky Immersive는 좀 특이한 사례이긴 합니다

Chinese: 
谈谈“返回”功能和这个 API 是如何与它互动的
在手势导航中 沉浸模式运作起来是这样的
任何从边缘起始的滑动操作
会首先触发状态栏和导航栏
那么 如果你从左侧 右侧 顶部或底部起始进行滑动
你就会看到 状态栏和导航条出现了
之后如果你继续滑动的话 就可以实现手势本身的功能了
从底部开始滑动 会让你返回主屏幕
从左侧或右侧滑动会让你返回
那么这个功能是如何与“返回” API 互动的呢？
大体上讲 同样的限制仍然在这里适用
例如 如果你打开了 Photos 应用
你可以使用 200dp API 
它会阻止用户在导航栏和状态栏中进行滑动操作
粘性沉浸 (Sticky Immersive) 模式是个比较特殊的例子

Japanese: 
「戻る」動作と
このAPIの相互作用について話します
ジェスチャーナビでの没入モードですが
端からのスワイプはまず
ステータスバーとナビゲーションバーで
トリガーされます
左 右 上または下からスワイプすると
ステータスバーと
ジェスチャーナビゲーションバーが表示されます
バーが表示された後のスワイプは
実際にジェスチャー自体を実行します
下からスワイプするとホームに戻り
左右からスワイプすると元に戻ります
これらがバックAPIでどのように機能するかは
ここでも制限が適用されます
例えば写真アプリを使用している場合
その200 dp APIを使用でき
これによりユーザーは
ナビゲーションバーとステータスバーを
スワイプできなくなります

Korean: 
크리스가 앞으로 블로그에 설명할 내용 중
몇 가지 사용 사례가 더 있습니다
기본적으로 밀어내는 기능은 앱에 사용하려면
모든 가장자리가 필요합니다
그래서 Sticky immersive는 왼쪽과 오른쪽 가장자리의
배제 범위가 무제한이라서
앱이 주로 게임 같은 앱을 구동할 때
전체 길이를 활용할 수 있죠
좋습니다
이제 크리스가 블로그 이야기를
짧게 해드릴 것입니다
네, 이제 마무리하죠
저희는 블로그에 몇 가지 글과 제스처 내비게이션을 주제로
짧게 연재했습니다
오늘 이야기한 내용을 훨씬 자세하게
다루고 있죠
Going Edge-to-Edge 말고도
제스처 제외 대상도 있어요
순서도를 올려놓았으니
쉽게 읽고 무엇을 하고 싶은지 정의할 수도 있습니다
꼭 확인하세요
그리고 여기 짧은 요약본이 있으니
시간 있을 때 라이브 스트림에서 읽어보세요
여기서 마치겠습니다
감사합니다
[박수]
[음악 재생중]

Portuguese: 
Imersivo fixo é um caso especial.
Chris vai tratar de alguns casos de uso
no blog. Basicamente, é preciso
que toda a beirada seja usada para o app.
O modo imersivo fixo
tem exclusão ilimitada
nas bordas esquerda e direita.
Apps podem usar a borda inteira,
para coisas como jogos.
Agora Chris vai falar sobre o blog.
Vamos encerrar.
Lançamos alguns blogs e uma minissérie
sobre navegação por gestos.
Neles há mais detalhes
sobre tudo.
Isso inclui borda a borda, mas também
o assunto da exclusão de gestos.
Tem um fluxograma para vocês lerem
e definirem o que querem fazer.
Vão conferir.
Vejam um resumo do vídeo.
Leiam depois na transmissão ao vivo.
Muito obrigado!

Spanish: 
El modo envolvente fijo
es un caso especial aquí.
Hay algunos casos de uso que Chris
explicará en blogs, pero, básicamente,
necesitan que se use el borde entero
para su aplicación.
El modo envolvente fijo
tiene una exclusión ilimitada
en los bordes izquierdo y derecho.
Las aplicaciones
pueden usar su longitud completa
para cosas como juegos, principalmente.
Genial.
Quiero que Chris hable
del blog rápidamente.
Sí, vayamos terminando.
Publicamos varias entradas de blog
y una miniserie de navegación de gestos
Entra en más detalle 
sobre lo que hablamos hoy
como trabajar de borde a borde y también
la exclusión de gestos.
Tenemos un diagrama de flujo que pueden
leer fácilmente
y definir qué quieren hacer.
Véanlo.
Y tenemos un resumen aquí.
Lean esto en su tiempo libre
en la transmisión en vivo.
Muchas gracias.
[aplausos]
[música sonando]

Japanese: 
但しSticky immersiveは
特殊なケースです
クリスのブログの事例で
詳細を紹介していますが
基本的にアプリ全体で
端全体を使用する必要がある場合です
Sticky immersiveでは
左右の端が無制限に除外され
主にゲームなどのアプリで
画面全体を使えます
クリスから
ブログについて一言
はい
ブログ記事と
ジェスチャーナビに関するシリーズを
公開しています
エッジツーエッジなど
今日の話の詳細が書かれています
便利なフローチャートもあります
ぜひ見てください
そして今日話せなかったこともあるので
後でライブストリームで見てください
ありがとうございました

Indonesian: 
Sticky immersive adalah kasus langka,
Ada beberapa kasus penggunaan yang
akan dibahas
Chris di blog-nya, yang intinya
mode ini butuh seluruh tepi
untuk digunakan pada aplikasi.
Jadi sticky immersive
memiliki pengecualian tak terbatas
di tepi kiri dan kanan.
Sehingga,
aplikasi dapat memanfaatkan seluruh tepi,
terutama untuk game.
Baiklah.
Chris akan membahas
blog secara singkat.
CHRIS BANES: Mari kita selesaikan.
Jadi kami merilis beberapa postingan blog
dan seri mini tentang navigasi gestur,
yang membahas lebih dalam
topik yang kami bahas hari ini.
Mulai dari tepi ke tepi,
hingga subjek pengecualian gestur.
Kami punya diagram alir yang mudah dibaca
sehingga Anda melangkah lebih mudah.
Anda bisa melihatnya.
Dan kami juga punya
TLDW singkat, silakan lihat di sini.
Anda dapat membacanya
sendiri nanti di livestream.
Terima kasih atas perhatiannya.

English: 
Sticky immersive is a bit of
a special case here, though.
There are a couple of
use cases that Chris
will go into in his
blogs, but basically, they
need that entire edge to
be used for their app.
So sticky immersive, it
has unlimited exclusion
on the left and right edge.
So apps can utilize
the entire length of it
for things like games, mainly.
Cool.
And then I want
to let Chris talk
about the blog super quick.
CHRIS BANES: Yeah,
let's finish off.
So we've released a number of
blog posts and a mini series
on gesture nav.
It goes much more into
detail about all the stuff
we talked about today.
So going from edge-to-edge,
but also the gesture
exclusion subject.
And we've got a flow
chart, which you can easily
read ad actually define what
you actually want to do.
So go check that out.
And as a quick TLDW, we've
got a little one here.
So yeah, read this in your own
time on the livestream later.
And yeah, thank you very much.
[APPLAUSE]
[MUSIC PLAYING]

Chinese: 
Chris 在他的博客里讨论了一些使用案例
粗略地说 它们需要在应用中使用整个边缘
粘性沉浸模式在左侧和右侧都可以无限制地切出
应用可以使用全部长度
主要用途大概是在游戏中吧
好 现在请 Chris 来大概讲讲他写的博客
关于手势导航 我们发布了
几篇博客文章 以及一系列短篇
详细讨论了我们今天涉及的所有内容
不但讨论了“边到边”
还包括了手势排除对象
我们准备了流程图 
你可以轻松阅读并理解自己想做的事情
请大家前往观看
再简单说一句
大家可以在看完演讲后 在方便的时候看看这些文章
多谢大家
