
English: 
IAN LAKE: Thanks for coming.
My name is Ian Lake.
JEREMY WOODS: And
I'm Jeremy Woods.
IAN LAKE: And today
we're here to talk
to you about Fragments--
not just Fragments of today,
but Fragments of past,
present, and we're
going to give you
a little sneak peek
about where we're going
with Fragments in the future.
So starting with
the past, Fragments
were introduced in
Android Honeycomb API 11.
But we don't really
talk about Honeycomb.
So we'll move on to what they
were originally supposed to do.
And Fragments were really
designed from the beginning
to kind of be micro activities.
Right?
Remember way back in
the day when everything
was within your Activity?
And Fragments were really
kind of that very first step
into moving code
out of your activity
and into something smaller.
But that also meant
that we inherited

Japanese: 
お越しいただき
ありがとうございます
イアン･レイクです
ジェレミー･ウッズです
今回のトピックは Fragmentです
現在のFragmentと
過去や将来についても触れます
では過去の話から始めましょう
FragmentはAndroid Honeycomb
API 11で導入されました
しかしHoneycombについては話しません
話すのは
Fragmentの当初の目的です
Fragmentは最初から
マイクロActivityのようなもの
として設計されていました
すべてがActivityに
収まっていた頃のことを
覚えていますか？
Fragmentの最初のステップは
コードをActivityから
より小さいものに移行することでした
しかしそれは Activityに備わっていた

Portuguese: 
Obrigado pela presença.
Meu nome é Ian Lake.
E eu sou Jeremy Woods.
Hoje vamos falar de fragmentos.
Não apenas os fragmentos de hoje,
mas os do passado, presente,
e vamos dar uma olhada
nos fragmentos do futuro.
Começando com o passado,
fragmentos foram introduzidos
na API 11 do Android Honeycomb.
Mas evitamos falar do Honeycomb.
Vamos falar do objetivo original deles.
Os fragmentos foram projetados
para ser microatividades.
Lembram de antigamente,
quando tudo estava na atividade?
E fragmentos eram a primeira etapa
para mover código para fora
da atividade e colocar em algo menor.
Mas isso significava que herdávamos

Spanish: 
Gracias por venir.
Soy Ian Lake.
Y yo soy Jeremy Woods.
Hoy vamos a hablarles
sobre los fragmentos,
no solo los de hoy, también los del pasado
y el presente, y les daremos un adelanto
de lo que haremos con los fragmentos
en el futuro.
En el pasado,
los fragmentos se introdujeron
en Android Honeycomb API 11.
Pero, en realidad, 
no hablamos sobre Honeycomb,
sino de lo que se suponía,
originalmente, que harían.
Desde el inicio, los fragmentos se diseñaron
para ser microactividades.
¿Cierto?
¿Recuerdan cuando todo estaba
dentro de su actividad?
Los fragmentos eran como el primer paso
para sacar el código de la actividad
y llevarlo a algo más pequeño.
Pero, a su vez, heredamos mucho

Indonesian: 
-Terima kasih sudah hadir.
Saya Ian Lake.
-Dan saya Jeremy Woods.
-Hari ini kita akan membahas
Fragment.
Bukan hanya yang ada sekarang,
tapi juga yang dulu,
saat ini, dan sedikit bocoran
tentang rencana kami dengan
Fragment di masa mendatang.
Mari mulai dengan Fragment
yang dulu.
Awalnya, Fragment diperkenalkan
di Android Honeycomb API 11.
Kita tidak akan membahas
Honeycomb.
Langsung saja kita bahas
tujuan utama adanya Fragment.
Awalnya, Fragment dirancang
sebagai aktivitas mikro.
Benar bukan?
Masih ingat saat semuanya
ada dalam Activity?
Fragment jadi
langkah pertama
untuk memindahkan kode dari Activity
dan menjadikannya lebih kecil.
Ini juga berarti kita mewarisi

Chinese: 
感谢大家到场 我是 Ian Lake
我是 Jeremy Woods
今天我们来和大家谈谈 Fragments
不仅是现今的 Fragments 
而是 Fragments 的过去和现在
并简要地展望一下 Fragments 的未来
先从 Fragments 的过去讲起
Fragments 最初是在 Android Honeycomb API11 加入的
但是我们今天不准备讲 Honeycomb
接下来我们讲讲 它们最初的功能是什么
Fragments 从一开始就是被设计成“微型 activity”
很久之前 所有的东西都在 Activity 里 还记得吗？
Fragments 是我们迈出的第一步
我们准备把代码逐渐移出 Activity 
转移到一些较小的东西里

Korean: 
만나서 반갑습니다
저는 이안 레이크이고
저는 제레미 우즈입니다
오늘의 주제는
프래그먼트입니다
지금의 프래그먼트뿐만
아니라 프래그먼트의 과거
그리고 현재에 대해 알아보고
향후 프래그먼트가
발전해 나갈 방향에 관해서도
조금 알아보겠습니다
먼저 과거에 관해서 
알아보겠습니다
Android Honeycomb API 11에 
프래그먼트가 처음 도입되었어요
하지만 Honeycomb 이야기는
넘어가도록 하죠
그럼 프래그먼트의
기존 설계 목적을 알아보죠
프래그먼트는 처음부터
마이크로 액티비티로
설계되었습니다
그렇죠?
예전을 기억하시나요? 모든 것이
액티비티로만 이루어지던 때요
프래그먼트는 일종의 
첫 단계였습니다
코드를 액티비티에서 벗어나
더 작은 것으로 옮긴 것이죠
이는 액티비티 고유의

Korean: 
많은 API 서비스를
그대로 가져왔다는 뜻이기도 했죠
따라서 액션 바 메뉴 같은 것이 전부였습니다
툴바라는 것이 없었기 때문이죠
또한 컨텍스트 메뉴도 있었죠
컨텍스트 메뉴를 아직도 
사용하시는 분 계시나요?
쓸모없지는 않지만
액티비티나 프래그먼트에 있을 필요가 없어요
그 자체로 말이에요
컨텍스트 메뉴는
뷰 계층에 있으면 되죠
또한 많은 맞춤 후크가 있었죠
따라서 일반적으로 액티비티로
전송되던 모든 것이
이제 프래그먼트에도 전송됩니다
예를 들면 onActivity 결과를 보면
꽤 유용해서 사람들이 사용해요 그렇죠?
권한과 같은 것 말이에요
Android가 출시되고
런타임 권한을 추가했을 때
당연히 프래그먼트가 권한을 가졌습니다
액티비티가 권한을 가졌기 때문에요
또한 다중 창 모드가 변경되었어요
혹은 PIP 모드가 변경되었죠

English: 
a lot of the API service that
was inherent in Activity.
So that means that we got things
like all the action bar menu
stuff because there wasn't
something called Toolbar yet.
It also meant that we had
things like context menus, which
does anyone actually use
context menus anymore?
They're a thing.
But they don't really need to
be on activities or Fragments,
per se.
They could be on
views themselves.
It also meant that we got
a lot of custom hooks.
So all the things
that were normally
just sent to your activity are
now also sent to your Fragment.
For instance, things
like onActivity result--
that's pretty useful,
people use that, right--
things like permissions.
When Android came
out and we added
runtime permissions,
of course Fragments
got it, because Activity got it.
And also things like, On
Multi-Window Mode changed.
Or On Picture In
Picture Mode changed.

Spanish: 
del servicio de API inherente a la actividad.
Obtuvimos elementos,
como el menú de la barra de acciones,
porque aún no existía
la barra de herramientas.
Teníamos otros elementos,
como menús contextuales.
¿Alguien los usa?
Existen.
Pero no necesitan estar
en actividades o fragmentos
en sí.
Podrían estar en vistas.
También significó
tener contenido atractivo personalizado.
Todas las cosas que, normalmente,
se enviaban a la actividad
ahora se envían al fragmento.
Por ejemplo, onActivityResult,
que es muy útil,
o permisos.
Cuando se lanzó Android M
y agregamos permisos de tiempo de ejecución,
tanto los fragmentos
como la actividad los obtuvieron.
Cambió también el modo multiventana
o el modo de pantalla en pantalla.

Japanese: 
多くのAPIサービスを
引き継くことを意味していました
まだツールバーもなかったため
アクションバーメニュー
などを利用していました
コンテキストメニューもありました
コンテキストメニューは
もう廃れています
これらが ActivityやFragment上に
ある必要はありません
ビュー自体には必要ですけどね
カスタムフックも多用されていました
これまでActivityに
送信されていたものが
今やFragmentにも送信されています
例えばonActivityResultです
とても便利です
他の例はパーミッションです
Android 6に併せて
ランタイムパーミッションが登場しました
Fragmentが採用しました
Activityが採用したからです
マルチウィンドウモードの
変更もありました
ピクチャインピクチャモードの
変更もありました

Indonesian: 
banyak layanan API yang
melekat di Activity.
Artinya, kita dapat banyak hal
seperti menu panel tindakan
karena belum ada Toolbar.
Selain itu, ada juga fitur
seperti menu konteks,
yang mungkin sudah
tidak ada lagi yang menggunakannya.
Menu konteks memang bisa digunakan,
tapi tak harus benar-benar ada di Activity
atau Fragment.
Fitur ini bisa ada di tampilan.
Ini artinya juga ada
banyak hook kustom.
Jadi, semua hal yang biasanya
hanya dikirim ke Activity,
sekarang juga dikirim ke Fragment.
Misalnya hasil onActivity,
yang cukup berguna
dan banyak orang menggunakannya.
Atau misalnya izin.
Saat Android muncul dan
kami menambahkan
izin waktu proses, Fragment
juga mendapatkannya
karena Activity mendapatkannya.
Dan hal seperti On Multi-Window
Mode berubah.
Atau, On Picture In
Picture Mode berubah.

Portuguese: 
muito do serviço da API
inerente à atividade.
Herdávamos coisas como
todo o menu "ActionBar"
porque ainda não havia
uma barra de ferramentas.
Também significava que havia
itens como menus de contexto.
Alguém ainda usa menus de contexto?
Eles existem.
Mas não precisam estar
em atividades ou fragmentos.
Eles poderiam estar nas
próprias visualizações.
Isso significava também que tínhamos
muitos ganchos personalizados.
Então tudo que normalmente
era enviado só para a atividade
também ia para o fragmento.
Por exemplo,
itens como o "onActivityResult",
que é bem útil, as pessoas usam.
Itens como permissões.
Quando Android M foi lançado
e adicionamos permissões,
claro que os fragmentos as receberam,
já que isso aconteceu com as atividades.
E coisas como
"onMultiWindowModeChanged"
ou "onPictureInPictureModeChanged".

Chinese: 
这也意味着 我们继承了很多 Activity 中的 API 服务
也就是说 所有的动作栏菜单之类的东西 都保留下来了
因为当时还没有“工具栏”这种东西
同时被保留的还包括上下文菜单
现在还有人在用上下文菜单吗？
虽然它确实还存在
但 Activities 和 Fragments 上面已经不需要有它了
直接放在视图上就好
这也意味着 我们有很多定制的代码钩子
那些通常只发送到 Activity 的东西
现在也会被发送到 Fragment 了
比如 onActivityResult
这个很有用 此外 还有权限
Android M 推出的时候 我们添加了运行时权限
Fragment 里面当然有它
因为 Activity 里面就有它
此外 还有 onMultiWindowModeChanged
onPictureInPictureModeChanged

Chinese: 
我们基本上自动得到了这些
因为 Fragment 就是微型版本的 Activity
不过 大家可以想一下 很多这样的东西
并不专属于 Fragment
如果任何东西都能获取这样的回调就好了
我们经历了这样的“存在危机”之后
也就抛弃了这种想法：
“只要 Activity 能做 Fragment 就能做”
我们如今的成果就是由此而来
产生那个想法 还是2011年的事
我们从那时起 经历了很长的历程
其中很大一部分努力内容是
重新构思 Fragment 的目的
目的之一就是 成为专门的 API 服务
真正确保它成为你需要的核心部件
让它拥有可预测的 合理的行为
也就是说 不要出意外 不要出现随机故障
此外 它还意味着 我们不想破坏现有的使用

Korean: 
그리고 이런 모든 것은
다 마이크로 액티비티가
있는 곳에서 프래그먼트가 되고
이런 아이디어가 되면서
그냥 거저 얻은 거예요
하지만 생각해보면 많은 것이
프래그먼트에만 국한되지 않아요
이런 종류의 콜백을 얻을 수 있다면
좋을 거예요
그래서 우리는 이런 종류의
혼란을 겪었습니다
이런 생각에서 벗어나기 위해서 말이죠
단지 액티비티가 할 수 있기 때문에
프래그먼트가 할 수 있는 그런거 말이에요
저희를 오늘날로 이끈 것이죠
2011년이었죠
그 이후로 먼 길을 왔습니다
그리고 이 중 많은 노력이 실제로
저희의 프래그먼트에 대한
목표를 재구성하는 데 들어갔죠
그중 일부는 단지 집중된
API 서비스일 뿐인지
예측 가능하고 올바른 행동에
필요한 핵심 요소인지
확인하는 것입니다
즉 놀라움도 없고 그저 무작위로
작동하지 않는 것은 없음을 의미합니다
또한 저희가 기존 소비자를 불편하게 
하고 싶지 않다는 것을 의미하기도 해요
그렇죠?

Japanese: 
これらはすべて無料で利用できました
それがFragmentであり マイクロActivityでした
これらの大半はFragmentに
限った話ではありません
コールバックが連携できれば
便利になります
しかし Activityで可能なことや
Fragmentで可能なことを
どんどん拡張してきた結果
当初の目的から逸脱してしまい
現在に至っています
2011年から 大きな進歩を遂げようと
努めてきました
特に苦労したのが
Fragmentのゴールを見直すことでした
そこで考え出したゴールとは
特化したAPIサービスとして
予測可能で正常動作に必要な
コアピースにすることです
つまり サプライズを排除するのです
これはUXの保護にもつながります

Portuguese: 
E tudo isso veio
meio que sem motivo com os fragmentos,
considerando que eles são microatividades.
Mas, se pararmos para pensar,
muitas dessas coisas
não são especificas dos fragmentos.
Seria legal se tudo pudesse
ter esse tipo de callback.
Passamos por uma crise existencial
ao nos afastar dessa ideia
de que os fragmentos podem fazer
as mesmas coisas que as atividades.
Isso nos traz ao presente.
Isso foi em 2011.
E tentamos
mudar bastante coisa deste então.
E muito dessa mudança foi tentar
redefinir nossa meta para os fragmentos.
E parte disso é ser um
serviço de API focado,
garantir que seja
o elemento principal necessário
com comportamento previsível e estável.
Ou seja, nada de surpresas,
nada de coisas
que não funcionem aleatoriamente.
Mas não queremos quebrar
os consumers existentes.

Spanish: 
Todo esto lo obteníamos gratis,
por ser fragmentos
o por esta idea de que son microactividades.
Pero, si lo pensamos bien,
muchos de estos elementos
no son específicos de los fragmentos.
Sería bueno
que cualquier cosa pudiera obtener
este tipo de devoluciones de llamadas.
Entonces atravesamos
esta especie de crisis existencial
y nos apartamos de esta idea
de que si una actividad puede hacerlo,
un fragmento también.
Eso nos lleva a la actualidad.
Eso fue en 2011.
Desde entonces, recorrimos un largo camino.
Tratamos de reestructurar nuestra meta
en relación con los fragmentos.
Por ejemplo, ser un servicio de API enfocado
que solo sea la pieza central que necesitan
con una conducta sensata y predecible.
Sin sorpresas
ni elementos que dejan de funcionar de golpe.
Pero tampoco queremos perder clientes.

English: 
And these are all kind
of things that we just
got kind of for
free, being Fragments
and being this idea that
there are micro activities.
But when you think about
it, a lot of these things
aren't specific to Fragments.
It would be nice
if anything could
get these kind of callbacks.
So we've kind of gone through
this kind of existential crisis
on kind of moving
away from this idea
that, it's like, oh, just
because an Activity can do it,
a Fragment can do it.
So that kind of
leads us to today.
That was 2011.
And we've tried to come
a long way since then.
And a lot of this
is really trying
to restructure what is
our goal for Fragments?
And some of this is really just
being a focused API service,
really making sure
that it's just
the core piece that you
need with predictable, sane
behavior.
That means no
surprises, no things
that just randomly don't work.
But it also means we don't want
to break existing consumers.
Right?

Indonesian: 
Inilah yang kita dapatkan
secara cuma-cuma dengan Fragment
dan ide adanya aktivitas mikro.
Tapi, jika dipikirkan lagi,
banyak hal yang sebenarnya
tidak spesifik untuk Fragment.
Alangkah baiknya jika apa pun
bisa mendapatkan callback ini.
Jadi kami seperti mengalami
krisis eksistensi saat mulai meninggalkan
gagasan bahwa jika Activity
bisa melakukannya,
Fragment pun bisa melakukannya.
Itulah yang membawa kami ke saat ini.
Dimulai pada tahun 2011.
Kami sudah mencoba
banyak hal sejak saat itu.
Banyak upaya dilakukan
untuk meninjau kembali
tujuan kami untuk Fragment?
Beberapa di antaranya adalah
membuatnya jadi layanan API terfokus,
memastikan bahwa
ini hanyalah komponen inti
yang Anda perlukan dengan
perilaku yang dapat diprediksi
dan masuk akal.
Jadi, tidak ada kejutan,
tak ada hal
yang tiba-tiba tidak berfungsi.
Tapi kami juga tidak ingin kehilangan
pelanggan yang sudah ada.

English: 
And that means binary source
or even behavior compatibility.
Now along the way, that
does mean that we do
have times when we introduce
a new alternative, a new API,
that is predictable and nice.
And we deprecate the old API
because we can't actually
remove it until we have
a good alternative that
gives you something much
better to work with.
But the idea is that
we do want to release
a 2.0 at some point, where
as long as you're not
using the deprecated APIs, if
you're all on the good new API
surfaces, then it'll be
an easy transition over
and we'll be able to cut out
a lot of code out of Fragments
to support these kind
of more legacy cases.
So what are we
doing to get there?
Well, the first part of
providing kind of a sane API
is a testable API.
If you're writing code that
you can't test, that's no good.

Indonesian: 
Jadi harus mempertahankan
kompatibilitas biner,
sumber,
dan bahkan perilaku.
Karena itulah,
kami pernah beberapa kali
memperkenalkan alternatif baru,
API baru yang dapat diprediksi
dan mudah digunakan.
Kami menghentikan API lama
tapi tidak bisa menghapusnya
sampai kami bisa berikan
alternatif yang lebih baik
untuk Anda gunakan.
Tapi, kami juga
akan merilis versi 2.0.
Selama Anda tidak
menggunakan API yang dihentikan,
jika Anda hanya
menggunakan permukaan API baru
yang masih berlaku,
transisinya akan mudah.
Kami juga akan bisa hilangkan
banyak kode dari Fragment
untuk mendukung
lebih banyak kasus aplikasi lama ini.
Apa saja usaha kami
untuk melakukannya?
Langkah pertama untuk
menyediakan API yang baik
adalah membuat API yang dapat diuji.
Kode yang tidak bisa diuji
adalah kode yang tidak bagus.

Japanese: 
つまり バイナリソースや
動作の互換性といった話になります
その過程で 新しいAPIを
導入することもあります
それらは予測可能で 優れたものです
そして古いAPIは 非推奨になります
優れた機能を提供する代替APIを
提供できるまで 削除できないからです
つまり非推奨のAPIが
使用されなくなった時点で
2.0をリリースすることになります
新しい優れたAPIサーフェスを
全面的に使用していれば
移行も簡単です
Fragmentから多くのコードを
取り除いて
古いケースをサポートできます
そのための取り組み
つまり健全なAPIを
提供するための第一歩とは
テスト可能なAPIを提供することです
テストできないコードを記述しても
困るだけです

Chinese: 
也就是二进制 源代码 甚至包括行为兼容性
这意味着 我们有时会加入新的替代方案 新的 API
而它们都是可预测的 运行良好的
然后我们会替换掉旧的 API
因为我们无法真正移除它
直到我们获得一个较好的替代方案
为用户提供好得多的使用体验为止
不过 我们确实想挑个时间推出 2.0 版本
只要你不使用被替代的 API
只要大家使用的都是表现良好的新 API
转换就会很容易
我们就可以从 Fragment 中减掉大量代码
支持这些较旧的用例
那么 我们是如何实现这个目标的呢？
想要提供一个合理的 API 
首先就要提供一个可测试的 API
如果你写的代码无法测试 那可不大好
如果我们写的代码库是你无法测试的

Spanish: 
¿Verdad?
Eso significa código binario
o incluso compatibilidad de comportamiento.
En el proceso, significa que,
al introducir una nueva alternativa,
tenemos una nueva API,
predecible y agradable,
y deja de estar disponible la antigua API
porque no podemos quitarla
hasta tener una buena alternativa
que sea mejor para trabajar.
Pero la idea es que, 
en algún momento, queremos lanzar
una versión 2.0 en la que,
siempre que no se usen las API obsoletas,
si todos usan
las superficies de la nueva API,
la transición será sencilla
y podremos quitar gran parte
de los códigos de los fragmentos
para admitir estos tipos de casos heredados.
¿Qué estamos haciendo para lograrlo?
La primera parte de ofrecer una API estable
es una API que se pueda probar.
No sirve escribir código
que no se puede probar,

Korean: 
바이너리 소스 또는 동작 호환성 말이에요
즉 이제 이 과정에서
새로운 대안인 새로운 API를
도입할 때라는 겁니다
예측할 수 있고 좋은 API로요
이전 API를 지원 중단하는 이유는
작업하기에 훨씬 더 좋은 대안을
드리기 전까지는
API를 제거할 수 없기 때문이죠
하지만 언젠가는 2.0 버전을 출시할 할 생각이니
지원 중단된 API를
사용하는 사람이 없을 때까지
모두 새 API를 사용할 때까지
기다린다면
쉽게 전환할 수 있고
프레그먼트에서 많은 코드를 잘라낼 수 있어
이러한 종류의 더 많은
레거시 사례를 지원할 수 있습니다
그래서 거기에 도달하기 위해 
무엇을 하고 있을까요?
올바른 API를 제공하는 첫 번째 부분은
테스트 가능한 API입니다
테스트할 수 없는 코드를
쓰는 것은 좋지 않습니다

Portuguese: 
E isso significa fonte binária ou
até compatibilidade de comportamento.
Nesse processo, há momentos
em que apresentamos uma
nova alternativa, uma nova API
que é previsível e boa.
E suspendemos o uso da antiga
porque não podemos
removê-la até que tenhamos
uma boa alternativa
que dê a você algo melhor para trabalhar.
Mas a ideia é lançar
a versão 2.0 em algum momento,
e desde que você não esteja
usando APIs obsoletas,
se estiverem todos nas novas e boas
superfícies de API,
será uma transição fácil,
e poderemos cortar muito
código dos fragmentos
para dar suporte a
esses casos mais antigos.
O que estamos fazendo
para chegar a isso?
O primeira passo para 
fornecer uma API estável
é uma API que possa ser testada.
Se escrever código que não pode testar,
isso não é bom.

Indonesian: 
Jika kami menulis library yang
tidak bisa Anda uji,
kode yang ditulis dengan
library itu
juga tidak akan berfungsi.
Jadi tahun 2019 ini,
kami ingin memperbaikinya.
Kami sekarang memiliki artefak
pengujian Fragment
yang menawarkan skenario Fragment.
Inilah cara untuk menguji
satu Fragment dalam isolasi.
Kami juga bekerja bersama
tim pengujian AndroidX.
Pengujian ini dibuat dalam skenario
aktivitas, yang berarti
sesuai untuk uji instrumen
dan uji Roboelectric.
Kami ingin memastikan
Fragment punya
permukaan API kecil yang baik.
Ada satu metode onFragment utama,
yang menggunakan lambda,
dan menghasilkan instance Fragment
yang sudah ada.
Ini juga memberikan banyak hook
yang diperlukan untuk memudahkan
pengujian siklus hidup
dan membuat ulang
keseluruhan Fragment.
Jadi, seperti apa tampilannya?
Cukup mudah.

English: 
And if we're writing a
library that you can't test,
code-written with
that library, that's
not going to work either.
So in 2019 here, we really
want to make that better.
So we have a Fragment
testing artifact now
that offers Fragment scenario.
This is really a way of testing
just one Fragment in isolation.
And we worked really closely
with the AndroidX test team.
So this is actually built
on activity scenario, which
means it works for
instrumentation tests
and it works for
robo electric tests.
Now we wanted to make
sure that this had kind
of a nice, small API service.
So really, it has one main
method of on Fragment,
which takes a lambda, gives you
the Fragment instance that's
available already.
And it also kind
of gives you a lot
of the hooks that you
need that makes it really
easy to test things
lifecycle and recreating
your whole Fragment.
So what does this look like?
Well, it's actually pretty easy.

Korean: 
그리고 테스트할 수 없는
라이브러리를 코딩하고 있고
그 라이브러리로 코딩하면
작동도 되지 않습니다
2019년에는 이 점을 개선하고 싶습니다
그래서 현재 아티팩트를
테스트하는 프래그먼트가 있고
여기서 프래그먼트 시나리오를 제공합니다
이 방법은 프래그먼트 하나만 격리하여 테스트하죠
AndroidX 테스트 팀과 긴밀히 협력했습니다
이는 액티비티 시나리오를 기반으로 하므로
계측 테스트에서 작동하고
로보 전기 테스트에서 작동합니다
이 프래그먼트가 멋지고 훌륭한
소규모 API 서비스를 갖기를 원했죠
실제로도 프래그먼트에는
주요 방법이 하나 있는데
람다를 취하는 방법이며 이미 사용 가능한
프래그먼트 인스턴스를 제공합니다
그리고 또한 필요한 후크를
많이 제공하여 수명 주기나
전체 프래그먼트를 재현하는 것을
정말 쉽게 테스트할 수 있죠
그래서 어때 보이나요?
실제로는 꽤 쉽습니다

Chinese: 
使用那个代码库编写的代码也照样不行
所以 在2019年 我们想要改善这个局面
现在我们有了一个 Fragment 测试工件
它可以提供 FragmentScenario
我们可以通过它来单独对一个 Fragment 进行测试
我们和 AndroidX 测试团队也在紧密合作
这个东西就基于 ActivityScenario
也就是说 它适用于 Instrumentation 测试和 Robolectric 测试
我们还想确保它拥有一套简洁精干的 API
它在有一个主方法 也就是 onFragment
它接收一个 lambda 给你可用的 Fragment 实例
它还会给你很多必须的钩子
你可以使用这些钩子来测试
诸如生命周期 重新创建整个 Fragment 之类的东西
它看起来是什么样子？
其实挺简单的

Portuguese: 
Se escrevemos uma
biblioteca que você não pode testar,
o código escrito com essa biblioteca
não vai funcionar também.
Então, em 2019, queremos melhorar isso.
Agora, temos um artefato
de teste de fragmentos
com "FragmentScenario".
É um jeito de testar apenas
um fragmento isolado.
E trabalhamos com a
equipe de teste do AndroidX.
Então ele é construído
no "ActivityScenario",
o que significa que funciona em
testes de instrumentação
e testes robóticos elétricos.
Queríamos garantir que houvesse
um serviço de API bom e pequeno.
Ele tem um método
principal de "onFragment",
que pega uma lambda
e fornece a instância do fragmento
que já está disponível.
E também fornece muitos
dos ganchos necessários,
o que facilita testes de
ciclo de vida e recriação de fragmentos.
E como fica?
É bem fácil, na verdade.

Japanese: 
テストできない
ライブラリを作成したら
そのライブラリで記述されたコードも
機能しないでしょう
2019年の今
大きく改善したいと考えています
そこで FragmentScenarioを提供する
Fragmentテスティング
アーティファクトを用意しました
これは特定のFragmentを
隔離してテストする手段です
AndroidXテストチームと
密に連携しました
これは ActivityScenario上で
構築されています
つまり インストゥルメントテストにも
ロボエレクトリックテスト
にも使用できます
これをコンパクトで優れた
APIサービスにしたいと考えました
そのためのメインメソッドが
onFragmentです
これはラムダを使用する方法で
既に利用可能なFragment
インスタンスを提供します
必要となる様々なフックを提供します
これらはライフサイクルをテストしたり
Fragment全体の再作成を
テストしたりするのを容易にします
この記述方法は 非常に簡単です

Spanish: 
y si escriben una biblioteca
que no se puede probar,
el código escrito con esa biblioteca
tampoco funcionará.
En 2019, realmente queremos mejorar eso.
Ahora, hay un artefacto
de prueba de fragmentos
que ofrece FragmentScenario.
Es una manera de probar un fragmento aislado.
Y trabajamos estrechamente
con el equipo de prueba de AndroidX.
Es decir que esto se crea
a partir de un ActivityScenario,
lo que significa que funciona
para pruebas de instrumentación
y para pruebas robóticas eléctricas.
Quisimos asegurarnos de que esto tuviera
un servicio de API pequeño y agradable.
Es por esto que tiene
un método principal de "onFragment",
que usa una lambda y les da
la instancia de fragmento ya disponible,
y ofrece muchas de las herramientas
necesarias para hacer pruebas fácilmente,
como el ciclo de vida
y la recreación del fragmento entero.
¿Cómo es?
En realidad, es bastante sencillo.

Japanese: 
LaunchFragmentInContainerを使用する
シナリオを作成します
これは Activityの作成や
Fragmentの追加
Resumedへの移行など
すべてを担います
ここでテストを行います
ビューでそれをクリックします
Fragment階層が
存在しています
onFragmentを使用して
内部状況を確認したり
クリックが正常に処理されているか
確認したりできます
例えば より複雑なコードで
ライフサイクルの状態や
タイミングを確認したい場合
scenario.MovetoStateを呼び出して
状態を“Started” “Created”
“Resumed”に移行します
再作成のテストも同様です
状態を適切に保存したり
回復したりしているか確認するには
Recreateを呼び出すだけです
これで 呼び出す前後の
状態を確認できます
簡単になりましたね
もう１つの点は
この再作成についてです
再作成はFragmentを
インスタンス化するための

Chinese: 
你通过 launchFragmentInContainer 创建 scenario
它会完成所有的创建工作 比如 Activity
添加 Fragment 将其移动到 resumed
然后只需要再做一次特别测试即可
只需要在 onView 里运行 click() 就好
Fragment 层级已经存在 已经做好了准备
然后我们可以使用 onFragment 来检查内部状态
看看它处理点击的方式是否正确
例如 如果你在做的是比较复杂的工作
如果你想要查看 如何切换生命周期状态
你只需调用 scenario.moveToState 就好
将其移动到 Started Created 或 Resumed
测试 Recreation 也是一样
我是否用正确的方式存储并恢复了我的状态
只需调用 recreate 即可
你可以在 recreate 之前或之后查看状态
这就是你需要做的全部内容
另外 我们遇到了这个 Recreation 的问题
这只是众多实例化 Fragment 方法中的一种

Portuguese: 
Você cria seu cenário usando
"LaunchFragmentInContainer",
o que fará toda a criação
da sua atividade,
adição do fragmento,
transferência para "RESUMED".
E vamos fazer um teste Espresso.
Você pode dizer para
clicar na visualização.
E a hierarquia do fragmento já está lá.
Está pronta.
E você pode usar "onFragment"
para verificar o estado interno,
ver se o clique foi processado.
Se estiver fazendo
coisas mais complicadas,
como verificar a movimentação
entre estados do ciclo de vida,
chame "scenario.moveToState" e mova
para "STARTED", "CREATED" ou "RESUMED".
É a mesma coisa para testar recriação,
conferir se salvei e restaurei
meu estado adequadamente.
É só chamar "recreate()".
Você pode checar o estado
antes e depois disso.
É só o que precisa fazer.
O próximo ponto é a recriação.
É uma das várias formas necessárias
para instanciar um fragmento.

English: 
You create your scenario using
Launch Fragment in Container,
which will do all of the
creating, your activity,
adding the Fragment,
moving it to resumed.
And then again just do a
[? special ?] test, right?
You can say On View, click it.
And the Fragments
hierarchy is already there.
It's already ready.
And then we can use on
Fragment to then check
our internal state, check
to see did it actually
handle the click correctly?
For example, if you're doing
more complicated things,
if you want to
check how, when you
move through lifecycle states,
you can just call the scenario
Move to State and move it
to Start It, or Create It,
or Resumed.
Same thing with actually
testing recreation--
do I save and restore
my state properly?
Just call Recreate.
You can check your
state before Recreate.
You can check your
state after Recreate.
And that's all you
really need to do.
So the other bit is we
have this recreation thing.
Well, that's really
just one of many ways

Indonesian: 
Buatlah skenario menggunakan
Launch Fragment di Container,
yang akan melakukan
pembuatan aktivitas,
penambahan Fragment,
dan memindahkan ke Resumed.
Lalu, cukup lakukan pengujian.
Anda bisa mengatur onView, lalu klik.
Hierarki Fragment sudah ada di sana.
Sudah siap.
Lalu, gunakan
onFragment untuk memeriksa
status internal dan apakah
klik ditangani dengan tepat.
Untuk proses yang lebih rumit,
misalnya memeriksa proses
perpindahan status siklus hidup,
cukup panggil skenario
Move to State dan pindahkan ke
Start It, atau Create It,
atau Resumed.
Sama halnya saat
menguji hasil pembuatan ulang,
untuk memeriksa bahwa status
disimpan dan dipulihkan dengan benar,
cukup panggil Recreate.
Anda bisa memeriksa status
sebelum Recreate
dan status setelah Recreate.
Hanya itu yang perlu dilakukan.
Selain itu, ada pembuatan ulang.
Ini salah satu cara
yang memerlukan

Korean: 
컨테이너에서 '프래그먼트 실행'을
사용해 시나리오를 작성하면
모든 작업을 수행합니다
액티비티를 생성하고
프래그먼트를 추가하고 재개로 옮기는 것이죠
그다음 다시 특별한 테스트를 수행하죠
그렇죠?
'뷰에서 클릭하기' 같은 식으로요
그리고 프래그먼트
계층 구조는 이미 있습니다
이미 준비되어 있죠
그런 onFragment를 사용하여
내부 상태를 확인하고 실제로 클릭을 올바르게
처리했는지 확인할 수 있어요
예를 들어 보다 복잡한
작업을 수행하는 경우에는
수명 주기 상태를 통해 어떻게 언제
이동하는지 확인하려면 시나리오를
'상태로 이동'으로 호출하여 '시작하기', '만들기'
또는 '재개'로 이동할 수 있습니다
실제로 재현을 테스트하는 것과 같은 거죠
상태를 올바르게 저장하고 복원했나 보려면
그냥 '재현'을 호출하세요
'재현' 전 상태를 확인할 수 있고
'재현' 후 상태도 확인할 수 있습니다
이거만 하면 됩니다
다른 하나는 이 재현인데
프래그먼트를 인스턴스화하는

Spanish: 
Se crea la situación
usando "launchFragmentInContainer",
que creará toda la actividad,
agregará el fragmento
y lo moverá al estado "reanudado".
Luego, harán una prueba de Espresso.
Por ejemplo, "onView" y harán un clic.
La jerarquía de fragmentos está allí.
Ya lista.
Y, luego, podemos usar "onFragment"
para comprobar el estado interno,
y ver si procesó bien el clic.
Por ejemplo, si hacen algo más complicado,
si quieren verificar cómo, al moverse
por los estados del ciclo de vida,
invocan la situación "moveToState"
y la mueven al estado "Iniciada", "Creada"
o "Reanudada".
Es lo mismo para probar la recreación,
¿guardo o restablezco bien mi estado?
Invoquen "recreate".
Se puede verificar el estado antes
o después de recrear.
Eso es todo lo que deben hacer.
Por otro lado, está la recreación,
una de las tantas maneras necesarias
para crear una instancia de un fragmento.

Korean: 
수많은 방법 중 하나이죠
새로운 프래그먼트를
추가하는 경우도 있습니다
프래그먼트를 인스턴스화하여
프래그먼트 관리자에게 제공해야합니다
또한 프래그먼트 시나리오와
같은 것도 있습니다
테스트를 위해 프래그먼트를 인플레이션하여
UI에 추가해야 합니다
그래서 이를 할 수 있는 한 방법을 개발했죠
바로 FragmentFactory입니다
이 덕분에 무엇이 가능해지는가 하면
마침내 프래그먼트에 생성자를 주입하고
인수가 없는 생성자를
필요로 하는 이 요구 사항에서
벗어날 수 있게 되죠
이 모든 것을 알아서 해 주는
것을 빌드할 수 있습니다
그럼 어떤 식일까요?
간단한 FragmentFactory는 하나의 메서드로
클래스 이름을 주면 인스턴스화하죠
그리고 클래스를 로드하는 것은 
여러분에게 달려 있습니다
따라서 슈퍼 점 인스턴스화는
리플렉션을 사용하고
무 인수 생성자를 호출합니다
이걸로 원하는 것은
무엇이든 할 수 있습니다
종속 항목 주입에 대한
의견이 담긴 가이드를 보면 아시겠지만
이것은 저희가 언젠가

Portuguese: 
Também temos casos
de adição de fragmentos.
Você precisa instanciar um fragmento
para dá-lo ao gerenciador.
Mas também temos itens
como "FragmentScenario".
Você precisa inflar o fragmento
para adicioná-lo à IU para teste.
Queríamos um jeito de fazer isso.
E esse jeito é "FragmentFactory".
Isso nos fornece uma forma
de finalmente conseguir fazer
a injeção de construtor
nos seus fragmentos e se afastar
desse requisito
de que precisa de um
construtor sem argumento.
E agora você pode construir algo
que faz tudo isso por você.
E como fica isso?
Um "FragmentFactory"
é só um método "instantiate",
em que é dado um nome de classe.
O carregamento da classe
fica por sua conta.
Então, "super.instantiate" usa reflexão
para chamar o construtor sem argumento.
Mas, na verdade,
você pode fazer o que quiser com isso.
Se vocês assistiram o guia assertivo
para injeção de dependência,

English: 
that you need to
instantiate a Fragment.
So we also have cases
where you're adding
a new Fragment in first place.
You need to
instantiate a Fragment
to give it to Fragment manager.
But also, we have things
like Fragment Scenario.
You need to inflate
the Fragment to add it
to your UI for testing.
So we wanted one
way of doing this.
And this one way
is FragmentFactory.
So this gives us
kind of a way to now
finally be able to do
constructor injection
into your Fragments and move
away from this requirement
that you need a
no-argument constructor.
Now you can actually
build something
that does all of this for you.
So what does this look like?
Well, a simple FragmentFactory,
it's really just one method,
instantiate, where you're
given a class name.
And it's up to you
to load the class.
So super dot instantiate
will just use reflection,
call your no arg constructor.
But really, you can do
anything you want with this.
If you watch the opinionated
guide to dependency injection,
this is the kind
of thing that we'd

Spanish: 
También hay casos en que, primero,
se agrega un fragmento nuevo.
Se debe crear una instancia de un fragmento
para dárselo al administrador de fragmentos.
También tenemos FragmentScenario.
Se debe aumentar el fragmento
para agregarlo a la IU y probarlo.
Queríamos una forma de hacerlo,
y esa forma es FragmentFactory.
Esto nos permite hacer
una inserción por constructor
en los fragmentos y alejarnos del requisito
de un constructor sin argumento.
Ahora se puede diseñar algo
que lo haga todo por uno.
¿Cómo es?
FragmentFactory es solo un método
para crear una instancia, 
que les da un nombre de clase
y ustedes deciden si cargar la clase.
Es decir, super.instantiate
usa reflexión e invoca al constructor no-arg.
Pero, en realidad,
pueden hacer lo que quieran con esto.
Si consultan la guía tendenciosa
sobre inyección de dependencias,
esto es lo que nos

Chinese: 
在有些情况下 用户首先就添加了新的 Fragment
你需要实例化 Fragment 才能将其传给 FragmentManager
此外 我们还有 FragmentScenario
你需要先 inflate Fragment 才能把它添加到 UI 中用来测试
我们想出了一个办法：FragmentFactory
现在 我们终于可以对你的 Fragment 的
构造方法进行注入
并规避无参数构造方法的需求
现在你可以构建一个东西 让它为你代劳
它看起来是什么样子？
FragmentFactory 只是一个实例化方法
接收一个类名称
你可以加载这个类
super.instantiate 会使用反射
调用你的无变量构造方法
其实你可以用它来做任何你想做的事
如果你有听《Android 依赖注入指南》这场演讲 你就会知道

Japanese: 
たくさんある方法の１つです
新規Fragmentを最初に
追加する場合もあります
Fragmentをインスタンス化して
Fragmentマネージャに
渡す必要があります
ほかにも
FragmentScenarioがあります
Fragmentをインフレートし
テスト用のUIに追加します
そこで登場したのが
FragmentFactoryです
これによりFragmentで
コンストラクタインジェクションを
実行できるようになり
引数なしのコンストラクタでなければ
ならないという要件を
取り除くことができました
これにより 作業もかなり簡素化されました
実例です
シンプルなFragmentFactoryです
これはあくまでも１つの方法で
インスタンス化し
クラス名が得られます
クラスをロードするかどうかは
あなた次第です
super.instantiateは
リフレクションを使用し
引数なしの
コンストラクタを呼び出します
これを使用して
行いたいことを実行できます

Indonesian: 
instansiasi Fragment.
Contoh lain adalah saat
menambahkan Fragment baru
untuk pertama kali.
Anda perlu menginstansiasi Fragment
untuk diberikan ke pengelola Fragment.
Selain itu juga ada
FragmentScenario.
Anda perlu meng-inflate
Fragment untuk ditambahkan
ke UI untuk pengujian.
Jadi kami ingin ini 
dilakukan dengan satu cara.
Cara itu adalah FragmentFactory.
Cara ini memungkinkan
kita akhirnya dapat
melakukan injeksi konstruktor
ke Fragment dan tidak perlu lagi
memikirkan syarat
konstruktor tanpa argumen.
Sekarang Anda bisa
membuat sesuatu
yang bisa melakukan semuanya
untuk Anda.
Jadi inilah tampilannya.
FragmentFactory yang sederhana
hanya berupa satu metode,
yang menginstansiasi,
dan memberikan nama class.
Terserah Anda apakah
class dimuat atau tidak.
Jadi, super.instantiate
akan menggunakan pencerminan,
dan memanggil konstruktor tanpa argumen.
Anda bisa melakukan apa pun dengan ini.
Jika Anda menonton panduan
untuk injeksi dependensi,
itulah yang ingin kami lakukan

Korean: 
여러분을 대신해 해드리고 싶은 일이므로
앞으로는 직접 코딩하지 않으셔도 됩니다
하지만 지금 당장이라도 인수를
팩토리에 전달한다면
정말 일이 쉬워지는 걸 알 수 있을 겁니다
여기에 생성자 주입을 사용해 인수를
프래그먼트에
전달하는 게 쉬워지는 거죠
그럼 액티비티에서 해야 할 일은
FragmentFactory를 호출하고
팩토리와 동일하게 설정하는 것 뿐입니다
super.onCreate 이전에 설정하면 더 좋아요
프래그먼트를 다시 인스턴스화하기 때문이죠
이제 이 일관성 문제를 모두 해결하려면
다뤄야 할 부분이 있는데
사실 프래그먼트를 만드는
다른 모든 부분이죠
'커밋'을 하고
프래그먼트를 추가하면
이 전체 인스턴스화며
모든 생성자 주입을 수행하는 대신
클래스 이름으로 추가할 수 있습니다
여기에서는 실체화된 Kotlin 버전을
사용하고 있습니다

Indonesian: 
untuk Anda, jadi Anda tidak perlu
menulisnya.
Bahkan sekarang, jika Anda
memberikan argumen
ke factory, akan ada
cara mudah
untuk memberikannya
ke Fragment yang
memerlukan argumen itu,
misalnya menggunakan injeksi konstruktor.
Anda hanya perlu memanggil
FragmentFactory di aktivitas Anda
dan menyetarakannya
dengan Factory,
lebih baik sebelum super.onCreate,
karena saat itu Fragment
akan diinstansiasi ulang.
Selanjutnya yang harus dilakukan
untuk konsistensi adalah
dengan melakukan ini,
maaf, di semua tempat
pembuatan Fragment.
Jika Anda melakukan Commit dan
menambahkan Fragment, daripada
melakukan instansiasi
dan injeksi konstruktor,
cukup tambahkan dengan nama class.
Di sini, kami menggunakan
versi reified Kotlin.

Spanish: 
encantaría hacer por ustedes en algún momento
para que no tengan que escribir esto.
Pero ahora mismo, si pasan argumentos
a la fábrica, logran una manera muy sencilla
de pasarlos a los fragmentos
para los que son importantes
usando la inserción por constructor
Entonces, todo lo que tendrán
que hacer en la actividad
será invocar "FragmentFactory"
y configurarlo igual a la fábrica,
preferiblemente, antes de "super.onCreate"
porque en ese momento 
crearán nuevas instancias de fragmentos.
Lo otro que queremos hacer
para corregir y lograr
la coherencia en todas partes
es ocuparnos de todos los demás lugares
donde tenemos creación de fragmentos.
Si están realizando una confirmación
y agregan un fragmento,
en vez de crear la instancia
y hacer la inserción por constructor,
pueden agregarlo con un nombre de clase.
Aquí usamos la llamada
en la versión concreta.

English: 
love to do for you
at some point so you
don't have to write this.
But even right now, if
you just pass in arguments
into your factory, then
you get a really easy way
of just passing those
onto the Fragments that
care about them, using
constructor injection here.
So then all you need to do
in your activity is just
call FragmentFactory and set
it equal to your Factory,
preferably before
super.onCreate, because that's
when you're going to be
reinstantiating Fragments.
Now, the other bit
that we want to do
to kind of fix up all of this
consistency everywhere is--
sorry, is all the
other places that you
have Fragment creation.
So if you're doing
a Commit and you're
adding a Fragment--
now instead of having
to do this whole instantiating
and doing all that constructor
injection, you can just
add it with a class name.
Here, we're using
the [INAUDIBLE]
[? reified ?] version.

Japanese: 
依存性の注入に関するガイドでは
この構造を推奨しています
引数をファクトリに渡している場合
コンストラクタ
インジェクションを使用すれば
それらを扱うFragmentに
簡単に渡せます
Activityに必要な記述は
FragmentFactoryを呼び出し
Factoryと等しく設定することだけです
super.onCreateの前をお勧めします
Fragmentを再インスタンス化する
タイミングだからです
すべての場所で
整合性を整えるために
次に注目するのは...
Fragmentを作成する
すべての場所です
コミットを実行する場合や
Fragmentを追加する場合
すべてをインスタンス化して
コンストラクタ
インジェクションを実行する代わりに
画面のように
クラス名だけで追加できます

Portuguese: 
sabem que esse é o tipo de coisa que
adoramos fazer para poupar seu trabalho.
Mas, mesmo agora,
se você apenas passar argumentos
para "Factory", então
você tem um jeito bem fácil
de passá-los apenas para
os fragmentos que cuidam deles
usando a injeção de construtor aqui.
Então o que precisa fazer
na sua atividade
é chamar "FragmentFactory" e
definir como igual à "Factory",
preferencialmente
antes de "super.onCreate"
porque é nesse momento
que vamos reinstanciar os fragmentos.
A outra parte que queríamos fazer
para criar uma consistência geral...
São todos os outros lugares
em que há criação de fragmentos.
Se estiver fazendo uma confirmação
e for adicionar um fragmento,
agora, em vez de ter que fazer
toda a instanciação
e toda a injeção de construtor,
basta adicioná-lo
com o nome da classe.
Aqui estamos usando
a versão reificada do Kotlin.

Chinese: 
这就是我们想要为你做的事 
这样你就不必去做类似的事了
不过 即使是现在 如果你刚刚把参数传入到你的 Factory
你就可以使用构造方法注入的做法
轻松地把这些东西传入相应的 Fragment
然后 你在 Activity 中需要做的就是
调用 FragmentFactory 
并将其设置为和你的 Factory 相同
最好是在 super.onCreate 之前
因为那是你重新实例化 Fragment 的时候
我们还准备通过以下手段 
来解决各处的一致性问题
也就是其他所有创建 Fragment 的地方
如果你在做 commit 并且正在添加 Fragment
那么 与其选择实例化 进行构造方法注入
不如直接用一个类名称直接完成添加
这里我们使用的是 Kotlin 验证版本
现在 我们会代理给你的 Factory

Portuguese: 
Agora vamos delegar para sua "Factory".
Pela primeira vez, você tem
um caminho de código para instanciar
quando estiver adicionando
ou substituindo um fragmento.
Da mesma forma, quando estiver
fazendo seu "FragmentScenario",
você só passa "Factory".
Pode ser um "MockFactory"
que acabou de criar
apenas para dar 
dependências a elementos fictícios.
Ou pode ser um "Factory" real se quiser
fazer algo como um teste de integração
Agora vou passar ao Jeremy
para falar sobre outra área
em que estamos gerando consistência.
Obrigado.
Encontramos uma inconsistência
entre adicionar um fragmento
a algo como um "FrameLayout"
e usar uma tag "fragment".
a tag adiciona fragmentos usando
um sistema totalmente diferente
de transação de fragmentos.
Para gerar um
comportamento consistente,
criamos uma "FragmentContainerView"
como o contêiner real para fragmentos.
"FragmentContainerView"
estende "FrameLayout".
Mas só permite
visualizações de fragmentos.
Ou seja, usem apenas em fragmentos.

English: 
So now we'll delegate
to your factory.
And now you have one code path
for doing, instantiating, here
for the very first
time when you're adding
or replacing a Fragment.
Similarly, when you're doing
your Fragment scenario,
you just pass the factory.
It could be a mock factory
that you've created just
to give mock dependencies.
Or it could be a real
factory if you're
trying to do more
integration test-style work.
So I'm going to pass
it off to Jeremy
to talk about another area
we're working on-- consistency.
JEREMY WOODS: Thanks.
So one [? instance ?] we found
between adding a Fragment
to something like, say, a
frame layout versus using
the Fragment tag,
is it turns out
the Fragment tag
adds Fragments using
a totally different system
from Fragment transactions.
To provide consistent
behavior, we
built a Fragment Container
View as the one true container
for Fragments.
Fragment Container View
extends frame layout.
But it only allows
Fragment views.
This means if you're
not a Fragment,
you probably shouldn't
be using this.

Japanese: 
つまり Factoryに委任できるのです
１つのコードパスで
インスタンス化を行えます
Fragmentを初めて追加するか
置き換えるときに使用します
FragmentScenarioを
実行するときも
Factoryを渡すだけで済みます
模擬の依存関係を渡すには
作成した
MockFactoryを渡します
統合テストのような作業を
実行しようとしている場合は
本物のFactoryを使用します
次は 別の取り組み「整合性」について
ジェレミーが説明します
フレームレイアウトなどに
Fragmentを追加する場合と
Fragmentタグを使用する場合を比較して
気付いたことがあります
Fragmentタグは
Fragmentトランザクションとは異なる
システムを使用して
Fragmentを追加する点です
動作に整合性をもたせるには
Fragmentコンテナビューを
Fragment用の唯一の
コンテナとして作成します
このビューは
フレームレイアウトを拡張します
しかしFragmentビューのみを
許可します
つまりFragmentでない場合は
これを使用すべきではありません

Korean: 
이제 팩토리로 위임하겠습니다
여기에서 인스턴스화하기 위한
코드 경로를 갖게 됩니다
처음으로 프래그먼트를 추가하거나
교체할 때요
마찬가지로 프래그먼트
시나리오를 수행할 때도
팩토리로 전달합니다
모의 팩토리일 수 있어요
단지 모의 종속 항목을
제공하기 위해 만들어서요
또는 더 많은 통합 테스트 스타일 작업을
수행하려는 경우에는
실제 팩토리일 수 있습니다
이제 제레미에게 넘겨서
다른 분야인 일관성에 관해
이야기해보겠습니다
감사합니다
저희가 발견한 일관성 문제 중 하나는
바로 프레그먼트를 프레임
레이아웃에 추가하는 것과
프래그먼트 태그를 사용하는 것
사이에서 발생하는 비일관성이었죠
프래그먼트 태그가
프래그먼트 트랜잭션과
완전히 다른 시스템을 사용해
프래그먼트를 추가하는 것으로 나타났어요
일관된 동작을 제공하기 위해
'프래그먼트 컨테이너 뷰'를 프래그먼트의
유일한 컨테이너로 빌드했어요
'프래그먼트 컨테이너 뷰'는 
프레임 레이아웃을 확장합니다
프래그먼트 뷰에서만 허용되죠
즉, 프래그먼트가 아니라면
'프래그먼트 컨테이너 뷰'를
사용해서는 안 된다는 거예요

Chinese: 
现在你可以通过一条代码路径
来在第一次添加或替换 Fragment 的时候完成实例化
与此类似 当你在处理 FragmentScenario 的时候
只需传入 Factory 即可
它可以是你创建的模拟 Factory 
创建它只是为了给出模拟依赖
也可以是真正的 Factory
用来做更多的整合测试类工作
下面有请 Jeremy 来谈谈我们在一致性方面的另一个努力方向
谢谢
我们发现 将 Fragment 添加到 FrameLayout 
和使用  tag 中间存在一致性问题 
我们发现  tag
会使用完全不同于 Fragment 处理的方式 来添加 Fragment
为了提供一致的行为 我们将 FragmentContainerView
打造成为唯一真正的 Fragment 容器
FragmentContainerView 继承自 FrameLayout
但它只允许 Fragment 视图
也就是说 如果你不是 Fragment 
那么你可能就不该用它

Indonesian: 
Jadi sekarang mari
lakukan delegasi ke Factory Anda.
Sehingga ada satu jalur kode
untuk menginstansiasi
pertama kalinya saat menambah
atau mengganti Fragment.
Sama seperti saat Anda melakukan
skenario Fragment.
cukup berikan ke Factory,
misalnya dengan Factory tiruan
yang baru dibuat untuk
memberikan dependensi tiruan.
Atau dengan
Factory sungguhan jika
diinginkan pengujian
yang lebih terintegrasi.
Berikutnya,
Jeremy akan menyampaikan
topik selanjutnya yaitu konsistensi.
-Terima kasih.
Salah satu temuan kami
saat menambahkan Fragment
ke, misalnya, tata letak
frame dibanding menggunakan
tag Fragment adalah
bahwa tag Fragment
melakukan penambahan
menggunakan sistem
yang sangat berbeda dari
transaksi Fragment.
Agar perilaku konsisten,
kami membuat Fragment Container View
sebagai satu-satunya container
untuk Fragment.
Container ini
meluaskan tata letak frame.
Tapi hanya mengizinkan
tampilan Fragment.
Jika Anda
tidak menggunakan Fragment,
sebaiknya jangan menggunakan ini.

Spanish: 
Ahora, realizaremos
una delegación a su fábrica,
y ahora tienen una ruta de código
para crear instancias aquí
por primera vez cuando agregan
o reemplazan un fragmento.
De modo similar.
cuando hacen su FragmentScenario,
solo tienen que pasar la fábrica.
Puede ser una fábrica simulada
que crean para dependencias simuladas.
O puede ser una fábrica real
si están intentando hacer un
trabajo de integración de prueba.
Ahora voy a dejar que Jeremy
hable de la coherencia,
otro tema en que estamos trabajando.
Gracias.
Una incoherencia que encontramos
entre agregar un fragmento a,
por ejemplo, un diseño de marco
y el uso de la etiqueta de fragmento
es que la etiqueta de fragmento
los agrega mediante un sistema
distinto de las transacciones de fragmentos.
Para lograr un comportamiento coherente,
debemos crear una vista
de contenedor de fragmentos
como el verdadero contenedor de fragmentos.
La vista de contenedor
amplía el diseño de marco,
pero solo permite vistas de fragmentos.
Esto significa
que es exclusiva para fragmentos.

Indonesian: 
Ini juga bisa
mengganti tag Fragment
saat class atau atribut nama
Android ditambahkan.
Di contoh ini, karena
Fragment Container
menggunakan transaksi Fragment,
Anda tidak perlu khawatir.
Tidak akan ada masalah saat
mengganti Fragment ini nanti.
Fragment Container View
juga memungkinkan kita
untuk mengatasi masalah animasi,
khususnya masalah pengurutan z Fragment.
Di contoh tata letak frame ini,
Fragment masuk langsung muncul di layar.
Yang sebenarnya terjadi adalah
animasi masuk bergeser
tapi ada di bawah
animasi yang sudah ada.
Fragment Container View
memastikan
pengurutan z jadi kita bisa melihat
animasi bergeser
untuk Fragment masuk,
memberikan
perilaku sama yang bisa diprediksi
di seluruh tingkat API.
Masalah lama lainnya yaitu
menangani sistem dari Fragment.
Untuk itu, kami menambahkan
OnBackPressedDispatcher.

Spanish: 
También puede 
reemplazar la etiqueta de fragmento
cuando agregan la clase
o el atributo de nombre de Android.
En este ejemplo, el contenedor de fragmentos
usa realmente una transacción de fragmento,
así que no se deben preocupar,
porque no tendrán problemas
al reemplazar este fragmento más tarde.
La vista de contenedor
de fragmentos también nos permite
ocuparnos de algunos problemas de animación,
específicamente, un problema
con el orden z de los fragmentos.
Aquí podemos ver
en el ejemplo de diseño de marco,
que el fragmento entrante
aparece instantáneamente en la pantalla.
Lo que está ocurriendo aquí,
es que la animación entrante
se desliza.
Pero está debajo de la animación saliente.
La vista de contenedor
de fragmentos garantiza el orden z
para que podamos ver
la animación que se desliza
del fragmento entrante, lo que produce
un comportamiento predecible
en todos los niveles de la API.
Otro problema de larga data que tuvimos
fue cómo manejar
el sistema a partir del fragmento.
Para abordarlo, agregamos
OnBackPressedDispatcher.

Korean: 
프래그먼트 태그를 바꿀 수도 있습니다
클래스 또는 Android 이름 속성을 추가할 때 말이에요
이 예를 보면 프래그먼트 컨테이너는
그 밑에 있는 프래그먼트 트랜잭션을 
사용하기 때문에
걱정할 필요가 없고
나중에 이 프래그먼트를
교체하는 것도 문제가 없어요
'프래그먼트 컨테이너 뷰'는 또한
일부 애니메이션 문제를 해결해주죠
구체적으로 프래그먼트의 z-순서 문제를 말이죠
프레임 레이아웃 예제에서 볼 수 있듯이
시작 프래그먼트가 즉시 화면에 나타납니다
실제로 여기서 일어나고 있는 것은 
슬라이딩 형식의
시작 애니메이션인데
종료 애니메이션의 아래에 있죠
프래그먼트 컨테이너 뷰는 z-순서를
보장하므로 실제로
시작 프래그먼트에 대한
슬라이딩 애니메이션을 볼 수 있으므로
모든 API 수준에서 예측 가능한
동일한 동작을 제공합니다
또 다른 오래된 문제는 프래그먼트에서
시스템을 다시 처리하는 것입니다
이를 해결하고자
OnBackPressedDispatcher를 추가했어요

Japanese: 
クラスまたはAndroid
名前属性を追加するときに
Fragmentタグを
置き換えることもできます
この例では
Fragmentコンテナが
その下でFragment
トランザクションを使用しているため
後でこのFragmentを置き換えても
問題ありません
Fragmentコンテナビューを使用して
アニメーションの問題に
取り組むこともできます
特にFragmentの
Z-orderingの問題です
フレームレイアウトの例です
入ってくるFragmentがすぐに
画面上に表示されます
ここで起きているのは
入ってくるアニメーションのスライドです
既存のアニメーションの
下に入ります
Fragmentコンテナビューが
Z-orderingを保証するため
入ってくるFragmentの
スライドアニメーションが表示されます
すべてのAPIレベルで予測可能な
均一動作を実現します
別の問題は
Fragmentからの
システムバックの処理です
これに対処するため
OnBackPressedDispatcherを追加しました

Portuguese: 
Também é possível substituir a tag...
ao adicionar a classe
ou o atributo "android:name".
Neste exemplo,
como o "FragmentContainerView"
usa uma transação de fragmento
abaixo dele,
você não tem que se preocupar.
Não haverá problemas
em substituir esse fragmento depois.
"FragmentContainerView"
também nos deu oportunidade
de corrigir problemas com animações,
especificamente com a
ordem z dos fragmentos.
Podemos ver aqui,
no exemplo do "FrameLayout",
que o fragmento que entra
aparece instantaneamente na tela.
Na verdade, o que acontece aqui
é que a animação entra deslizando.
Mas está abaixo da
animação que está saindo.
"FragmentContainerView"
garante a ordem z
para que possamos
ver a animação deslizando
para o fragmento seguinte, o que oferece
um comportamento previsível
e estável em todos os níveis de API.
Outro problema de longa data
é lidar com o sistema
ao voltar do fragmento.
Para corrigir isso, adicionamos
"OnBackPressedDispatcher".

English: 
It also can replace
the Fragment tag
when you add the class or
Android name attribute.
So in this example, because
Fragment Container actually
does use a Fragment
transaction under it,
you don't have to worry about--
you don't have any issues with
replacing this Fragment later.
Fragment Container View
also gave us the opportunity
to address some animation
issues, specifically
an issue with z
ordering of Fragments.
So here, we can see in
the frame layout example,
the entering Fragment
instantly pops onto the screen.
What's actually happening
here is the entering animation
is sliding.
But it's underneath
the exiting animation.
Fragment Container
View ensures the z
ordering so we could actually
see the sliding animation
for the entering
Fragment, providing
predictable, same behavior
across all API levels.
Another longstanding
issue we had
is handling the system
back from Fragment.
To address this, we added
the OnBackPressedDispatcher.

Chinese: 
它还可以在添加类或添加 Android 名称属性的时候
取代  tag 
在本例中 因为 FragmentContainerView
确实会在内部中使用 Fragment 处理
所以大家无需担心
今后如何替换这个 Fragment 的问题
FragmentContainerView 还可以让我们
有机会来解决一些动画问题 
特别是 Fragment 的 z 排序问题
这里 我们可以在 FrameLayout 例子中看到
正在进入的 Fragment 会立即在屏幕上跳出
其实 这里正在进入中的动画 正在滑动
但它位于现有动画的下方
FragmentContainerView 确保了 z 排序
所以我们可以看到正在进入中的 Fragment 在滑动中的动画
从而在所有级别的 API 上提供可预测的 相同的行为
我们遇到的另一个长期问题是
如何用 Fragment 来进行系统后退操作
为了解决这个问题 我们加入了 onBackPressedDispatcher

Japanese: 
API上でFragmentを
追加する代わりに
BaseActivity
クラスコンポーネントActivityで
新しいAPIを介して
コンポーネントで戻るを扱えます
テストでは
OnBackPressedDispatcherを
注入するのが理想的でしょう
実際のコードをお見せします
Fragmentは呼び出し側の
Activityから
またはそのActivity自体から
ディスパッチャをつかみます
それからコールバックを作成します
ここで確認ダイアログを使用して
そのコールバックを作成します
それをこれに渡します
Fragmentは
ライフサイクルの所有者なので
Fragmentを渡せます
例えば
ユーザーが[戻る]を押します
[戻る]が押されたら
ShowConfirmDialogを呼び出します
ユーザーが
とにかく終了したい場合
コールバックを無効にします
ディスパッチャを使用して
BackPressedを実行します
新しいFragment APIはありません
代わりにFragmentと
アーキテクチャコンポーネントの間の
既存の統合を利用しています
アーキテクチャコンポーネントは
これからもっと
活用していきたいものです

English: 
Instead of adding a
Fragment on the API,
now any component can
handle a back via a new API
on the base activity
class component activity.
Ideally, you'd inject the
OnBackPressedDispatcher
for testing purposes.
But here, we're going to show
you how to use it in code.
So a Fragment would
grab a dispatcher
from its calling activity
or from its activity.
And then we'll
create a callback.
Here, we create that callback
using the [INAUDIBLE]..
And we pass it this.
And we can pass the
Fragment because a Fragment
is a lifecycle owner.
So for example, in your
code, the user presses back.
And then we call Show
Confirm Dialog when
the back button is pressed.
And then the user will say
they want to exit anyway.
We'll disable the callback.
And then we'll
use the dispatcher
to actually do the BackPressed.
So, no new Fragment API.
Instead, we just take advantage
of the existing integration
between Fragments and
architecture components.
So an architecture
component is something
we want to leverage
even more going forward.

Chinese: 
我们没有在 API 上添加 Fragment
现在任意组件都可以在 Activity 类中
通过新 API 处理后退操作了
在理想情况下 你可以注入 onBackPressedDispatcher
用于测试用途
不过这里 我们要展示给大家 在代码中要如何使用它
Fragment 会从调用它的 Activity 或它自己的 Activity 中获得一个 Dispatcher
然后 我们会创建一个回调
这里我们使用 Kotlin lambda 创建回调
然后把这个传入给它
然后我们传入 Fragment
因为 Fragment 是 LifecycleOwner
例如 在你的代码中 用户点击后退按钮
然后我们调用 showConfirmDialog 
然后用户表明 无论如何都要退出
这时我们会禁用回调
然后使用这个 Dispatcher 来执行 BackPressed
我们没有使用新的 Fragment API
而是利用了现有的 Fragment 和架构组件之间的整合
我们今后准备更多地利用架构组件

Portuguese: 
Em vez de adicionar
um fragmento na API,
qualquer componente pode
lidar com uma volta pela nova API
na classe de atividade básica
"ComponentActivity".
O ideal é injetar o
"OnBackPressedDispatcher"
para propósitos de teste.
Mas aqui vamos mostrar
como usar no código.
O fragmento pega um dispatcher
da atividade que faz a chamada
ou da própria atividade.
E então criamos um callback.
Aqui, criamos o callback
usando a lambda do Kotlin
e passamos isso para ele.
E podemos passar o fragmento porque
ele é um proprietário do ciclo de vida.
Por exemplo, no seu código,
o usuário pressiona "voltar"
e chamamos "showConfirmDialog"
quando o botão "voltar" for pressionado.
O usuário diz que quer sair mesmo assim.
Nós desativamos o callback
e usamos o dispatcher
para executar o "BackPressed".
Nenhuma API nova de fragmento.
Apenas aproveitamos
a integração existente
entre fragmentos
e componentes da arquitetura.
Um componente de arquitetura é algo
que queremos usar ainda mais no futuro.

Spanish: 
En lugar de agregar un fragmento en la API,
un componente puede controlar el retroceso
usando una nueva API
en la actividad de componente
de la clase de actividad base.
Lo ideal sería insertar
el OnBackPressedDispatcher
con fines de prueba.
Pero aquí, mostraremos cómo usarlo en código.
Por ejemplo, 
un fragmento toma un despachador
de la actividad invocante o de su actividad.
Luego, crearemos una devolución de llamada.
Aquí, creamos la devolución de llamada usando
la lambda a la que se lo pasamos.
Podemos pasar el fragmento porque
es propietario del ciclo de vida.
Por ejemplo, en su código,
el usuario presiona Atrás.
Luego, invocamos showConfirmDialog
cuando se presiona el botón Atrás.
Luego, el usuario dirá
que quiere salir igual,
desactivaremos la devolución de llamada
y usaremos el despachador
para presionar Atrás.
Evitamos así un nuevo fragmento en la API.
En cambio, usamos la integración
entre fragmentos y componentes.
Un componente de arquitectura es algo
que deseamos aprovechar más en el futuro.

Korean: 
API에 프래그먼트를 추가하는 대신
이제 모든 컴포넌트가 기본 
액티비티 클래스 구성요소 액티비티의
새 API를 통해 뒤로 가기를 처리할 수 있죠
테스트 목적으로
OnBackPressedDispatcher를
삽입하는 것이 좋습니다
여기에서는 코드에서
사용하는 방법을 보여 드리겠습니다
프래그먼트는 디스패처를
호출 액티비티 또는 자체 액티비티에서 가져옵니다
그런 다음 콜백을 만드는 것이죠
여기서는 Kotlin 람다를
사용하여 해당 콜백을 만듭니다
그리고 이것을 전달합니다
프래그먼트를 전달할 수 있어요
프래그먼트는 수명 주기를
가지고 있기 때문이죠
예를 들어 코드에서
사용자가 뒤로 가기 버튼을 누릅니다
뒤로 가기 버튼을 누르면
'확인 대화 상자 표시'가 호출됩니다
여기서 사용자가 종료하길 원하면
콜백을 비활성화할 것입니다
그리고 디스패처를 사용하여
실제로 BackPressed를 수행합니다
따라서 새로운 프래그먼트 API는 없습니다
대신 프래그먼트와 아키텍처 구성 요소 간의
기존 통합의 이점을 활용할 뿐이죠
따라서 이런 아키텍처 구성 요소를
앞으로 더 활용하고자 합니다

Indonesian: 
Tidak perlu menambahkan
Fragment di API,
cukup tangani kembali komponen
melalui API baru di
class aktivitas dasar
aktivitas komponen.
Biasanya, injeksi
OnBackPressedDispatcher
dilakukan untuk pengujian.
Tapi, kami akan tunjukkan
cara menggunakannya dalam kode.
Fragment akan mengambil dispatcher
dari aktivitas memanggil atau
dari aktivitasnya.
Lalu, kita buat callback.
Di sini, callback dibuat
menggunakan lambda Kotlin.
Lalu, kami menetapkan ini.
Fragment bisa ditetapkan
karena Fragment
adalah pemilik siklus hidup.
Misalnya, pengguna menekan kembali
di kode Anda.
Lalu, kami memanggil Show Confirm Dialog
saat tombol kembali ditekan.
Lalu, pengguna akan
mengonfirmasi keluar.
Callback akan dinonaktifkan,
lalu kami akan gunakan dispatcher
untuk melakukan BackPressed.
Jadi, tidak ada API Fragment baru.
Sebagai gantinya, kami
memanfaatkan integrasi yang sudah ada
antara Fragment dan komponen arsitektur.
Komponen arsitektur adalah sesuatu
ingin kami manfaatkan lebih jauh.

Japanese: 
例えば
FragmentのViewModelを
取得しやすくする必要があります
FragmentレベルやNavGraphレベル
そしてActivityレベルで
ViewModelを取得できるように
Kotlinプロパティの
拡張機能を追加しました
これでViewModelが
常に適切にスコープされます
それを実現するツールもあります
ライフサイクルでも同様です
例えばsetUserVisibleHintの
カスタムライフサイクルマップを
使用する代わりに
通常のライフサイクル
メソッドを使用して
Fragmentをビューページや
アダプタに追加できます
これはViewPage2が
現在機能する方法です
現在のFragmentのみが再開されます
イアンと代わります
ジェレミーありがとう
現在できることについて
良く分かりました
Fragment 1.1にも
たくさんありました
コンテナビューの定義は
昨日の時点でRC 1となった
Fragment 1.2で行えます
ここでもう少しお話ししたい点は
長期的な展望についてです

Spanish: 
Por ejemplo, debería ser fácil obtener
un modelo de vista para un fragmento.
Aquí, creamos
las extensiones de propiedad Kotlin
para un modelo
de vista a nivel del fragmento,
del gráfico de navegación o el de actividad,
para que el alcance 
del modelo de vista siempre se defina bien
y tengan las herramientas para ofrecerlo.
También tendemos hacia el ciclo de vida.
En lugar de usar el método de ciclo de vida
setUserVisibleHint,
ahora pueden usar
métodos de ciclo de vida normales
cuando agregan fragmentos
a una página de vista o un adaptador.
Así es cómo funciona actualmente ViewPager 2
y solo se reanudará el fragmento actual.
Le cedo el lugar a Ian de nuevo.
Genial Jeremy, gracias.
Ese fue un muy buen resumen
de lo que tenemos disponible hoy en día.
La sección Fragmento 1.1
incluyó mucho de esto.
La vista de contenedor
de fragmentos está en Fragmento 1.2,
que está en RC 1 desde ayer.
Otro tema sobre el que quiero hablar
es hacia dónde vamos en el largo plazo.

Chinese: 
例如 为 Fragment 获取 ViewModel 很容易
这里 我们用 Kotlin 创建了扩展属性 
让你可以从 Fragment 级别
NavGraph 级别 或 Activity 级别获得 ViewModel
这样一来 你的 ViewModel 会一直都位于适当的范围内
而你也会有相应的工具来获得它
我们也在更多地借力 Lifecycle
例如 我们没有使用定制生命周期方法 setUserVisibleHint
而是在为 ViewPager 或 Adapter 添加 Fragment 时
直接使用生命周期方法
目前 这就是 ViewPager2 的运作方式
只有你当前的 Fragment 会被恢复
- 有请 Ian  - 谢谢 Jeremy 
他充分地讲解了现在可用的各种工具
Fragment 1.1 中有很多这些工具
Fragment 1.2 中有 FragmentContainerView 
昨天它处于 RC1 状态
另外一件我想讲的事是
我们的长期计划

Portuguese: 
Por exemplo, deveria ser fácil receber
um "ViewModel" do seu fragmento.
Aqui, criamos as extensões
de propriedade do Kotlin.
É possível receber uma "ViewModel"
no nível "fragment",
"navGraph" ou "activity", assim
o escopo do "ViewModel" sempre está certo
e você tem as ferramentas
para fornecer isso.
Também estamos
nos voltando ao ciclo de vida.
Em vez de usar o mapa de
ciclo de vida personalizado
"SetUserVisibleHint()",
agora você pode usar métodos
regulares de ciclo de vida
quando estiver adicionando fragmentos
a um adaptador "ViewPager1".
É assim que "ViewPager2" funciona.
E apenas o fragmento atual será retomado.
De volta para o Ian.
Obrigado, Jeremy.
Esse foi um ótimo resumo
do que está disponível no momento.
O Fragment 1.1 tem
muito disso.
"FragmentContainerView"
está em Fragment 1.2,
que está na RC1 desde ontem.
Mas queria falar um pouco mais
sobre aonde vamos
no longo prazo.

English: 
So for example, it should
be easy to get a View
model for your Fragment.
And here, we created the
Kotlin Property Extensions
so you can get a view model
at the Fragment level, the Nav
Graph level, or
the Activity level
so your View model is
always properly scoped
and you have the
tools to provide that.
We're also leaning to
the lifecycle as well.
For example, instead of
using the custom lifecycle
map of Set User
Visible Hint, you
can now just use regular
lifecycle methods
when you're adding Fragments
to a View page or one adaptor.
And so this is currently
how View Page 2 works.
And only your current
Fragment will be resumed.
Back to Ian.
IAN LAKE: Great.
Thanks, Jeremy.
That was a really good rundown
of what's available right now.
So Fragment 1.1
had a lot of this.
Defining Container View
is in Fragment 1.2, which
is in RC 1 as of yesterday.
But the other thing is I wanted
to talk a little bit more
about where we're going
kind of longer term.

Korean: 
예를 들어 프래그먼트에 대한 뷰 모델을
쉽게 얻을 수 있어야 합니다
여기에서 'Kotlin 속성 확장'을 생성하여
뷰 모델을 얻을 수 있습니다
프래그먼트 수준, 탐색 그래프 수준
또는 액티비티 수준에서 말이죠
이런 식으로 뷰 모델의 범위가
항상 적절하게 지정되고
이를 위한 툴도 지원되죠
또한 수명 주기도 활용하고 있습니다
예를 들어 '사용자 가시성 힌트 설정'의
맞춤형 수명 주기 맵을 사용하는 대신
일반 수명 주기 매서드를 사용할 수 있어요
뷰 페이지 또는 어댑터 하나에
프래그먼트를 추가할 때요
이것이 현재 뷰 페이지 2의 작동 방법입니다
현재 프래그먼트만 재개되는 것이죠
다시 이안이 설명하겠습니다
좋아요
고마워요 제레미
현재 가능한 것에 대한
아주 훌륭한 요약이었어요
프래그먼트 1.1에는
이런 좋은 기능이 많죠
'컨테이너 뷰 정의'는
프레그먼트 1.2에 있습니다
어제부로 RC 1에 접어들었죠
이제 장기적으로 어떤 방향으로
발전해야 하는지에 대해서
조금 더 이야기하고 싶습니다

Indonesian: 
Misalnya, mendapatkan
model View untuk
Fragment seharusnya mudah.
Jadi, kami membuat
Kotlin Property Extensions
agar Anda mendapatkan model View
di level Fragment,
level Nav Graph, atau
level Activity, jadi
model View selalu
punya cakupan yang tepat
dan Anda punya alat
untuk menyediakannya.
Kami juga punya rencana
untuk siklus hidup.
Misalnya, alih-alih menggunakan
peta siklus hidup kustom
Set User Visible Hint, kini Anda bisa
menggunakan metode siklus hidup reguler
saat menambahkan Fragment ke
View Page atau satu adaptor.
Inilah cara kerja ViewPage 2.
Hanya Fragment saat ini
yang akan dilanjutkan.
Silakan, Ian.
-Oke. Terima kasih Jeremy.
Pembahasan yang sangat bagus
terkait apa yang ada sekarang.
Fragment 1.1 memiliki banyak hal ini.
Menentukan Container View
ada di Fragment 1.2, yang ada di
RC 1 mulai kemarin.
Saya ingin tambahkan
sedikit tentang rencana kami
untuk jangka panjang.

Chinese: 
我们想做的事情有很多
所以这里和大家简要预览一下我们正在进行的一些项目
不过 当然 因为这些项目都还没有推出
所以一切细节均有可能改变
我们对项目的走势很看好
不过现在还没办法提供给大家使用
首先 多返回栈 (Multiple Back Stack)
有的人可能听说过它 它确实存在
不过 它其实只是 Android 现存的遗留产物之一
在 Android 上 尤其是在 Activity 级别上
总是存在着一个 Activity 栈
Fragment 最后继承了同样的结构
保留下来的只有返回栈上的东西
我们很想使用这样的模型：
同时支持两者 即单一栈方式和多栈方式
这意味着 我们允许大家保存

Korean: 
앞으로 하고 싶은 일은 많이 있습니다
그래서 지금 진행하고 있는
일부 프로젝트를 살짝
소개하려 합니다
물론 아직 진행 중이기 때문에
변경될 수 있습니다
이런 발전 방향에 매우 만족스럽습니다
하지만 오늘 당장 사용할 수 있는 것은 아니에요
그럼 첫 번째는 다중 백 스택입니다
몇몇 분은 아마 들어보셨을 거예요
꽤나 주목 받고 있죠
그러나 실제로 이 중 일부는
Android의 기존 레거시와 관련이 있어요
따라서 특히 Android에서는 
액티비티 수준과 마찬가지로
항상 단일 액티비티 스택이었습니다
그리고 프래그먼트는 결국
그런 동일한 구조를 물려받게 되었어요
백 스택에 있는 것만 저장되는 것이죠
그래서 저희가 개발하고자 한 모델은
단일 스택 접근 방법뿐만 아니라
다중 스택 접근 방법을 모두 지원하는
그런 모델이었죠
여러분이 실제로

Portuguese: 
Há muitas outras coisas
que queremos fazer.
Vou compartilhar uma prévia
de alguns projetos atuais.
Claro que, como nada 
disso foi lançado ainda,
tudo está sujeito a mudanças.
Estamos felizes com a direção tomada.
Mas ainda não dá
para vocês testarem ainda.
Para começar,
múltiplas pilhas de retorno.
Alguns de vocês
já devem ter ouvido falar.
Elas existem.
Na verdade, tem a ver
com aquele legado existente do Android.
No Android, em especial,
no nível de atividade,
sempre houve uma pilha
única de atividades.
E os fragmentos acabam
herdando a mesma estrutura
em que as únicas coisas salvas
são as que estão na pilha de retorno.
E queremos mudar para um modelo
com suporte a pilhas únicas e múltiplas.
Na verdade, isso significa o seguinte:
permitimos que você salve
o estado dos fragmentos

Indonesian: 
Ada banyak hal lain yang
ingin kami lakukan.
Saya akan berikan sedikit gambaran
beberapa proyek
yang sedang kami kerjakan.
Tentu saja,
karena belum diluncurkan,
proyek ini bisa berubah.
Kami cukup senang dengan kemajuannya.
Tapi, Anda belum bisa
menggunakannya sekarang.
Pertama adalah
Multiple Back Stacks.
Mungkin sudah ada yang
pernah mendengarnya.
Ini cukup populer.
Tapi memang benar, beberapa
di antaranya berasal
dari komponen lama
yang ada di Android.
Jadi khususnya di Android,
level Activity selalu berupa
satu tumpukan aktivitas.
Dan Fragment akhirnya mewarisi
struktur yang sama, dan
yang disimpan hanyalah
apa yang ada di Back Stack.
Kami ingin beralih ke model
yang bisa mendukung keduanya,
bukan hanya satu tumpukan,
tapi juga lebih dari satu tumpukan.
Itu artinya Anda bisa menyimpan

Japanese: 
行いたいことが他にも
たくさんあります
現在進行中のプロジェクトの
プレビューについて
少し共有したいと思います
もちろん
まだ正式版ではないため
変更される可能性があります
出来映えは上々ですが
提供は まだ先のことです
最初のものは
「複数バックスタック」です
これについて聞いたことが
ある方もいるかもしれません
これはAndroidで既存の
レガシーの問題に行き着きます
Androidでは特に
Activityが単一スタックでした
Fragmentも結局は
同じ構造を引き継ぎ
保存されるものは
バックスタック上のものだけでした
両方をサポートするモデルに
移行したいと考えました
単一スタックのアプローチだけでなく
複数スタックのアプローチも
サポートするものです
それはつまり
画面上に表示されていない

English: 
There's a lot of other
things that we want to do.
So I'm going to
share a little bit
of a preview of some of the
projects that we're working on.
But of course, because
none of this is out yet,
this is all subject to change.
We're pretty happy with
where this is all going.
But it's not something you
can play with right today.
So the first thing is
Multiple Back Stacks.
Some of you may
have heard of this.
It's a thing.
But really, some
of this comes down
to just that existing
legacy on Android.
So on Android especially,
at like the Activity level,
it was always a single
stack of activities.
And Fragments just
ended up inheriting kind
of that same structure where
the only things that are saved
are the things that
are on the Back Stack.
And we really want
to move to a model
where we kind of
support both, not just
the single stack
approach but also
the multiple stack approach.
And really, that
just means that we

Spanish: 
Hay muchas otras cosas que queremos hacer.
Así que voy a compartir un poco
de una vista previa de unos
proyectos en los que estamos trabajando.
Pero, por supuesto, 
ninguno de estos se publicó aún;
así que todo puede cambiar.
Estamos contentos
con cómo se están dando las cosas.
Pero esto no es algo
con lo que puedan jugar hoy.
Lo primero es la opción
de varias pilas de actividades.
Quizá algunos de ustedes
hayan oído hablar sobre esto.
Es algo real.
En realidad, parte de esto se reduce
al sistema heredado existente de Android.
En Android, especialmente
en el nivel de actividad,
siempre se trataba 
de una única pila de actividades.
Los fragmentos acababan heredando
casi la misma estructura,
donde lo único que se guardaba
era lo que estaba en la pila de actividades.
Realmente queremos pasar a un modelo
que admita ambos enfoques,
no solo el de la pila única,
sino también 
el de varias pilas de actividades.
En realidad, eso quiere decir
que permitimos guardar
el estado de los fragmentos

Japanese: 
Fragmentの状態を失うことなく
保持するということです
このアプリは過去の事例です
ボトムナビゲーションや
ナビゲーションビューを使いっています
このサンプルアプリでは
回避策を使用しています
回避策とは
扱いにくいFragmentコードです
これをFragmentレベルで
簡単に行えるようにしたいと考えています
新しいアプローチでは
各タブで独自の
スタックを持てるようにします
独自の状態を保持できます
これらのタブを切り替えると
保存するのと同時に
別のスタックを復元します
スタック間のナビゲーション時に
状態の保存と復元を
処理するアプローチです
回避策を検討している別の点は
結果の返し方に関するものです

Chinese: 
屏幕上不可见的 Fragment 的状态
相关的例子包括底部导航 导航视图
现在我们就有一个样品应用
它使用了一个取巧的办法
之所以说它取巧 是因为这些 Fragment 代码写得不够好看
我们只是想让它在 Fragment 层面上简单易用
我们采取的方式 也是这些标签页所采用的
也就是 每个标签页都有它自己的栈 得以保留自己的状态
随着你在这些标签页之间切换
其实就是在保存 恢复一个与之前不同的栈
当你在不同的栈之间切换的时候
我们负责恢复和保存所有的状态
我们想要设法解决的另一个问题是 返回结果

Portuguese: 
que não estão visíveis na tela
sem perder o estado deles.
Estes são alguns
dos casos que apareceram.
Coisas como navegação inferior e
visualizações de navegação.
E temos um app de amostra agora
que usa uma solução alternativa.
Eu digo isso, mas é um código
de fragmento "desagradável".
Nós queríamos facilitar
no nível do fragmento.
A abordagem que estamos adotando
é a mesma capacidade
em que cada uma destas guias
pode ter a própria pilha.
Cada uma tem o próprio estado.
Então. conforme você alterna entre elas,
tem mais a ver com
salvar e restaurar uma pilha diferente.
E nós cuidamos de fazer a restauração e
gravação dos estados de uma pilha a outra.
A outra parte que queremos corrigir
é o retorno de resultados.

Indonesian: 
status Fragment
yang tidak terlihat di layar
tanpa kehilangan statusnya.
Ya. Ini beberapa masalah
yang ditemukan.
Contohnya adalah
Bottom Nav dan Navigation Views.
Mari kita lihat contoh aplikasi
yang menggunakan suatu trik.
Saya bilang trik
karena ini kode Fragment yang buruk.
Kami hanya ingin mempermudah
pada level Fragment.
Jenis pendekatan yang kami lakukan
adalah kemampuan
yang memungkinkan setiap tab ini
punya tumpukannya sendiri.
Dan punya status sendiri.
Jadi, saat berpindah tab,
sebenarnya sama seperti
menyimpan lalu memulihkan
tumpukan lain.
Kami menangani semua
pemulihan
dan penyimpanan status
saat berpindah antartumpukan.
Hal lain yang ingin kami atasi
adalah menampilkan hasil.

Spanish: 
que no están visibles en pantalla,
sin que estos pierdan su estado.
Estos son algunos de los casos que surgieron.
Por ejemplo, navegación inferior
y vistas de navegación.
Ya tenemos una app de muestra
que usa una especie de solución alternativa.
Digo "solución alternativa" porque
es un molesto código de fragmento.
Y, en realidad, queremos
que esto sea realmente sencillo
en el nivel del fragmento.
Por lo tanto, el enfoque que estamos usando
es la misma capacidad
para que cada una de estas pestañas
tenga realmente su propia pila.
Para que tengan su propio estado.
Es decir, cuando alternan entre estas,
se trata de guardar y, luego,
restablecer una pila distinta.
Nosotros nos encargamos
de restablecer y guardar el estado
a medida que pasan de una pila a otra.
También buscamos una solución alternativa
para la devolución de resultados.

English: 
allow you to save the state of
Fragments that aren't actually
visible on the screen
without losing their state.
So this is some of the
cases that came up.
It was really like, Bottom Nav,
things like Navigation Views.
And we have a
sample app right now
that uses kind of a little
bit of a work-around.
I say work-around-- it's
some nasty Fragment code.
And really, we just want to
make this really easy at kind
of the Fragment level.
So kind of the approach
that we're taking
is kind of that same ability
where each one of these tabs
can actually have its own stack.
So it has its own state.
So as you swap
between these, it's
really more about saving
and then restoring
a different stack.
And we're taking care
of doing all the state
restoration and state saving
as you go from stack to stack.
The other bit that we
want to work around
is around returning results.

Korean: 
화면에서 볼 수 없는 프래그먼트의 상태를
잃지 않고도 저장할 수 있습니다
그래서 이런 사례들이 발생하는 거죠
Bottom Nav, Navigation Views 같은 것들 말이죠
지금 샘플 앱이 있는데
임시 해법을 사용하고 있어요
해결 방법이 까다로운
일종의 프래그먼트 코드가 있어서요
저희는 이 코드를 정말 쉽게 만들고 싶어요
프래그먼트 수준에서요
저희가 취하고 있는 접근방식은
이러한 각각의 탭이 자체 스택을
가질 수 있는 방식과 동일한 방식입니다
따라서 자체 상태를 가지고 있죠
이 두 사이를 전환하면서
저장한 다음 다른 스택을 복원하는
그런 것에 관한 거죠
그리고 스택 간 이동에 따라
모든 상태 복원과
상태 저장에 대해 신경 쓰고 있어요
해결하고 싶은 다른 부분은
결과를 반환하는 것입니다

Spanish: 
Escuchamos que se preguntan mucho
cómo hablar entre fragmentos.
¿Cómo hablo entre un
un elemento y otro en Android?
Hay muchas maneras distintas de hacerlo.
Algunas son mejores que otras.
Además, las API de fragmento
que tenemos en la actualidad
no son grandiosas.
Tenemos una API
definida de fragmento de destino
que permite conectar un fragmento con otro
y, básicamente, mantener
una referencia sólida a otro fragmento.
Pero, en esencia, no aporta
nada para el ciclo de vida
de lo que es el otro fragmento.
Si el otro fragmento
está en la pila de actividades,
está detenido; en realidad,
no está iniciado;
si le hablan a ese fragmento
y tratan de hacer transacciones de fragmento,
esa operación fallará
porque no están en Iniciado.
Por lo tanto,
no tenemos ese tipo de garantías
respecto de en qué estado
ese otro fragmento se encontrará.

Indonesian: 
Kami banyak dengar informasi seperti
bagaimana menghubungkan
antar-Fragment?
Bagaimana cara menghubungkan
berbagai hal di Android?
Selalu ada banyak cara berbeda
untuk melakukannya,
beberapa lebih baik dari cara yang lain.
Dan ternyata API Fragment
yang kami miliki saat ini tidak bagus.
Kami punya seluruh target
API Fragment yang ditetapkan ini
agar Anda bisa menghubungkan
satu Fragment dengan yang lain,
dan pada dasarnya, terus merujuk
ke Fragment lain.
Dan tidak melakukan apa pun
untuk siklus hidup
Fragment lain lain itu.
Jika Fragment lain itu ada di
Back Stack,
Fragment tersebut terhenti.
Tidak dimulai.
Upaya menghubungkan
Fragment itu
dan melakukan
transaksi Fragment
dan lainnya akan gagal karena
memang tidak dimulai.
Jadi tidak ada kepastian
akan seperti apa
status Fragment lain itu?

English: 
So we've heard a lot of
information where you're like,
how do I talk between Fragments?
How do I talk between
anything on Android?
It's always kind of--
there's lots of different
ways of doing it,
some better than others.
And it turns out
that the Fragment
APIs we have right
now are not great.
So we have this whole
set target Fragment
API that allows you to connect
one Fragment with another,
and basically just keep a hard
reference to another Fragment.
But it basically does
nothing for the lifecycle
of what that other Fragment is.
So if that other Fragment
is on the back stack,
it's actually stopped.
It's not started.
And if you actually
talk to that Fragment
and it's trying to do
like Fragment transactions
and stuff, that's going to fail
because you're not started.
So we really don't have
any kind of guarantees
around like, what state is
that other Fragment actually
going to be in?

Portuguese: 
Muitos de vocês perguntaram:
"Como fazer
a comunicação entre fragmentos?"
Como fazer isso
com qualquer elemento no Android?
É sempre meio...
Há várias maneiras de fazer isso,
umas melhores que outras.
Na verdade,
as APIs de fragmento atuais não são boas.
Temos a API setTargetFragment,
que permite conectar fragmentos
e basicamente mantém
uma referência fixa a outro fragmento.
Mas não informa o que é o fragmento.
Então, se ele estiver
na pilha de retorno, está parado.
Não está iniciado.
Se você se comunicar com ele
e tentar fazer transações de fragmentos,
ele vai falhar porque não foi iniciado.
Então não temos garantias
sobre o estado do outro fragmento.

Japanese: 
“Fragment間で
どうやり取りしたら良いか？”
“Android上で
どうやり取りしたら良いか？”
といった質問が多く寄せられました
それらを行う方法は
たくさんあります
あるものは別のものより
優れています
現在使用しているFragment APIは
やや力不足です
１つのFragmentを
別のものと接続するには
setTargetFragment APIを使えます
別のFragmentへの
ハード参照を保持するものです
しかし 別のFragmentの
ライフサイクルに対しては無力です
別のFragmentが
バックスタック上にあると
停止してしまいます
開始しません
そのFragmentと
やり取りしようとして
Fragmentトランザクション
を実行しようとすると失敗します
開始していないからです
これでは 別のFragmentの状態を
上手くコントロールできません

Korean: 
여러분께 많은 질문을 듣고 있어요
예를 들면 프래그먼트 간의
통신이 어떻게 이루어지나요?
Android에서는 어떻게 통신하나요?
같은 거죠
항상
다양한 방식이 있어요
더 나은 방법도, 그렇지 않은 것도 있고요
그리고 지금 가지고 있는
Fragment API가 그다지
좋지는 않은 걸로 드러났죠
그래서 하나의 프래그먼트를 
다른 프래그먼트와 연결하도록 하는
전체 세트 타겟 프래그먼트 API가 있어요
기본적으로 다른 프래그먼트에 대한
하드 참조를 쓰지만
다른 프래그먼트의 수명 주기에는
아무런 영향을 미치지 않습니다
따라서 다른 프래그먼트가 백 스택에 있으면
실제로 중지됩니다
시작되지 않는거죠
또한 해당 프래그먼트와 통신하고 
프래그먼트 트랜잭션 같은 것을
수행하려고 한다면
시작하지 않았기 때문에 실패할 것입니다
그래서 어떤 보장도 없는 거죠
예를 들면 다른 프래그먼트가 실제로
어떤 상태에 있는지와 같은 것 말이죠

Chinese: 
很多人向我们询问 不同的 Fragment 之间如何沟通
或者说和 Android 上其他的任何东西如何沟通
做到这一点 有很多不同的方式 其中当然有优劣之分
最后事实证明 我们的 Fragment API 还不够好
我们的这个设置目标 Fragment API 
可以让你把多个 Fragment 连接起来
也就是让多个 Fragment 之间保持硬引用
但是 它几乎完全不涉及另一个 Fragment 的生命周期
如果另一个 Fragment 现在在返回栈里
它是停下来的状态
不是被启动的状态 
如果你和那个 Fragment 沟通
并试图进行 Fragment 处理
那么你会失败 因为它没有启动
所以 我们无法保证 
其他 Fragment 将会处于什么状态之中

Chinese: 
此外 我们还认为 你可以使用 onActivityResult
我在想 是从 Fragment 到 Fragment 吗？
这样就比较奇怪了
因为我们无需重新使用这些 API 来做回调
我们是用比较整体性的视角来看待它的
不仅限于 Fragment 到 Fragment 
还包括 startActivityForResult
我们能把同样的 API 用在 startActivityForResult 上
用在不同 Fragment 之间的沟通
以及不同导航目标之间的沟通吗？
我们能不能提供一个公用的 API
让它们都可以用它来沟通
这样一来 当你构建回调的时候
就不必担心它是否来自不同的 Activity 或 Fragment 了
我们认为 这些 API 的用途大概就是这样
很期待能在几个月之后跟大家分享它

Portuguese: 
Além disso, havia a ideia de que
era possível usar "onActivityResult".
Mas intents?
De fragmento para fragmento?
Parece estranho.
Não precisamos reutilizar algumas
dessas superfícies de API para callbacks.
Então estamos analisando
de forma mais geral,
não apenas de fragmento
para fragmento,
mas coisas como
"startActivityForResult()".
Podemos fazer a mesma superfície de API
para "startActivityForResult",
para comunicação entre fragmentos
e de um destino de navegação a outro?
Podemos oferecer uma API comum
em que todos esses elementos
possam se comunicar de forma que,
ao criar callbacks, não importa
se está vindo de uma atividade
ou de um fragmento diferente?
É assim que vemos
o futuro de muitas dessas APIs.
Espero poder compartilhar
um pouco disso com vocês
em alguns meses, talvez.

Spanish: 
Además, teníamos esta idea
de que se puede usar onActivityResult.
Yo digo: "¿actividad intensa
de un fragmento a otro?"
Me parece medio raro.
En realidad, no es necesario reutilizar
algunas de estas superficies de API
para las devoluciones de llamadas.
Por eso, estamos observando
esto de una manera más holística,
no solo fragmento por fragmento,
sino también, por ejemplo,
startActivityForResult.
¿Podemos crear
el mismo tipo de superficie API
para startActivityForResult,
para comunicación de fragmento a fragmento
y para destino de navegación
a destino de navegación?
¿Podemos proporcionar una API común
a la que estas cosas puedan hablarle
cuando crean devoluciones de llamadas?
No importa, en realidad,
si proviene
de otra actividad o de otro fragmento.
Creemos que es allí a donde se dirigen
muchas de esas API.
Estoy entusiasmado
porque compartiremos algo de eso
en unos pocos meses, quizá.

English: 
Additionally, we
had like this idea
that, oh, you can use
On Activity Result.
And I'm like, intense
from Fragment to Fragment?
That feels kind of weird.
Like, we don't really need to
be reusing some of these API
surfaces for callbacks.
So we're really kind of looking
at this more holistically,
not just Fragment to
Fragment, but also
things like start
startActivityForResult.
Can we do kind of
the same kind of API
surface for
startActivityForResult,
for Fragment to
Fragment communication,
from Navigation Destination
to Navigation Destination?
Can we provide a common API
that all these things can
[? time ?] to talk at so that
when you're building callbacks,
it doesn't actually
matter if it's
coming from a different activity
or a different Fragment.
So that's kind of where we
kind of see a lot of those APIs
going.
I'm really excited to share some
of that in just a few months,
maybe.

Indonesian: 
Selain itu, ada ide misalnya
menggunakan
On Activity Result.
Intent
dari Fragment ke Fragment?
Sepertinya sangat aneh.
Kita tidak perlu menggunakan kembali
beberapa permukaan
API ini untuk callback.
Kami benar-benar melihat hal ini
secara holistik,
bukan hanya Fragment ke Fragment,
tapi juga hal seperti
memulai startActivityForResult.
Apa kami bisa melakukan
jenis permukaan API
yang sama untuk
startActivityForResult,
untuk komunikasi Fragment ke
Fragment,
dari Navigation Destination
ke Navigation Destination?
Kami berusaha menyediakan API umum
yang bisa berkomunikasi
dengan semua hal ini
agar saat Anda membuat callback
tidak masalah jika berasal
dari Activity atau Fragment lain.
Jadi, seperti inilah kira-kira
cara kerja API nantinya.
Saya tak sabar memberi info baru
dalam beberapa bulan mendatang.

Korean: 
게다가 On Activity Result를
사용할 수 있다고 생각했습니다
그리고 프래그먼트 간 집중?
이것은 좀 이상하죠
마찬가지로 콜백에 이러한 API 표면 중 일부를
재사용할 필요는 없습니다
그래서 좀 더 전체적으로 보고 있어요
프래그먼트 간뿐만 아니라
startActivityForResult와 같은 것도요
동일한 종류의 API 표면을
startActivityForResult
프래그먼트 간 통신
그리고 탐색 대상 간에
사용할 수 있는지 말이에요
통신이 가능한 공통 API를 제공하여
콜백을 빌드할 때
다른 액티비티나 프래그먼트에서
오는 것이 중요하지 않도록
할 수 있는지 말이죠
그리고 이러한 API가 앞으로
많이 나올 것으로 봅니다
몇 달 안에 그중 일부를
소개할 수 있을 거고요
아마도요

Japanese: 
このようなアイデアもありました
onActivityResultを使用する
というものです
しかし Fragment間でインテントを
使うのは変です
コールバックに関する
APIサーフェスのいくつかは
再使用する必要がありません
これらをもっと全体的に考えています
Fragment間だけではなく
startActivityForResultを
開始するような感じです
Fragment間のやり取りに対して
ナビゲーションの宛先から
ナビゲーションの宛先へ
startActivityForResult
と同じような
APIサーフェスを実行できることが理想です
すべてがやり取りできる
共通のAPIを提供できれば
コールバックの構築時に
ActivityやFragmentへの依存を避けられます
こうしたAPIが 今後の目標です
発表を楽しみにしています...
数か月かな

Chinese: 
关于 Fragment 还有一个反馈是我们常常收到的
也就是关于生命周期的反馈 这个难度很高对吧？
而且 Fragment 的生命周期可以说是难上加难
因为 Fragment 有两个生命周期
Fragment 本身有一个生命周期
也就是当 Fragment 被附加到 FragmentManager 上的时候
一直持续到它被从管理器中移除并销毁为止
此外 Fragment 视图还有一个完全独立的生命周期
如果你把什么东西放进返回栈
它的视图就会被销毁 但 Fragment 还会继续存留
这里有一个疯狂的想法 如果合二为一会怎样？
我们在想 如果在 Fragment 视图被销毁的时候
Fragment 本身也被销毁 会怎么样呢
如果我们想要重新创建视图 只需重新创建 Fragment 即可
把二者整合起来 简化了很多东西

Spanish: 
El otro tema sobre el que constantemente
escuchamos opiniones
de los fragmentos es el ciclo de vida.
Eso es difícil, ¿verdad?
Es doblemente difícil con los fragmentos,
porque los fragmentos tienen dos ciclos.
El fragmento en sí tiene un ciclo de vida,
que es cuando el fragmento se conecta
al administrador de fragmentos
hasta que se lo quita de ahí
y se lo destruye.
Pero la vista de fragmentos
tiene un ciclo de vida independiente
en el que cuando colocamos algo
en la pila de actividades,
la vista se destruye,
pero el fragmento sobrevive.
Pensemos en una idea loca:
¿qué ocurriría si fueran lo mismo?
¿Qué ocurriría
si cuando la vista del fragmento
se destruye, el fragmento
se destruyera al mismo tiempo?
Entonces, cuando queremos recrear la vista,
recreamos el fragmento.

Portuguese: 
Outro feedback que sempre recebemos
é sobre o ciclo de vida dos fragmentos.
É difícil, né?
É duas vezes pior com fragmentos
porque eles têm dois ciclos de vida.
O fragmento em si tem um ciclo de vida,
desde quando é anexado ao gerenciador
até ser removido dele e destruído.
Mas a visualização de fragmentos
tem um ciclo totalmente separado,
em que, quando você coloca
algo na pilha de retorno,
a visualização dele é destruída,
mas o fragmento perdura.
Então que tal
se eles fossem a mesma coisa?
Tivemos uma ideia.
E se, quando a visualização do fragmento
fosse destruída, ele também fosse?
Então, ao recriarmos a visualização,
o fragmento é recriado.

Japanese: 
Fragmentに関して
よく受け取るフィードバックは
ライフサイクルに関するものです
厄介ですよね？
Fragmentになると
さらに難しくなります
Fragmentには
２つのライフサイクルがあるからです
Fragment自体に
ライフサイクルがあります
FragmentがFragment
マネージャに渡されてから
Fragmentマネージャにより
削除 破棄されるまでです
Fragmentビューにも
別個のライフサイクルがあります
バックスタックに配置した場合
ビューが破棄されても
Fragmentは存続します
それらを同じにしたら
どうなるでしょうか？
Fragmentのビューが破棄されたときに
Fragmentも同時に破棄されると
どうなるでしょうか？
ビューを再作成したいときは
Fragmentも再作成します
これらを一緒にすると
かなり複雑さが解消されます

English: 
The other thing is
something we've constantly
heard feedback on
Fragments is lifecycle.
Like, that's hard, right?
Well, it's like doubly
hard with Fragments
because Fragments
have two life cycles.
The Fragment itself
has a lifecycle, which
is when the Fragment is actually
attached to the Fragment
manager until it's removed from
the Fragment manager and gets
destroyed.
But the Fragments view has
a totally separate lifecycle
where when you actually put
something on the back stack,
its View gets destroyed
but the Fragment lives on.
So crazy idea, what
if they were the same?
So we have this idea for what
if, when the Fragment's view is
destroyed, the Fragment was
destroyed at the same time.
And then when we want
to recreate your View,
we recreate your Fragment.
And bringing these
things together saves

Korean: 
다른 하나는 프래그먼트 수명 주기에 관한
의견에서 끊임없이 들려오고 있는 것입니다
어려운 문제죠?
특히 프래그먼트라 어려움이 두 배군요
프래그먼트에는 두 개의
수명 주기가 있기 때문이죠
프래그먼트는 자체 수명 주기를 가지는데
프래그먼트 관리자로부터 제거되어 파괴될 때까지
프래그먼트가 프래그먼트 매니저에
연결되어 있는 거죠
그러나 프래그먼트 뷰는 
완전히 분리된 수명주기를 가지고 있어서
백 스택에 무언가를 넣을 때
뷰가 파괴되지만
프래그먼트는 계속 유지됩니다
만약 이 두 개가 같다면 어땠을까요?
만약 이 두 개가 같아서 
프래그먼트의 뷰가 파괴될 때
동시에 프래그먼트가
파괴된다면 어땠을까 생각했습니다
그렇다면 뷰를 다시 만들고 싶을 때
프래그먼트를 다시 만들어야 하죠
그리고 이러한 것이 모이면

Indonesian: 
Selain itu, kami sering mendapat
masukan tentang siklus hidup Fragment.
Mereka berkata, "itu sulit kan?"
Ya, Fragment sangat sulit
karena memiliki dua siklus hidup.
Fragment itu sendiri memiliki
satu siklus hidup, yaitu saat Fragment
tertaut ke pengelola Fragment lain
hingga dihapus dari pengelola Fragment
dan dihancurkan.
Tapi, View Fragment memiliki
siklus hidup yang sepenuhnya terpisah.
Jika Anda menyimpan sesuatu
di Back Stack,
View-nya dihancurkan
tapi Fragment masih ada.
Jadi bagaimana jika
keduanya adalah hal yang sama?
Kami punya ide,
jika View dihancurkan,
Fragment juga dihancurkan
pada saat yang sama.
Lalu jika ingin membuat ulang View,
Fragment dibuat ulang.
Menyatukan keduanya mengurangi

Korean: 
복잡성이 많이 줄고
어떤 경우에도 해야 하는 FragmentFactory와
모든 저장 상태가 기본이 됩니다
예를 들면 구성 변경, 프로세스, 종료를 하고
다시 돌아오는 그런 것 말이죠
이제 하나의 코드 경로만
테스트하면 됩니다
예를 들면 지금 어떤 상태에 있는 건지
이 수명 주기 변화 때문에
관찰자가 오작동하고 있는 건지요
이제 이것이 큰 변화라는 것을 알고 있습니다
그래서 이걸 선택적인 API로
만드는 데 주력하고 있어요
프래그먼트 액티비티 수준에서요
따라서 프래그먼트 액티비티의 모든 것이
훨씬 더 간소화된 수명 주기가 있는
이 새로운 세계로 옮겨 갈 것입니다
저희는 이 모든 것이 출시되는 순간을
정말로 기대하고 있습니다
의견이 있으시면 샌드박스에서
말씀해 주시면 감사하겠습니다

English: 
so much complexity
and means that things
like FragmentFactory
and all the saving
state that you have to
do anyways for cases
like, oh, I'm on configuration
change, the process, death,
and coming back, Now, that just
becomes the default option.
And now we only have to
test one code path of like,
wait what state am I in?
Are my observers doing
the wrong thing here
because these
switching life cycles?
Now, I do realize this
is a bigger change.
So we are looking at making this
kind of an opt-in kind of API
at the Fragment
activity kind of level.
So everything in that
Fragment activity
would all move to
this new world where
we have a much more
simplified lifecycles case.
So we're really looking
forward to releasing
all of these things.
And we'd really
appreciate it if you
can talk to us in the Sandbox
if you've got any feedback.

Japanese: 
これにより FragmentFactoryなど
とにかく保存する必要があるもの
つまり構成変更 プロセス 終了
戻るなどが
デフォルトオプションになります
１つのコードパスだけを
テストすればよくなります
“今の状態は何だっけ？”
“これはライフサイクル
の切り替えだから
オブザーバーは間違ったことを
している？”などです
これは大きな変更です
Fragment Activityのレベルで
このようなAPIのオプトインを行う
ことを検討しています
Fragment Activityの全体を
新しいアプローチに移し
ライフサイクルを
もっとシンプルにしたいと考えています
これらすべてを
リリースできることを
楽しみにしています
何かフィードバックがありましたら
是非Sandboxで
お知らせください

Chinese: 
同时意味着 例如 FragmentFactory 和保存状态之类东西
你反正是要在配置更改 流程 消亡并重生 之类的地方用到它的
现在它直接变成了默认选项了
现在我们只需要测试一个代码路径：我正处在哪个状态下
我的观察者是否正在因为这些切换中的生命周期做出错误的事情？
我知道 这是一个不小的改动
所以 我们把它做成了一个在 FragmentActivity 这种层面
可以选择加入的 API
FragmentActivity 内部的所有东西都会转移到这个新世界之中
在这里 我们的生命周期用例会简单得多
我们很想尽快发布所有这些东西
如果你想提供反馈 很期待你前往互动体验区找到我们

Spanish: 
Unir esto nos ahorraría
complejidad, y significaría
que, por ejemplo, FragmentFactory
y todo el ahorro
que deben hacer de todos modos
para cambios de configuración,
proceso, cierre y retorno.
Todo eso pasa a ser ahora
la opción predeterminada.
Ahora solo tenemos
que probar una ruta de código,
como el estado en el que estoy,
y si mis observadores cometen un error aquí
porque están cambiando entre ciclos de vida.
Me doy cuenta de que este
es un cambio más grande.
Así que estamos intentando
que esta API tenga opción de participación
en el nivel de actividad del fragmento.
Entonces, toda la actividad de fragmentos
se trasladaría a este nuevo mundo
en el que tendríamos
ciclos de vida más simplificados.
Así que estamos emocionados
por lanzar todas estas funciones,
y les agradeceríamos mucho
que vayan a la zona de pruebas
para hablar con nosotros.

Indonesian: 
begitu banyak kerumitan
dan artinya
FragmentFactory
dan semua status
penyimpanan yang harus dilakukan
untuk kasus seperti
saat sedang melakukan perubahan
konfigurasi, proses, mati,
dan kembali,
kini menjadi opsi default.
Dan kita hanya perlu menguji
satu jalur kode
untuk status saat ini.
Apa ada kesalahan
pada observer
karena siklus hidup tertukar?
Kami menyadari bahwa ini
ini perubahan yang besar.
Jadi, kami sedang mempertimbangkan membuat
keikutsertaan API ini
pada tingkat aktivitas Fragment.
Apa pun yang ada di
aktivitas Fragment tersebut
akan dipindahkan ke kondisi baru
dengan siklus hidup yang lebih sederhana.
Kami tak sabar untuk merilis
semua hal ini.
Dan kami sangat menghargai jika
Anda memberikan masukan di Sandbox.

Portuguese: 
Juntar essas coisas
reduz muito a complexidade.
Coisas como "FragmentFactory"
e as gravações de estado,
necessárias ao mudar a configuração,
escrever o processo, destruir e restaurar,
agora são opções padrão.
E só precisamos testar
um caminho de código para ver o estado
ou se os observadores fazem algo errado
por causa da troca de ciclos de vida.
Eu sei que esta é uma grande mudança.
Então, a adoção dessa API será voluntária
no nível da atividade do fragmento.
Então tudo na atividade do fragmento
será transferido para o "novo ambiente",
em que os ciclos de vida
serão simplificados.
Estamos ansiosos
para lançar todos esses recursos.
E ficaremos gratos se vocês
vierem dar seu feedback no sandbox.

Spanish: 
También mediante issuetracker.google.com
si tienen comentarios
o pedidos de otras funciones
que les gustaría ver en los fragmentos.
Gracias.

Korean: 
또한 IssueTracker.Google.com을 방문하여
프래그먼트에 대한 의견이나
기타 기능 요청을
보내실 수도 있습니다
감사합니다
[박수]
[음악 재생]

Portuguese: 
Vocês também podem acessar
IssueTracker.Google.com
para dar feedback
ou pedir outros recursos nos fragmentos.
Obrigado.

Chinese: 
此外 别忘了使用 issuetracker.google.com
提交任何反馈信息或其他针对 Fragment 的功能请求
谢谢

Japanese: 
フィードバックや
Fragmentに取り入れてもらいたい
今後のリクエストがありましたら
IssueTracker.Google.comも
ご利用いただけます
ありがとうございました

Indonesian: 
Selain itu, gunakan
IssueTracket.Google.com
jika ada masukan atau
permintaan fitur lain
yang Anda inginkan ada di Fragment.
Terima kasih.

English: 
Also using the
IssueTracker.Google.com
if you have any feedback
or other feature requests
that you'd love to
see in Fragments.
Thank you.
[APPLAUSE]
[MUSIC PLAYING]
