
Portuguese: 
Olá a todos.
Bem-vindos ao WorkManager: além do básico.
- Meu nome é Sumir Kataria.
- Olá. Eu sou o Rahul Ravikumar.
Falaremos um pouco sobre o WorkManager,
a biblioteca adiável
de processamento em segundo plano
baseada em restrições e padrão do Jetpack.
Falaremos de assuntos
intermediários e avançados,
então esperamos que vocês conheçam
um pouco do WorkManager.
Falemos um pouco dos principais
lançamentos do WorkManager
desde o ano passado,
que foi quando lançamos
o WorkManager 1.0 e 2.0.
A versão 1.0 é a biblioteca de suporte
do mundo antigo.
A 2.0, em desenvolvimento,
é a versão do AndroidX.
A 2.1 apresenta inicialização sob demanda.
Falaremos sobre inicialização mais tarde,
porque é um assunto importante.
A versão estável, 2.2,
tem suporte para GcmNetworkManager

English: 
[MUSIC PLAYING]
SUMIR KATARIA: Hi, everyone.
Welcome to WorkManager:
Beyond the Basics.
My name is Sumir Kataria.
RAHUL RAVIKUMAR: Hi.
I'm Rahul Ravikumar.
SUMIR KATARIA: And we're going
to be talking a little bit
about WorkManager,
which is Jetpack's
deferrable constraint-based
background processing library.
And we'll be covering a lot
of intermediate and advanced
topics, so we're kind
of counting on you
to know a little bit
about WorkManager.
So let's talk a little
bit about Lights,
or the release
highlights of WorkManager
over the last year or so.
So we released WorkManager
last year, 1.0 and 2.0.
So 1.0 is a support library
version, the old world.
2.0, which is what we're
currently developing,
is the AndroidX version.
2.1 brought you
on-demand initialization.
We'll be talking a little
bit about initialization
later today, because
that's an important topic.
2.2, which is our
latest stable version,
is introducing support
for GcmNetworkManager,

Chinese: 
大家好 欢迎来到 WorkManager 进阶课堂
我是 Sumir Kataria
大家好 我是 Rahul Ravikumar
我们要讨论的是 WorkManager
它是 Jetpack 的一个可延迟的 基于条件约束的
后台进程处理库
我们会详细聊一些进阶的话题
所以希望大家已经对 WorkManager 有了一定的了解
下面我们来简单谈谈 其闪光点 
或者说 WorkManager 在过去一年中的发布亮点
我们去年发布了 WorkManager 1.0 和 2.0
1.0 是一个支持库版本 适合当时的情况
而我们正在开发的 2.0 则是 AndroidX 版本
2.1 版本为大家带来了按需初始化
之后我们还会继续谈论初始化
因为这个话题相当重要
2.2 版本是我们最新的稳定版本
它加入了对 GcmNetworkManager 的支持

Spanish: 
Hola a todos.
Bienvenidos a WorkManager:
Más allá de lo básico.
Mi nombre es Sumir Kataria.
Hola. Yo soy Rahul Ravikumar.
Vamos a hablar un poco
sobre WorkManager,
que es la biblioteca de procesamiento
en segundo plano basada
en restricciones diferibles de Jetpack.
También cubriremos
muchos temas intermedios
y avanzados,
así que contamos con que ustedes
sepan un poco
sobre WorkManager.
Hablemos de los lanzamientos
más importantes de WorkManager
el año pasado más o menos.
Lanzamos WorkManager
el año pasado, 1.0 and 2.0.
La versión 1.0 es una biblioteca
de compatibilidad, el viejo mundo.
La 2.0, que es la que estamos
desarrollando actualmente
es la versión AndroidX.
La 2.1 trajo inicialización a pedido.
Hablaremos sobre la inicialización
un poco más tarde,
porque es un tema importante.
La 2.2, que es nuestra última versión
más estable,
presenta compatibilidad
para GcmNetworkManager,

Japanese: 
皆さん こんにちは
“WorkManager: 中級編”へ
ようこそ
スミア･カタリアと申します
こんにちは
ラーフル･ラヴィクマールです
私たちはWorkManagerについて
お話ししたいと思います
これはJetpackの延期可能な制約ベースの
バックグラウンド処理ライブラリです
中級および上級のトピックを
扱いたいと思います
皆さんがWorkManagerについて
ある程度ご存知であると想定して
話を進めさせていただきます
まず過去１年ほどの間にリリースされた
WorkManagerのハイライトについて
お話ししたいと思います
昨年リリースされた
WorkManagerは1.0と2.0です
1.0はサポートライブラリバージョンで
旧式になります
2.0は現在開発を進めている
AndroidXバージョンになります
2.1ではオンデマンドの
初期化が可能になりました
初期化については
後ほど詳しくお話しします
これは重要なトピックです
2.2は最新の安定版で
GcmNetworkManagerと
オプションのAPIレベル22以下が

Korean: 
[음악 재생 중]
여러분, 안녕하세요
'WorkManager: 기초 너머로'에 오신 것을 환영합니다
저는 수미르 카타리아입니다
안녕하세요
저는 라훌 라비쿠마입니다
오늘은 Jetpack의
제약 조건 기반 지연 가능
백그라운드 처리 라이브러리인
WorkManager 이야기를 해볼 것입니다
그리고 다른 중급, 고급 주제도 다룰 것입니다
그래서 여러분이 WorkManager를
어느 정도 알고 있으리라
생각하고 진행하겠습니다
그러면 작년 한 해 WorkManager의
릴리즈 하이라이트, Lights를
살펴보겠습니다
작년에는 WorkManager
1.0과 2.0을 내놓았습니다
1.0은 예전 시스템을 지원하는 라이브러리 버전입니다
지금 개발하고 있는 2.0은
안드로이드X 버전입니다
2.1은 주문형 초기화 프로그램을 제공했습니다
초기화는 중요한 주제이므로
나중에 더 다루겠습니다
2.2는 최신 안정판으로
GcmNetworkManager와

Indonesian: 
-Hai, semua.
Selamat datang di
WorkManager: Beyond the Basics.
-Saya Sumir Kataria.
-Hai, saya Rahul Ravikumar.
-Kami akan
sedikit membahas WorkManager,
yang merupakan library pemrosesan 
latar belakang berbasis batasan Jetpack
yang dapat ditangguhkan.
Dan kami akan mengulas berbagai
topik menengah dan lanjutan,
jadi kami harap
Anda paham tentang WorkManager.
Mari kita bahas dulu Light,
atau sorotan rilis WorkManager
selama satu tahun terakhir
atau setelahnya.
Kami merilis WorkManager
versi 1.0 dan 2.0 tahun lalu.
Versi 1.0 adalah versi library
dukungan, dengan tampilan lama.
Versi 2.0 yang sedang kami
kembangkan saat ini
adalah versi AndroidX.
Versi 2.1 menyediakan
inisialisasi on demand.
Kita akan singgung
sedikit tentang inisialisasi hari ini,
karena topik ini sangat penting.
Versi 2.2,
yaitu versi stabil terbaru,
memperkenalkan dukungan
untuk GcmNetworkManager,

English: 
and its optional
API 22 and below.
So that adds a
lot of reliability
to your WorkManager.
And then 2.3, which is what
we're currently developing--
and we hope will be
stable later in the year--
brings you progress
and setForeground APIs.
So that should very important.
We won't really be
talking about that today.
So let's dive into some topics.
And we're going to be covering
a broad swath of things.
But they'll all be
sort of focusing
on things that make you
understand how WorkManager
works under the hood.
And this is the first topic,
which is how does WorkManager
interact with the OS?
So you all probably have
a simple worker like this.
This is very simplified.
It just-- it's a worker
that uploads images.
So this is the
basic unit of work.
And you'll probably create
a work request using this.
You might add some constraints.
In this case, since
it's uploading,
it'll probably be network
constraints of some sort.
You'll build it, and
you'll enqueue it.
So this is the basic
WorkManager workflow.
And what happens at this point?
This is very important
to understand,

Portuguese: 
e é opcional para API 22 e anteriores.
Isso dá mais confiabilidade
ao WorkManager.
A versão 2.3 está em desenvolvimento.
Esperamos estabilizá-la este ano.
Ela contém APIs de progresso
e setForeground.
Isso será muito importante,
mas não abordaremos hoje.
Vamos entrar no assunto.
Temos muita coisa a dizer.
A ideia geral é explicar
o que faz o WorkManager funcionar.
Este é o primeiro assunto:
como o WorkManager interage com o SO?
Vocês devem ter um worker como este.
Está bem simplificado,
é apenas um worker que carrega imagens.
Essa é a unidade básica de trabalho.
Você deve criar
uma solicitação de trabalho assim.
Pode adicionar restrições.
Neste caso, já que está carregando,
provavelmente haverá algum tipo
de restrição de rede.
Você cria e coloca na fila.
Esse é o fluxo de trabalho básico
do WorkManager.
O que acontece agora?
É muito importante entender isso,

Spanish: 
y el API 22 opcional e inferiores.
Eso agrega mucha confiabilidad
a WorkManager.
La 2.3, es la que estamos
desarrollando ahora,
y esperamos que esté estable
dentro de este año,
trae API de Progress y setForeground.
Eso debería ser muy importante.
En realidad no hablaremos de eso hoy.
Así que hablemos de algunos temas.
Vamos a cubrir un amplio espectro
de cosas.
Pero todas se van a enfocar
en cosas que ayudan
a entender cómo funciona
WorkManager en niveles más profundos.
Este es el primer tema:
¿cómo interactúa WorkManager con el SO?
Quizás todos tengan
un pequeño trabajador como este.
Está muy simplificado.
Es un trabajador que sube imágenes.
Esta es la unidad básica de trabajo.
Quizás crearán
una solicitud de trabajo con él.
Pueden agregar algunas restricciones.
En este caso,
como tiene que ver con subir,
quizás sean restricciones de red.
La construirán y la pondrán en cola.
Este es el flujo de trabajo
básico de WorkManager.
¿Qué pasa en este punto?
Es muy importante entenderlo

Korean: 
선택사항인 API 22 이하 버전 지원을 도입했습니다
이걸로 여러분의 WorkManager에
상당한 안정성을 가져왔습니다
그리고 2.3은 현재 개발하고 있으며
올해 안으로는 더 안정성을 갖추고
여러분에게 발전된 모습과 
setForeground API를 드리는 게 목표입니다
그런 면에서 더 중요하죠
이 내용은 오늘 다루진 않을 겁니다
그럼 본격적으로 시작해보죠
꽤 다양한 내용을 다룰 예정인데
그 내용은 모두
여러분이 WorkManager의 작동 원리를
이해하는 데 초점을 맞출 것입니다
첫 번째 주제는 이것입니다
WorkManager는 어떻게 OS와
상호작용할까?
여러분이라면 이런 단순한 워커는
가지고 있으실 겁니다
아주 간단하죠
이건 이미지를 업로드하는 워커입니다
작업의 기초 단위이죠
그리고 이걸 사용해서 작업 요청을 생성할 겁니다
여기에 제약 조건을
추가할 수도 있습니다
이 예시에서는 
계속 업로드를 하고 있었으니
네트워크 제약 조건 같은 게 있을 겁니다
이걸 빌드하고 큐에 넣게 되겠죠
이게 WorkManager의 기초 워크플로입니다
그러면 이 시점에서 무슨 일이 생길까요?
이는 나머지 코드에

Chinese: 
并且兼容 API 22 及以下版本
这就极大地提升了 WorkManager 的可靠性
而 2.3 版本 也是我们正在开发的版本
我们希望这个版本今年能够进入稳定状态
它更进一步 为大家带来了 setForeground API
这是非常重要的
不过我们今天不会讲太多关于它的内容
下面我们来展开看一些话题
今天我们要谈论的东西很多
但是这些东西都有一个共性：
它们都有助于大家理解 WorkManager 的运行原理
第一个话题是 WorkManager 是如何与 OS 配合的？
大家可能都有这样一个简单的 Worker
它只负责上传图片
是基本工作单元
然后你可能会使用它来创建一个 WorkRequest
也许还会添加一些约束条件
在这个例子中 因为它负责上传
这个约束条件可能就是网络连接状态之类的东西
你构建了它 把它加入队列
这就是基本的 WorkManager 工作流程
这个时候会发生什么呢？
你必须了解这一点

Japanese: 
サポートされるようになりました
これがWorkManagerに
大きな信頼性をもたらしました
2.3は現在開発中で
今年の後半には安定版を
リリースしたいと願っています
機能が向上し
setForeground API も導入されるため
非常に重要なバージョンになります
ただし 今日はこれについてはお話ししません
いくつかのトピックを
掘り下げていきましょう
幅広いトピックを扱います
しかしそれらはすべて
WorkManagerが内部で
どのように機能しているかを
理解するのに役立ちます
最初のトピックは
WorkManagerが
OSとやり取りする方法です
皆さんもこのようなシンプルな
ワーカーをお使いかもしれません
非常にシンプルです
このワーカーは単に画像を
アップロードするもので
基本的な作業単位です
これを使用して
作業リクエストを作成します
制約の追加もできます
この場合アップロードなので
ネットワークの制約か何かに
なるかもしれません
これをビルドして
キューに入れます
これは基本的な
WorkManagerのワークフローです
この時点で何が起きるでしょうか
これは非常に重要な点です

Indonesian: 
serta opsi API 22
dan yang lebih rendah.
Jadi, itu meningkatkan keandalan
untuk WorkManager Anda.
Selanjutnya versi 2.3,
yang sedang dikembangkan,
dan harapannya jadi
stabil tahun depan,
memberikan progres dan setForeground API.
Harusnya sangat penting,
tapi kami tidak akan bahas itu hari ini.
Terkait topik bahasan,
kami akan membahas banyak hal.
Tetapi, semua akan fokus
pada hal-hal yang membantu Anda
memahami cara WorkManager
beroperasi di balik layar.
Mari mulai dengan topik pertama,
bagaimana WorkManager 
berinteraksi dengan OS?
Jadi, Anda mungkin memiliki
worker yang sederhana seperti ini.
Ini sangat sederhana.
Worker hanya
mengupload gambar.
Jadi, inilah unit dasar pekerjaan.
Dan Anda mungkin akan membuat
permintaan pekerjaan menggunakannya.
Anda bisa tambahkan beberapa batasan.
Pada kasus ini, 
karena sedang mengupload,
batasannya bisa berupa
batasan jaringan atau semacamnya.
Anda membuatnya,
lalu mengantrekannya.
Itulah alur kerja dasar WorkManager.
Lalu, apa yang terjadi sekarang?
Hal ini sangat penting
untuk dipahami,

Korean: 
영향을 주게 되므로
꼭 이해해야 합니다
그렇다면 첫째, 요청은 어떻게 지속할까요?
먼저 이것을
WorkManager 데이터베이스에 저장합니다
이게 모든 것의 정보 출처가 됩니다
우리가 이야기할 내용은 사실
정보 출처 제어가 전부입니다
그래서 여러분의 작업이 실행되고 있는지
완료됐는지, 실패했는지, 5번이나 재시도했는지 등을
알려면, 그 모든 정보가 여기 저장되어 있습니다
이후에 여러분이 API 23이나 그 이상 버전처럼
새로운 API를 사용한다면
우리는 이를 JobScheduler에 저장합니다
죄송합니다
우리는 이 요청을 JobScheduler로 보냅니다
API 22와 그 이하 버전에서는
여러분의 기기에 Google Play 서비스가 있고
workgcmdependency를 사용하는지
확인할 겁니다
우리는 이걸 GcmNetworkManager로 보내겠죠
그렇지 않으면 맞춤형 Alarm Manager와 
브로드캐스트 리시버 구현도 있습니다
이 모든 과정이 끝나면
여러분의 작업 요청을 어떻게 실행할까요?
방금 JobScheduler와 GcmNetworkManager
Alarm Manager를 이야기했는데요
여러분 앱 외부 요소는 이 세 가지가 다입니다

Japanese: 
残りのコードに影響を及ぼすからです
ではリクエストを
どのように維持するでしょうか
まずWorkManagerデータベースに
保存します
これはすべての情報源となります
実際にここでは
この情報源をどのように制御するか
についてお話しします
処理が実行されているか 
完了したか
失敗したか ５回再試行したか
知りたいことが何であれ
すべてここに保存されています
その後 新しいAPI つまり
API 23以上を使用するようになっても
JobSchedulerにそれを保存します
失礼
このリクエストを
JobSchedulerに送信します
API 22以下では
デバイス上に
Google Playサービスが
あるかどうかを確認し
work-gcm依存関係を使用して
GcmNetworkManagerに送信します
またはカスタムAlarmManagerや
ブロードキャストレシーバーを使用します
これらが行われた後
作業リクエストはどのように
処理されるでしょうか
ここまでで
JobScheduler
GcmNetworkManager
AlarmManagerについて話しました
これらはすべて
アプリの外部で処理されます

English: 
because it will
have repercussions
throughout the
rest of your code.
So first is, how do
we persist a request?
And the first thing
we do is we store it
in the Work Manager database.
This is our source of
truth for everything.
Nothing else that we talk
about is actually controlling
the source of truth.
So if you want to know
if your work is running,
has finished, has failed, has
retried five times-- whatever
it is, all of this
is stored here.
After that, if you're
on a newer API--
API 23 and up-- we'll
store it in JobScheduler.
Sorry.
We'll send this request
to JobScheduler.
For API 22 and below, we'll
check if you have Google Play
services on your device and
you're using the [? work-gcm ?]
dependency.
We'll send it to
GcmNetworkManager.
Otherwise, we have a custom
Alarm Manager and broadcast
receiver implementation.
So after all of
this is done, how,
does your work request run?
And we talked
about JobScheduler,
GcmNetworkManager,
and Alarm Manager.
So these are all things that
are outside of your app.

Portuguese: 
porque terá repercussões
em todo o resto do seu código.
Então, como persistimos
em uma solicitação?
Primeiro, nós a armazenamos
no banco de dados do WorkManager.
Ele é nossa fonte da verdade.
Nada do que falaremos
pode controlar a fonte da verdade.
Se quiser saber se seu trabalho
está em execução, se concluiu, se falhou,
se reiniciou cinco vezes, enfim,
tudo isso será armazenado aqui.
Depois disso, se você usa uma API
mais recente, acima da 23,
armazenaremos no JobScheduler.
Perdão, enviaremos uma solicitação
ao JobScheduler.
Para as APIs 22 e abaixo, veremos se
o dispositivo tem o Google Play Services
e se usa a dependência work-gcm.
Enviaremos ao GcmNetworkManager,
caso contrário,
temos o AlarmManager personalizado
e a implementação do broadcast receiver.
Depois que tudo isso estiver pronto,
como é executada
a sua solicitação de trabalho?
Falamos sobre JobScheduler,
GcmNetworkManager e Alarm Manager.
Essas coisas existem fora do seu app,

Indonesian: 
karena akan berdampak
pada sisa kode Anda.
Pertama, bagaimana
mempertahankan permintaan?
Hal pertama yang kita lakukan 
adalah menyimpannya
di database Work Manager.
Ini adalah sumber kebenaran
untuk segalanya.
Tidak ada hal lain dalam bahasan kita
yang mengendalikan sumber kebenaran.
Jadi, jika Anda ingin tahu
apakah pekerjaan Anda sedang berjalan,
selesai, gagal, 
atau telah dicoba lima kali,
apa pun itu, 
semua infonya disimpan di sini.
Kemudian, 
jika menggunakan API lebih baru,
API 23 dan lebih tinggi, kami akan
menyimpannya di JobScheduler.
Maaf.
Kami akan kirim
permintaan ke JobScheduler.
Untuk API 22 dan di bawahnya,
kami akan memeriksa
apakah perangkat 
memiliki layanan Google Play
dan menggunakan dependensi [? work-gcm ?].
Kami akan mengirimnya ke
GcmNetworkManager.
Jika tidak, 
kami memiliki Alarm Manager kustom
dan implementasi penerima siaran.
Setelah semuanya selesai,
bagaimana permintaan
pekerjaan Anda berjalan?
Kita tadi sudah bahas JobScheduler,
GcmNetworkManager,
dan Alarm Manager.
Semua hal ini
berada di luar aplikasi Anda.

Spanish: 
porque tendrá repercusiones
en todo el resto de tu código.
Primero, ¿cómo mantenemos la solicitud?
Lo primero que hacemos es guardarla
en la base de datos de WorkManager.
Esta es nuestra fuente de la verdad
para todo.
Nada de lo que hablemos
en realidad controla
la fuente de la verdad.
Así que si quieren saber
si su trabajo funciona,
ha terminado, ha fracasado,
se ha reintentado cinco veces,
lo que sea,
todo está guardado aquí.
Después de eso,
si usan un nuevo API,
API 23 y superiores,
lo guardaremos en JobScheduler.
Perdón.
Enviaremos esta solicitud
a JobScheduler.
Para API 22 e inferiores,
revisamos si tienen servicios
de Google Play en su dispositivo
y si usan la dependencia work-gcm
para enviarla a GcmNetworkManager.
De otro modo, tenemos
un AlarmManager personalizado
e implementación de receptores
de emisiones.
Así que mientras se hace todo esto,
¿cómo funciona la solicitud de trabajo?
Hablamos sobre JobScheduler,
GcmNetworkManager,
y Alarm Manager.
Estas cosas están todas
afuera de tu aplicación.

Chinese: 
因为它会在你的代码内部各处产生相应的影响
第一个问题 我们如何持久化请求呢？
首先 我们把它保存在 WorkManager 数据库里
这个是我们之后操作的基础
其他的任何东西都做不到
如果你想知道自己的工作程序是否在运行 
是否完成 是否失败 是否重试了5次 等等
一切信息都储存在这里
之后 如果你使用的是 API 23 或以上
我们就会把信息储存在 JobScheduler 里
说错了 我们会把这个请求发送到 JobScheduler
对于 API 22 及以下 我们会查看你的设备上
是否有 Google Play 服务 是否有 Work-Gcm 依赖
我们会把请求发送给 GcmNetworkManager
没有的话 我们还可以通过 AlarmManager 
以及相应的广播接收器来实现
在这些之后
你的 WorkRequest 将如何运行呢？
我们刚说到 JobScheduler GcmNetworkManager 和 AlarmManager
这些都是在你的应用之外的

Portuguese: 
seja no SO ou no Play Services.
Outra coisa agora sabe do seu trabalho
e pode ativar seu app, se necessário,
e solicitar que o WorkManager
execute seu trabalho.
Por exemplo, com uma restrição de rede
em um dispositivo mais novo,
o JobScheduler ativará seu app
para dizer que há uma rede
e que ele pode executar o trabalho.
Então, o WorkManager o executa.
Também temos o chamado GreedyScheduler.
O GreedyScheduler só existe
dentro dos processos do seu app.
Ele faz a mesma coisa:
acompanha algumas restrições.
Quando é oportuno, ele solicita
ao WorkManager que execute o trabalho.
Mas, como está no processo,
não ativará seu app.
É apenas uma maneira otimizada
de executar seu trabalho rapidamente,
além de ser muito útil,
já que independe do resto do SO.
É uma maneira otimizada e rápida
de executar seu trabalho.
Vamos abrir um breve parênteses
que vai se encaixar perfeitamente
neste conceito aqui.

Spanish: 
Entonces es el SO
o Play Services.
Algo más ahora sabe sobre tu trabajo.
Y eso puede activar
tu aplicación si necesario,
y pedirle a WorkManager
que ejecute tu trabajo.
Así que, por ejemplo, si tienes alguna
restricción de conectividad de red
en un dispositivo más nuevo,
JobScheduler activará tu aplicación,
y le dirá: oyes, tienes una red.
Puedes hacer este trabajo.
Y luego WorkManager
lo ejecutará.
También tenemos algo
llamado GreedyScheduler.
GreedyScheduler solo existe
dentro del proceso de la aplicación.
Y hace lo mismo.
Mantendrá un registro
de algunas de las restricciones.
Y aprovechará para pedir
a WorkManager que ejecute el trabajo.
Pero, como está en el proceso,
no activará la aplicación.
Es una manera optimizada
de buscar cómo ejecutar tu trabajo.
Es muy útil porque no depende
del resto del SO.
Ejecutará tu trabajo
de forma rápida y oportunista.
Tomemos un breve desvío.
Esto se unirá a este concepto de acá.

Japanese: 
OSかPlayサービスのいずれかです
別の何かが処理を認識しています
必要に応じて
それらがアプリを起動します
WorkManagerにその処理を
実行するように依頼します
たとえば ネットワークデバイスに
ネットワーク接続の制約がある場合
JobSchedulerはアプリを起動し
それに＂ネットワークがあるから
この処理を実行できるぞ＂と伝え
WorkManagerが
その処理を実行します
GreedyScheduler
というものもあります
GreedySchedulerは
アプリプロセス内にのみ存在します
そして同様の処理を実行します
一部の制約を管理します
また状況を見てWorkManagerに
処理を実行するよう依頼します
ただしこれはプロセス内に存在するため
アプリを起動することはありません
処理をひたすら実行するための
最適化された方法にすぎません
OSの残りに依存しないため
これは非常に有用です
これは状況を見て
素早く処理を実行します
少し脇道にそれます
今考慮したこれらのコンセプトと
関係があるのですが

English: 
So it's either the OS
or it's Play Services.
Something else now
knows about your work.
And that thing can wake
up your app, if needed,
and ask WorkManager
to run your work.
So for example, if you have a
network connectivity constraint
on a newer device, JobScheduler
will wake up your app,
and tell it, hey,
you have a network.
You can do this work.
And then WorkManager
will run it.
We also have this thing
called a GreedyScheduler.
GreedyScheduler only exists
within your app process.
And it does the same stuff.
It'll keep track of
some of the constraints.
And it will
opportunistically ask
WorkManager to run the work.
But since it's in
your process, it's
not going to wake up your app.
It's just an optimized way
to eagerly run your work.
And this is very useful
because it doesn't
depend on the rest of the OS.
So it's just opportunistically
and quickly running your work.
So let's take a brief detour.
And this will tie right back
into this concept right here.

Korean: 
즉, OS가 아니면 Play 서비스만 남은 셈이죠
다른 무언가가 여러분의 작업을 알고
필요하다면 여러분의 앱을 깨운 다음
WorkManager에게 작업 실행을 요청합니다
예를 들어보죠. 여러분의 새로운 기기에서 
네트워크 연결 제약이 있다면
JobScheduler는 앱을 깨운 후
네트워크가 있으니
작업을 할 수 있다고 말할 겁니다
그러면 WorkManager는 이를 실행하겠죠
GreedyScheduler라는 것도 있습니다
GreedyScheduler는 앱 프로세스 안에만 존재합니다
하는 역할은 같습니다
제약 조건을 일부 추적하고
기회가 생기면 WorkManager에게 작업을
실행하라고 요청할 겁니다
하지만 GreedyScheduler가 프로세스 안에 있어서
앱을 깨우지는 않을 것입니다
작업을 적극적으로 실행하도록
최적화된 방식일 뿐이죠
GreedyScheduler는 OS의 나머지 부분에
의존하지 않아서 대단히 유용합니다
기회를 보고 재빨리 작업을 실행하는 게 전부입니다
이제 잠시 돌아가 보겠습니다
여기 이 개념으로 바로 연결되는데요

Indonesian: 
Mungkin berupa OS atau Play Services-nya.
Sekarang, ada aplikasi lain
yang tahu pekerjaan Anda.
Dan aplikasi itu bisa membuka
aplikasi Anda, jika diperlukan,
dan meminta WorkManager
untuk menjalankan pekerjaan Anda.
Misalnya, jika Anda memiliki
batasan konektivitas jaringan
di perangkat yang lebih baru,
JobScheduler akan membuka aplikasi Anda,
dan memberi tahu
bahwa Anda punya jaringan.
Pekerjaan bisa dilakukan.
Lalu, WorkManager akan menjalankannya.
Kami juga GreedyScheduler.
GreedyScheduler hanya aktif
selama pemrosesan aplikasi.
Pekerjaannya juga sama.
Scheduler ini akan
melacak beberapa batasan,
lalu meminta WorkManager
secara oportunistik
untuk menjalankan pekerjaan.
Tetapi, karena ada di proses Anda,
ini tidak akan membuka aplikasi Anda.
Inilah cara yang dioptimalkan
untuk menjalankan pekerjaan dengan aktif.
Ini sangat bermanfaat karena
tidak bergantung pada bagian lain OS.
Jadi, cara ini menjalankan pekerjaan Anda
secara oportunistik dan cepat.
Mari kita sedikit menyimpang.
Dan ini akan membawa kita
kembali ke konsep ini.

Chinese: 
不是 OS 就是 Play Service
总之另外的一些东西现在知道你的工作需求了
而这个东西可以在需要的时候唤醒你的应用 
并请求 WorkManager 运行你的工作
例如 如果你在一台较新的设备上有一个网络连接约束
JobScheduler 就会唤醒你的应用
并告诉它 嘿 你有网络了 你可以做这个工作了
然后 WorkManager 就会运行它
我们还提供了一个名叫 GreedyScheduler 的东西
GreedyScheduler 仅存在于你的应用进程中
它的作用是相同的
它会追踪部分约束条件
并且适时地要求 WorkManager 来运行工作
但是因为它存在于应用进程里 所以它无法唤醒你的应用
它只是一种比较优化的方法 用来主动运行你的工作
这是很有用的 因为它不依赖于 OS 的其余部分
它会适时并更快速地运行你的工作
下面我们来简要地岔开一下话题
来讲讲这个概念

Spanish: 
Alguien vino a verme,
un equipo interno en Google
y me pidieron
que querían ejecutar WorkManager
de manera experimental.
"Lo introduciremos en una aplicación,
y nos gustaría asegurarnos
de que podemos experimentar
y hacer pruebas A/B con él".
La primera idea que tuvieron fue
si dejaban de llamar a WorkManager
para un población experimental,
¿puedo hacer esta prueba A/B?
¿Qué pasa acá?
Volvamos a esa primera parte
del diagrama de flujo.
El viejo trabajo
todavía se ejecutará,
porque se puso en cola
este trabajo en el pasado.
Luego piensan, "bien,
voy a dejar de usar
WorkManager para este usuario".
El SO todavía recuerda
todo este trabajo,
y todavía inicia
el proceso de la aplicación.
Le pedirá a WorkManager
que ejecute el trabajo.
Entonces no es lo que querían.
La segunda idea fue,
"¿y si no inicializamos WorkManager
para esa población experimental?"
Bien.
Así que el viejo trabajo
todavía se ejecutará
si usan inicialización a pedido,
porque eso inicializará
WorkManager a pedido.
Hablaremos sobre inicialización
un poco más,
pero eso es una cosa.

Chinese: 
Google 内部团队有人曾经找到我 问我
嘿 我们想试着运行一下 WorkManager
我们准备在我们的应用里推出它
我们想对它做实验 做 A/B 对照
他们的第一个想法是
如果我们在某个实验组中停止调用 WorkManager 会怎样？
这样不就是 A/B 测试了吗？
看看会发生什么
下面我们回到流程图的第一部分
你之前的工作仍然会运行
因为你之前已经把这个工作加入了队列
然后你又决定不在这个用户身上使用 WorkManager
但 OS 还记得这个工作的所有信息
它会启动应用进程
请求 WorkManager 来运行这个工作
这不是他们想要的结果
他们的第二个想法是
如果我们在某个实验组中不初始化 WorkManager 会怎样？
好 如果你使用了按需初始化
你之前的工作仍然会运行
因为它会在需要时来初始化 WorkManager
之后我们会详细谈谈初始化方面的问题 那是另一个话题了

Portuguese: 
Uma equipe interna da Google
me disse que gostaria de executar
um experimento no WorkManager.
Disseram que o incorporaram em um app
e que gostariam de fazer experimentos A/B.
Eles pensaram em parar
de chamar o WorkManager
para uma população experimental,
para fazer um teste A/B.
O que aconteceria?
Voltamos à primeira parte do fluxograma.
Seu trabalho antigo ainda será executado,
já que você o adicionou à fila.
Então, você para de usar o WorkManager
para este usuário.
O SO ainda se lembra de todo o trabalho
e iniciará o processo do app,
que solicitará ao WorkManager
que execute o trabalho.
Mas não era isso que eles queriam.
A segunda ideia foi:
e se eu não inicializar o WorkManager
para essa população experimental?
Certo. Seu trabalho antigo
ainda será executado
se você usar inicialização sob demanda,
porque o WorkManager será inicializado.
Esse é um aspecto da inicialização,
da qual falaremos mais a fundo.

Korean: 
Google 내부 팀의 누군가가
제게 와서 물었습니다
시험적으로 WorkManager를
가동해보고 싶다고 했죠
WorkManager를 앱에 도입하고 있는데
WorkManager로 실험과 A/B 테스트도 할 수 있는지
확인하고 싶다고 했습니다
이들의 첫 번째 발상은
A/B 테스트처럼 실험군에
WorkManager 호출을 중단하면
어떻게 되는지였습니다
그러면 무슨 일이 일어나는 걸까요?
플로차트의 앞부분으로 돌아가 보죠
오래된 작업은 계속해서 실행되고 있을 겁니다
예전에 작업을 큐에 넣어놓았기 때문이죠
그렇다면 여기서 이 사용자의 WorkManager를
중단하겠다고 알립니다
이 모든 작업은 OS가 여전히 기억하고 있습니다
그리고 앱 프로세스를 시작하고
OS는 WorkManager에게
작업을 실행해달라고 요청할 겁니다
Google팀이 원한 것은 이게 아니었습니다
두 번째 생각은 실험군에서 WorkManager를
초기화하지 않았을 때는 어떨까 였습니다
좋습니다
여러분이 주문형 초기화를 사용하더라도
이는 요구가 있을 때 WorkManager를 초기화하므로
오래된 작업은 계속 실행될 것입니다
초기화를 주제로 더 이야기하겠지만
이런 초기화도 있고요

Japanese: 
ある人が私のところに来ました
Googleの内部チームのメンバーですが
こう言いました
＂WorkManaerを実験的に実行したい
アプリ内に導入して
実験できるようにしたい
A/B実験をこれで行いたい＂
彼らが最初に考えたのは
＂実験個体群に対して
WorkManagerの呼び出しを
停止したらどうなるか？＂でした
このA/Bテストを行えるでしょうか
どうなるでしょうか
先ほどのフローチャートの
最初の部分に戻りましょう
古い処理は実際に処理され続けます
前にこの処理を
キューに入れているためです
それで
このユーザーに対しては
WorkManagerの使用を停止します
この処理のすべては
OSによって記憶されています
OSはアプリプロセスを開始します
OSはWorkManagerに
その処理を実行するように求めます
これは彼らが
期待したことではありません
次に＂実験個体群のために
WorkManagerを初期化しなかったら
どうなるか？＂と考えました
オンデマンド初期化を使用すると
古い処理は実行され続けます
WorkManagerをオンデマンドで
初期化するからです
初期化についてはあとで
もう少し詳しくお話しますが
もちろん それだけではありません

Indonesian: 
Jadi, ada yang menghampiri saya,
dari tim internal Google,
dan berkata "Hai,
kami ingin menjalankan 
WorkManager secara eksperimental.
Kami telah 
memperkenalkannya di aplikasi,
dan kami ingin memastikan 
bahwa kami bisa mencoba
dan melakukan
percobaan A/B terhadapnya."
Jadi, Ide pertama mereka adalah,
bagaimana jika saya berhenti
memanggil WorkManager
untuk populasi eksperimental,
bisakah saya lakukan percobaan A/B ini?
Apa yang terjadi di sini?
Mari lihat lagi
bagian pertama diagram alir.
Pekerjaan lama akan tetap berjalan,
karena telah diantrekan sebelumnya.
Kemudian Anda atur agar
WorkManager berhenti digunakan
untuk pengguna ini.
OS tetap mengingat semua pekerjaan ini,
dan akan memulai pemrosesan aplikasi.
Dan meminta WorkManager
menjalankan pekerjaan.
Jadi, itu bukanlah keinginan mereka.
Ide kedua adalah,
bagaimana jika
saya tidak menginisialisasi WorkManager
untuk populasi eksperimental itu?
Oke.
Jadi, pekerjaan lama Anda
akan tetap berjalan jika Anda
menggunakan inisialisasi on demand,
karena itu akan menginialisasi
WorkManager sesuai permintaan.
Kami akan bahas
inisialisasi sedikit lebih jauh.

English: 
So somebody came to me--
an internal team at Google
came to me and asked, hey,
we want to run WorkManager
experimentally.
We're introducing it
in our app, and we'd
like to make sure
that we can experiment
and do A/B experiments with it.
So the first idea
they came up with
was, what if I stopped
calling WorkManager
for an experimental
population, so I
can do, like, this A/B test?
What happens here?
So let's go back to that
first part of that flowchart.
Your old work will
actually still run,
because you've enqueued
this work in the past.
Then you say, OK,
I'm stopping using
WorkManager for this user.
Well, all of this work is
still remembered by the OS,
and it'll start the app process.
And it'll ask WorkManager
to run the work.
So that's not what they wanted.
So the second idea
was, what if I
don't initialize WorkManager for
that experimental population?
OK.
So your old work
will still run if you
use on-demand initialization,
because that'll initialize
WorkManager on demand.
And we'll talk about
initialization a little bit
more, but that's one thing.

Portuguese: 
Com a autoinicialização,
apenas será criada uma exceção.
Isso porque ele dirá: "Espere aí.
Você queria executar este trabalho.
Eu tentei inicializar o WorkManager,
mas ele não foi inicializado.
Certo, essa foi uma exceção".
Então, tiveram uma terceira ideia:
e se removermos o WorkManager
para essa população experimental?
Agora, isso parece certo.
Seu trabalho antigo será ignorado,
já que os componentes
que deveriam estar no seu app
não são encontrados pelo JobScheduler,
GcmNetworkManager e Alarm Manager.
Então, ele imprimirá algo no LogCat como:
"Não encontrei isso aqui",
ignorando o trabalho.
Mas o problema sutil aqui
é que ainda se usam recursos do sistema.
Voltemos ao exemplo da restrição de rede.
O JobScheduler está monitorando.
"Tenho rede? Sim, tenho rede.
Vou mandar este app ser executado".
Nosso app, neste caso específico,
não tem mais o WorkManager.
Então você usou vários
recursos do sistema para fazer nada.
Isso não é nada civilizado.

Japanese: 
自動初期化を使用すると
例外をスローします
＂ちょっと待って
この処理を実行したかったんだよね
WorkManagerを
初期化しようとしたけど
初期化されないよ＂
それで例外がスローされます
彼らは３つ目にこう考えました
“実験個体群のためにWorkManagerを
取り除くとどうなるだろうか？”
あまり良い方法には
思えないかもしれません
古い処理は無視されます
アプリ内に配置されるはずの
コンポーネントが
JobScheduler GcmNetworkManager
AlarmManagerによって
検出されないからです
それで＂見つけられないぞ＂
と出力します
その処理は無視されます
しかしここで微妙な問題が生じます
システムリソースが
使用され続けるということです
たとえば 先ほど接続に関する
制約があると言いました
JobSchedulerは追跡し続けます
＂ネットワークはいつ使えるか？
ネットワークが使えるぞ
このアプリに実行するように言わなければ＂
この場合 このアプリには
WorkManagerはありません
何も実行しないのに
多くのシステムリソースを使ってしまいます
それも効率的だとはいえません。
そこで作業リクエストをすべてキャンセルし

Chinese: 
而自动初始化则会抛出一个异常
它会发现 等等 你不是想运行这个工作吗
我试着初始化了 WorkManager 但它没有初始化
好吧 出现异常了
于是 他们又有了第三个想法
如果我们在某个实验组中移除 WorkManager 会怎样？
现在情况看起来很不对劲
你之前的工作都会被忽略
因为 JobScheduler GcmNetworkManager 和 AlarmManager
现在都找不到你的应用中应有的组件了
它们也许会在日志中显示 找不到这个东西 并忽略工作
但这里有个微妙的问题：它仍然在占用系统资源
例如 这里仍然存在着一个网络连接约束
JobScheduler 会持续追踪 持续等待联网
并会在联网成功之后通知应用开始运行
而相应的应用这时已经没有 WorkManager 了
你耗费了系统资源 但什么都没做成
不干活白占资源可不好

Spanish: 
Con la autoinicialización
solo generará una excepción.
Porque entonces dirá
que queríamos
ejecutar este trabajo.
Intenté inicializar WorkManager,
pero no se inicializó.
Bien, eso es una excepción.
Así que volvieron
con una tercera idea.
"¿Y si quitamos WorkManager
para esa población experimental?"
Bueno, ahora las cosas se ven bien.
Tu viejo trabajo
va a ser ignorado,
porque JobScheduler, GcmNetworkManager,
y Alarm Manager
no pueden encontrar
los componentes que se supone
que deben estar en tu aplicación.
Quizá impriman algo en log-cat como
"sí, no pude encontrar esta cosa."
E ignorará el trabajo.
Pero hay un problema acá
que es muy sutil.
Usará los recursos
del sistema.
Así que dije, por ejemplo,
que hay una restricción
de conectividad.
Así que JobScheduler
todavía está rastreando.
¿Cuándo tengo red?
Tengo red.
Mejor voy y le digo a esta aplicación
que se ejecute.
Esta aplicación, en ese caso,
nuestra aplicación
ya no tiene WorkManager.
Así que usamos algunos recursos
del sistema para no hacer nada.
Y eso tampoco es algo bueno.

Korean: 
그리고 자동 초기화는 예외를 발생시킵니다
그렇게 하면 시스템은
작업을 실행하려고 하지 않았냐고 하겠죠
WorkManager를 초기화하려고 했지만
초기화하지 못했으니
예외로 처리할 겁니다
그래서 세 번째 생각은 이랬습니다
실험군에서 WorkManager를 제거하면 
어떻게 되는지 궁금해했죠
지금은 뭔가 제대로 되지 않았습니다
오래된 작업이 무시되겠죠
JobScheduler와 GcmNetworkManager
Alarm Manager가 여러분의 앱에 있어야 할
구성 요소를 찾을 수 없으니까요
그래서 이런 걸 찾지 못했으니
그 작업은 무시할 거라는
로그를 출력할 수도 있습니다
하지만 여기엔 작은 문제가 있습니다
여전히 시스템 리소스를 사용한다는 것이죠
저는 그랬습니다
가령 연결 제약이 있다면
JobScheduler는
계속 추적할 거라고 했죠
'네트워크에 언제 연결되는 거지?'
'아, 연결됐구나'
'앱에 이제 실행하라고 말해야겠어'
그러면 이 앱은, 이 경우 우리 앱은
WorkManager를 갖지 않습니다
아무것도 안 하면서
시스템 리소스만 쏟아부은 셈이죠
별로 좋은 행동이 아닙니다

Indonesian: 
Dengan inisialisasi otomatis,
pengecualian akan diberikan.
Karena selanjutnya, 
terjadi kendala ketika
pekerjaan akan dijalankan,
dan WorkManager tidak terinisialisasi.
Oke, itu adalah pengecualian.
Jadi mereka kembali dengan ide ketiga.
Bagaimana jika WorkManager
untuk populasi eksperimental itu dihapus?
Nah, sepertinya itu tidak bagus.
Jadi, pekerjaan lama Anda akan diabaikan,
karena komponen 
yang harusnya ada di aplikasi Anda
tidak bisa ditemukan oleh JobScheduler,
GcmNetworkManager, dan Alarm Manager.
Jadi, mungkin tercetak 
di [? log-cap ?] dan memberi tahu
bahwa ini tidak bisa ditemukan,
dan pekerjaan ini akan diabaikan.
Tetapi ada masalah di sini, 
yang samar, yaitu resource sistem
masih akan digunakan.
Jadi, misalnya, saya tentukan
ada batasan konektivitas.
JobScheduler masih terus melacak. 
"Kapan saya dapat jaringan?"
"Oh, ada jaringan.
Saya akan menjalankan aplikasi ini."
Dan aplikasi ini, di kasus ini
aplikasi kami,
tidak lagi memiliki WorkManager.
Jadi, Anda telah sia-sia 
menggunakan sekumpulan resource sistem.
Dan itu bukan 
praktik yang baik juga.
Jadi, jawabannya adalah

English: 
And with auto initialization,
it'll just throw an exception.
Because then it
will say, hey, wait.
You wanted to run this work.
I tried initializing
WorkManager,
but it's not initialized.
OK, well, that's an exception.
So they came back
with a third idea.
What if I remove WorkManager for
that experimental population?
Well, now, things
aren't looking right.
So your old work
will get ignored,
because your components that
are supposed to be in your app
are no longer found
by JobScheduler,
GcmNetworkManager,
and Alarm Manager.
So they may print something out
in [? log-cap ?] saying, oh,
yeah, I couldn't
find this thing.
And it'll ignore the work.
But there's a problem
here, and it's subtle--
it'll still use
system resources.
So I said, for
example, that there
is a connectivity constraint.
So JobScheduler
is still tracking.
When do I have network?
Oh, I have network.
I'd better go tell
this app to run.
And this app-- in this
specific case, our app--
doesn't have
WorkManager anymore.
So you've used a bunch of
system resources to do nothing.
And that's not good
citizenship either.

English: 
So the answer here is you should
cancel all your work requests
to clean up after yourself.
That's what I gave to that team.
And the reason I'm
bringing this up
is because you should always
realize that WorkManager
is something that
exists within your app,
but there are repercussions
outside of your app.
The rest of the OS
also knows about it.
And it's important to know that.
So a common question
people come to me and ask
is why is my work not running?
And there's a wide variety
of reasons for this,
and I want to remind
you about a few of them.
One is unsatisfied constraints.
And that's very simple, right?
Like, that's the
most obvious answer.
If your constraints aren't
met, your work won't run.
If you're on a newer
device, you can always
dumpsys JobScheduler.
Because we do store our
jobs in JobScheduler
and it will tell you what
the constraints are that
aren't met.
Another answer might
be you're in doze mode.
Remember that WorkManager is
for deferrable processing,
so your jobs can be delayed in
doze mode to preserve battery.
Similarly, Battery
Saver mode, which is on,
like, Pixel devices
by default when
your battery gets below 15%.

Korean: 
이 문제의 정답은 여러분의 흔적을 모두 지우기 위해
모든 작업 요청을 취소해야 한다는 것입니다
제가 그 팀에 제시한 답이 바로 이것이었습니다
이 내용을 오늘 언급한 이유는
여러분이 WorkManager는 항상 앱 안에 존재하지만
앱 외부에서는 반동이 있을 것이라는 사실을
이해하셔야 하기 때문입니다
OS의 나머지도 이를 알고 있습니다
그래서 꼭 알고 있어야 하죠
사람들이 제게 흔히 하는 질문이 있습니다
왜 작업이 실행되지 않냐는 것이죠
그 원인은 다양하지만
그중 몇 가지를 상기해드리겠습니다
첫 번째는 맞추지 못한 제약 조건입니다
아주 간단하죠?
가장 알기 쉬운 이유죠
제약 조건을 충족하지 않는다면
작업이 실행되지 않을 것입니다
더 새로운 기기를 사용한다면
dumpsys JobScheduler를
쓸 수 있습니다
이는 우리가 작업을 JobScheduler에
저장하기 때문이며
JobScheduler는 충족하지 못한
제약 조건을 알려줄 것입니다
또 다른 원인은 잠자기 모드입니다
WorkManager는 지연 가능 프로세싱을 위한 것입니다
그래서 잠자기 모드에서는 배터리를 절약하기 위해
작업이 지연될 수 있습니다
마찬가지로 Pixel 같은 기기에서는
배터리가 15% 이하로 떨어지면
기본적으로 절전 모드가 켜집니다

Chinese: 
解决方案是 应该取消所有 WorkRequest 
并把自己造成的麻烦清理干净
这也是我为那个团队提供的建议
我之所以提起这件事是因为
你应该随时记住 WorkManager 虽然存在于应用之中
但它带来的影响是超出你的应用范围的
整个 OS 都受其影响
了解这一点是很重要的
人们常问我的一个问题就是
为什么我的工作不能运行？
导致这种现象的原因有很多
这里我只提几种
一 约束条件未满足 
很简单吧 这应该是显而易见的
如果约束条件满足不了 工作就无法运行
如果你使用的是相对较新的设备
那么你随时可以 dumpsys jobscheduler
因为我们会在 JobScheduler 中保存工作
它会告诉你 未满足的约束条件是什么
二 你有可能处于低耗电模式 (doze mode)
还记得吗 WorkManager 是用于处理可延期任务的
所以在低耗电模式下为节省电量 工作会被延迟处理
类似的还有省电模式 
Pixel 等设备在电量低于15%时默认会启用这一模式

Japanese: 
自分で後始末する必要がある
ことが分かります
そのチームにそう教えました
この話に言及したのは
WorkManagerがアプリ内に
存在するものでありながら
アプリの外部に影響を与えるものである
ということを
常に意識していただきたいからです
OSのその他の部分も
これを認識します
このことはぜひ知っておいて
もらいたいのです
私がよく尋ねられるのは
＂なぜ自分の処理が実行されないのか？＂
という質問です
それにはさまざまな理由がありますが
そのうちのいくつかの点を
お伝えしたいと思います
１つは制約事項が
満たされていないことです
非常にシンプルです
最も分かりやすい答えです
制約事項が満たされていなければ
処理は実行されません
最新のデバイスを使用していれば
dumpsysをJobSchedulerに
対して実行できます
JobSchedulerにジョブを
保存しているので
そうすることで
満たされていない制約を確認できます
別の理由はDozeモードで
実行していることかもしれません
WorkManagerでは処理を
延期できることを思い出してください
バッテリを長持ちさせるためのDozeモードで
ジョブが遅延することがあります
バッテリーセーバーも同様です
これはPixelデバイスなどで
バッテリが15%を下回ると
デフォルトでオンになります

Indonesian: 
Anda harus batalkan semua permintaan 
kerja agar Anda bisa menghapusnya sendiri.
Itulah saran saya untuk tim.
Dan alasan saya membahas ini
adalah karena Anda harus selalu sadari
bahwa WorkManager adalah sesuatu 
yang ada di dalam aplikasi Anda,
tetapi berdampak di luar aplikasi Anda.
Bagian lain dari OS
juga tahu tentang hal ini.
Dan Anda perlu tahu hal ini.
Jadi, pertanyaan 
yang umumnya ditanyakan kepada saya
yaitu kenapa pekerjaan saya 
tidak berjalan?
Ada beragam alasan di balik ini,
dan saya ingin mengingatkan
beberapa di antaranya.
Salah satunya adalah 
batasan yang tidak terpenuhi.
Sangat sederhana dan jelas, kan?
Jika batasan tidak sesuai, 
pekerjaan tidak berjalan.
Jika pada perangkat baru, 
Anda bisa lakukan dumpsys JobScheduler,
karena kami
menyimpan tugas di JobScheduler
dan Anda akan diberi tahu 
batasan apa saja yang tidak sesuai.
Jawaban lain yaitu mungkin 
Anda berada di mode istirahat.
Ingat bahwa WorkManager 
merupakan proses yang bisa ditangguhkan,
jadi, tugas Anda bisa ditunda 
di mode istirahat agar hemat baterai.
Begitu juga dengan mode Penghemat Baterai,
yang aktif secara default
misalnya pada perangkat Pixel
saat baterai Anda berada di bawah 15%.

Portuguese: 
A resposta para limpar a bagunça seria
cancelar as solicitações de trabalho.
É o que eu respondi à equipe.
Conto esse exemplo para que vocês entendam
que o WorkManager existe dentro do seu app
mas que há repercussões fora.
O resto do SO também sabe disso,
e é importante que saiba.
Sempre me perguntam
por que tal trabalho não foi executado.
Há muitos motivos para isso.
Quero lembrá-los de alguns.
Um deles é uma restrição não satisfeita.
Parece simples, não? É a resposta óbvia.
O trabalho só se executa
com a satisfação das restrições.
Se tem um dispositivo mais novo,
use dumpsys JobScheduler.
Como armazenamos trabalhos
no JobScheduler,
ele nos avisa quais restrições
não foram satisfeitas.
Outro motivo: você pode estar
no modo soneca.
Lembre que o WorkManager
é para processamentos adiáveis.
Portanto, os trabalhos podem ficar
em modo soneca para economizar bateria.
O mesmo ocorre
no modo economia de bateria,
ativado por padrão em dispositivos Pixel
com menos de 15% de bateria.

Spanish: 
Así que la respuesta es que deberían
cancelar todas las solicitudes
para limpiar cuando se van.
Eso es lo que le di al equipo.
Y la razón por la que cuento esto
es que siempre deben darse cuenta
de que WorkManager
es algo que existe
dentro de su aplicación,
pero hay repercusiones
fuera de la aplicación.
El resto del SO
también sabe sobre eso.
Y es importante saberlo.
Una pregunta común
que la gente viene a hacerme
es por qué su trabajo no se ejecuta.
Y hay una amplia variedad
de razones para ello,
y quiero recordarles
algunas de ellas.
Una es restricciones insatisfechas.
Y esa es muy simple, ¿no?
Esa es la respuesta
más obvia.
Si no se satisfacen,
tu trabajo no se ejecuta.
Si estás en un dispositivo
nuevo, puedes
usar dumpsys JobScheduler.
Porque guardamos nuestros
trabajos en JobScheduler
y te dirá cuáles son las restricciones
que no se satisfacen.
También puede ser
que estás en el modo descanso.
Recuerda que WorkManager
es para procesamiento diferido,
así que nuestros trabajos pueden demorarse
en modo descanso para conservar batería.
De forma similar el modo
Battery Saver, que está en
los dispositivos Pixel
de forma predeterminada
tu batería baja del 15%.

Portuguese: 
Nesse caso, os trabalhos também
não são executados em segundo plano.
Pode ser que seu SO ou app
esteja trabalhando demais.
Portanto, o JobScheduler permite apenas
certo número de trabalhos ativos por vez.
Então, você pode ter excedido isso.
Isso vale para todos os apps.
O WorkManager também é limitado
pelo pool de threads
que você define no começo.
O padrão é entre dois e quatro trabalhos.
Se tentar fazer dez coisas de uma vez,
algumas serão adicionadas à fila.
Também pode haver pré-requisitos
com falha ou incompletos.
Então confira sempre
se os pré-requisitos estão completos.
Todos foram bem-sucedidos?
Se não, um trabalho principal causará
falha em todos os trabalhos subsequentes.
Isso é muito importante.
Garanta que isso sempre aconteça.
Essa é a expectativa do WorkManager.
Se você está usando um trabalho único
com a política de append,
garanta o sucesso do trabalho principal.

Chinese: 
并停止应用的后台活动
所以这二者其实是一回事
还有可能是因为 你的 OS 或应用的工作负荷太大了
JobScheduler 在同一时间只会允许一定数量的活跃工作
而你可能超出了限制 这个规则适用于所有应用
WorkManager 还会受到的一个限制是
最初配置时设定的线程池
在默认情况下 线程池内含2-4项工作
所以 如果你试图同时做10项工作
其中一些便会加入延迟处理的队列
还有一种可能性是 你可能未能完全满足先决条件
所以 你应该随时查看
先决条件是否被完全满足了？检测是否全部通过？
如果有的条件没有通过 失败的母工作
将会致使它所属的一切子工作失败
这很重要 不要忽视这一点
请务必保证先决条件得到完全满足
这也是 WorkManager 能够正常工作的前提
如果你在使用的是带附加策略的单一工作
那么请确保母工作执行成功
因为 如果母工作失败

Japanese: 
この場合バックグラウンドジョブは
実行されません
同じことです
OSやアプリで実行する処理が
多すぎることも考えられます
JobSchedulerは特定の数のジョブしか
同時にアクティブにしません
それで
その数を超えている可能性があります
アプリ全体で起こります
WorkManagerは
構成時に指定する
スレッドプールでも制限されます
デフォルトでは
２～４のジョブです
一度に10個のジョブを
実行しようとすると
そのうちのいくつかは後で
処理されるようにキューに入れられます
前提条件が満たされていない場合もあります
前提条件を満たしているか
常に確認する必要があります
すべて成功しましたか？
すべてが成功していない場合
その失敗した親ジョブのせいで
派生ジョブすべてが失敗します
これは非常に重要です
まだこの問題に気付いたことがなければ
この問題に遭遇したことがなければ
注意してください
これはWorkManagerで
起こり得ることです
追加のポリシーで固有の処理を
実行している場合
親ジョブが失敗していないことを
確認してください
親ジョブが失敗すると
追加しているものがすべて

Spanish: 
Los trabajos de segundo plano
no se ejecutan en este caso.
Así que es igual.
Podría ser que tu SO
o tu aplicación
esté haciendo demasiado trabajo.
JobScheduler solo permite
que un cierto número de trabajos
al mismo tiempo.
Puede que lo estén excediendo.
Y eso es en todas las aplicaciones.
WorkManager también está limitado
por los subprocesos
que le dan al comienzo
cuando lo configuran.
Y de forma predeterminada,
eso es entre dos y cuatro trabajos.
Por eso, si intentan hacer
diez cosas a la vez,
quedarán en cola para más tarde.
También pueden tener prerrequisitos
incompletos o con fallas.
Siempre deben controlar
que los prerrequisitos están terminados.
¿Todos han tenido éxito?
Si no es así,
un trabajo principal fallido
hará que también fallen
todos sus trabajos secundarios.
Es muy importante.
Si aún no se han dado cuenta,
si todavía no les ha pasado,
siempre deberían
asegurarse de que pase.
Eso es lo que se espera en WorkManager.
Y si usan un trabajo único
con la póliza anexa,
asegúrense de que
el trabajo principal no falló.
Porque si falla,
todo lo que tengan anexado

English: 
Background jobs don't
run in this case.
So same thing.
It could be that
your OS or your app
is just doing too much work.
So JobScheduler only allows a
certain number of active jobs
at a time.
So you might be exceeding that.
And that's across all apps.
WorkManager is also
limited by the thread pool
you give it at the beginning,
when you configure it.
And by default, that's
between two and four jobs.
So if you're trying to
do 10 things at once,
you know some of them will
be in the queue for later.
And you could also have failed
or incomplete prerequisites.
So you should always check--
are your prerequisites finished?
Have they all succeeded?
If they haven't succeeded,
a failed parent job
will fail all its
descendant jobs.
So that's very important.
If you haven't
realized that yet,
if you haven't hit this
yet, you should always
make sure that happens.
That's the expectation
in WorkManager.
And if you're using a unique
work with the append policy,
make sure that the
parent job hasn't failed.
Because if it fails,
everything you keep appending

Indonesian: 
Tugas di latar belakang tidak
berjalan di kasus ini. Jadi sama saja.
Bisa jadi OS atau aplikasi Anda
melakukan terlalu banyak pekerjaan.
JobScheduler hanya mengizinkan 
beberapa tugas aktif dalam satu waktu.
Jadi, mungkin Anda melebihi itu.
Dan itu berlaku untuk seluruh aplikasi.
WorkManager juga
dibatasi oleh kumpulan thread
yang Anda berikan di awal, 
saat Anda mengonfigurasikannya.
Dan secara default, 
itu sekitar dua sampai empat pekerjaan.
Jadi, jika Anda mencoba 
melakukan sepuluh hal bersamaan,
beberapa di antaranya 
akan masuk di antrean berikutnya,
Dan Anda juga bisa gagal 
atau prasyaratnya tidak lengkap.
Jadi, selalu periksalah
apakah prasyarat Anda sudah terpenuhi?
Apakah semuanya sudah berhasil?
Jika belum berhasil, 
tugas induk yang gagal
akan menggagalkan semua tugas turunannya.
Jadi, ini sangat penting.
Jika Anda belum menyadarinya,
jika Anda belum mengalaminya,
Anda harus pastikan hal itu terjadi.
Itulah harapan di WorkManager.
Dan jika Anda menggunakan pekerjaan unik 
dengan kebijakan tambahan,
pastikan tugas induknya tidak gagal.
Karena jika gagal, 
semua yang Anda tambahkan

Korean: 
이때 백그라운드 작업은 실행하지 않기 때문에
같은 사례이죠
여러분의 OS나 앱이 문제일 수도 있습니다
일이 너무 많아서 그럴 수 있죠
JobScheduler는 활성화된 작업을
한 번에 처리하는 양이
정해져 있습니다
그런데 이를 초과했다면
모든 앱에 영향이 갈 수 있죠
그리고 WorkManager는 
여러분이 초기에 구성할 때
부여한 스레드 풀에 따라
한계가 정해지기도 합니다
기본적으로는 두 개에서 네 개 정도를 처리하죠
그런데 한 번에 열 개를 처리하려고 하면
그중 몇 개는 나중으로
연기될 수밖에 없는 겁니다
그리고 전제조건 달성 실패나 
미완성의 문제일 수도 있습니다
항상 전제조건을 충족했는지
모두 성공했는지 확인해야 하죠
성공하지 못했다면 실패한 상위 작업에 따라
귀속된 모든 하위 작업도 실패할 것입니다
이걸 아직 몰랐고
경험한 적도 없다면
이런 일은 언제나 일어날 수 있다는 것을
꼭 기억하셔야 합니다
WorkManager에서는 이런 일을 감안해야 합니다
그리고 Append 정책이 있는
고유한 작업을 사용한다면
상위 작업이 실패하지 않게 주의하세요
이게 실패하면 여러분이 추가해놓은 모든 것이

Japanese: 
失敗し続けるからです
近いうちにこの問題に対処する
APIを追加する予定です
この問題で苦労している
という報告を多数受けているからです
最後の理由は
アプリが強制停止されることです
強制停止は
通常[設定]から行うもので
アプリを強制停止させます
この操作ですべてのジョブと
アラームが終了されます
WorkManagerは極めて円滑に
これを処理します
次に初期化されると
すべてが再スケジュールされます
しかしこれは破壊的なアクションと
見なされるため
実際に強制停止されると
アプリは制御できなくなります
その時点では
アプリを起動できません
そのように意図されているからです
一部のデバイスでは
かなり強引にアプリが強制停止されます
これが発生した場合
私たちにご報告ください
いくつかの対処法があります
最後の点から生じるのが
＂なぜ私の処理は頻繁に実行されるのか？＂
という疑問です
この質問もよく尋ねられます
１つの例を考えてみましょう
ここに作成アクティビティがあります
周期的な作業リクエストを
キューに入れます
これは非常に頻繁に実行するものです
ここに問題があります

Indonesian: 
akan terus gagal.
Dan kami akan memberikan API 
untuk segera mengatasi ini.
Karena kami tahu banyak 
yang kesulitan dalam hal ini.
Dan alasan yang terakhir yaitu
aplikasi Anda bisa dipaksa berhenti.
Dan penghentian paksa biasanya 
berasal dari setelan Anda,
dan Anda perintahkan 
untuk menghentikan paksa aplikasi ini.
Itu menghapus semua tugas dan alarm.
Jadi, WorkManager 
menangani masalah ini dengan tepat.
Pada inisialisasi selanjutnya,
program ini akan 
menjadwalkan ulang semuanya untuk Anda.
Tetapi, karena ini 
dianggap sebagai tindakan destruktif,
kami tidak bisa mengontrol 
ketika ada penghentian paksa.
Kami tidak bisa membangunkan 
aplikasi Anda ketika hal itu terjadi.
Itulah maksudnya.
Dan beberapa perangkat 
yang kami tahu
menghentikan paksa aplikasi Anda 
dengan sangat agresif.
Jika Anda mengalami hal ini, 
bicarakan dengan kami.
Kami memiliki beberapa ide.
Akibat dari poin terakhir
adalah mengapa pekerjaan saya
berjalan terlalu sering?
Inilah pertanyaan 
yang sering ditanyakan pada saya.
Mari lihat contoh berikut.
Berikut adalah aktivitas pada Create,
dan Anda mengantrekan 
permintaan kerja periodik.
Dan masalah ini lumayan sering 
kami jumpai. Ini salah.

English: 
will keep failing.
And we'll be giving APIs
to address this soon.
Because we know a lot of people
sort of struggle with this one.
And then the final
reason is your app
could be force-stopped.
And a force stop is
something that you usually
go from your Settings, and
you say force stop this app.
It wipes out all
jobs and alarms.
So WorkManager handles
this fairly gracefully.
The next time it's
initialized, it'll just
reschedule everything for you.
But since this is considered
a destructive action,
we can't really control it
when it's force-stopped.
We can't wake up your app
for you at that point.
That's the intent.
And some devices we
know force-stop your app
very aggressively.
If you're running into
this, come talk to us.
We have some ideas.
And the corollary
to the last point
is why is my work
running too often?
This is one thing that
also people ask me.
Let's take a look at an example.
So here's an activity on
Create, and you're enqueue-ing
a periodic work request.
And this is something we
run into fairly often.
This is wrong.

Chinese: 
你附加在它上面的一切都会随之失败
我们很快就会给出 API 来解决这个问题
因为我们知道 很多人在为这个问题苦恼
最后一条原因是 你的应用可能被强制停止了
强制停止通常是操作者前往“设置”
并选择“强制停止这个应用”的结果
这个操作会清除所有工作和提醒
WorkManager 相当好地解决了这个问题
当应用再次初始化的时候 它会重新安排好一切
但是 因为强制停止属于具有破坏性的操作
我们无法控制那些被强制停止的应用
在这种情况下 我们无法唤醒那个应用
而这本就是“强制停止”这个操作的应有之义
据我们所知 有些设备在强制停止你的应用的时候
会采取非常激烈的手段
如果你遇到这样的状况 请联系我们
我们可能可以提供解决方案
根据最后一个原因 我们导出了一个推论
为什么我的工作运行得这么频繁？
有人问过我这个问题
我们来看一个案例
这里是一个 Activity 的 onCreate 方法
你正在把一条周期工作请求加入队列
这种情况还是比较常见的
但这是错误的

Portuguese: 
Caso ele falhe, tudo o que estiver
em append também terá falhas.
Em breve, forneceremos APIs
para solucionar isso.
Sabemos que muitos sofrem com isso.
Agora, o último motivo pode ser
o fechamento forçado do seu app.
Geralmente, forçamos o fechamento
de um app nas Configurações.
Isso remove todos os trabalhos e alarmes.
O WorkManager lida com isso elegantemente.
Na próxima inicialização,
ele reagenda tudo para você.
Mas, como é considerada
uma ação destrutiva,
não podemos controlar quando será forçado.
Nesse momento,
não podemos ativar o app para você.
É essa a intenção.
Sabemos que alguns dispositivos forçam
o fechamento do app agressivamente.
Se você tem esse problema,
fale conosco. Temos algumas ideias.
O corolário do último item é:
"Por que meu trabalho
é executado com tanta frequência?"
As pessoas também me perguntam isso.
Vamos olhar um exemplo.
Esta é uma atividade no onCreate,
e você adiciona à fila
uma solicitação de trabalho periódico.
Vemos isso com muita frequência,
mas está errado,

Korean: 
계속 실패할 테니까요
그리고 이 문제로 고생하는 사람들이
많다는 걸 알기에
곧 이걸 해결할 API를 내놓을 것입니다
마지막 원인은 여러분의 앱이
강제로 종료되었기 때문입니다
강제 종료는 설정에서 앱을 강제 종료하라는
과정을 거치면 일어납니다
모든 작업과 알람을 삭제해버리죠
그래서 WorkManager는
단계적으로 이를 처리합니다
다음에 초기화할 때는 여러분을 위해
모든 것을 재조정할 것입니다
하지만 이것을 파괴적인 행위로
간주하는 만큼
언제 앱이 강제 종료될지를
달리 제어할 방도가 없습니다
그 시점에서는 앱을 깨울 수 없죠
이건 의도한 부분입니다
그리고 어떤 기기는 여러분의 앱을
공격적으로 강제종료합니다
여러분이 이 문제를 겪는다면
말씀해주시기 바랍니다
해결 방안이 몇 가지 있습니다
마지막 질문은 이것입니다
제 작업이 이렇게 자주 실행되는 이유는 무엇인가요?
이것도 자주 물어봅니다
예를 살펴보죠
여기 onCreate 활동이 있고 
여러분은 PeriodicWorkRequest를
큐에 추가하고 있습니다
이건 꽤 자주 발생하는데요
이건 틀렸습니다

Spanish: 
también fallará.
Les daremos API
para resolver esto pronto.
Porque sabemos que mucha gente
enfrenta esto.
La razón final es que la aplicación
puede ser forzada a detenerse.
Una detención forzada
es algo a lo que vas desde Configuraciones
y dices que la aplicación
sea forzada a detenerse.
Borra todos los trabajos y alarmas.
WorkManager manera esto
con bastante gracia.
La próxima vez que se inicialice,
solo reprogramará todo por ustedes.
Pero como esto se considera
una acción destructiva,
no podemos controlarla
si forzamos la detención.
No podemos activar tu aplicación
por ti en ese punto.
Esa es la intención.
Algunos dispositivos
fuerzan a la aplicación a detenerse
de manera muy agresiva.
Si se encuentran con algo así,
vengan a hablarnos.
Tenemos algunas ideas.
Y el corolario
para el último punto
es ¿por qué mi trabajo
se ejecuta tan a menudo?
Esto es algo que la gente
también me pregunta.
Veamos un ejemplo.
Aquí hay una actividad en Create,
y estás poniendo en cola
una solicitud de trabajo periódica.
Esto es algo que encontramos muy a menudo.
Esto está mal.

Indonesian: 
Alasan hal ini salah adalah 
karena setiap kali Anda
mengantrekan permintaan kerja 
di luar create,
program ini membuat 
permintaan kerja periodik baru.
Dan pekerjaan periodik
terus menerus terjadi.
Beginilah cara yang benar.
Jadi, Anda mengantrekan 
permintaan pekerjaan periodik yang unik.
Dan permintaan pekerjaan 
periodik yang unik,
Anda bisa menentukan apa yang terjadi
jika nama permintaan pekerjaan itu 
sudah ada sebelumnya.
Jadi, di kasus ini, kami sarankan untuk 
menyimpan permintaan pekerjaan yang lama.
Jadi, jika sebelumnya kita 
pernah mengantrekannya, jangan buat lagi.
Gunakan saja yang sudah ada sebelumnya. 
Begitulah cara yang benar.
-Dan saya kembalikan ke Rahul.
-Ya, terima kasih, Sumir.
Sumir sudah sampaikan 
cara menggunakan WorkManager
secara eksperimental.
Dia juga sudah
menyinggung inisialisasi,
yang akan kita bahas lebih detail.
Ada dua jenis inisialisasi, 
yang pertama adalah inisialisasi otomatis.
Dan yang kedua on demand.
Mari kita bahas yang otomatis dulu.
Inisialisasi otomatis berguna 
saat Anda ingin WorkManager
terinisialisasi otomatis 
dengan konfigurasi default.
Itu jika Anda tidak ingin 
menyesuaikan apa pun,
dan hanya ingin default.

Japanese: 
その理由は
ただ作成するだけにとどまらず
その作業リクエストを
キューに入れるたびに
新たな周期的な作業リクエストが
作成されることにあります
これを実行すればするほど
周期的な処理が発生します
対処方法は次のとおりです
固有の周期的な作業リクエストを
キューに入れます
その周期的な作業リクエストで
同じ名前の作業リクエストが
存在している場合に
どうするかを指定できます
この場合 古い作業リクエストを
維持するようにします
これをキューに入れたら
それを繰り返し作成しません
すでに存在するものを使用し続けます
これが正しい対処方法です
ではラーフルと交代します
はい
スミア ありがとう
スミアはWorkManagerを
実験的に使用する方法について述べました
初期化についても言及しました
初期化の詳細に
注目していきましょう
初期化には２種類あります
１つ目は自動初期化です
２つ目はオンデマンドです
まず自動初期化について考えましょう
自動初期化は
WorkManagerに
デフォルト構成で自動的に
初期化する場合に役に立ちます
つまり
何もカスタマイズしない場合です
デフォルトがいい場合です
これが機能するように

English: 
The reason this is wrong
is because every time you
enqueue that work
request beyond create,
it creates a new
periodic work request.
And you just keep
having more and more
periodic work happening.
This is the right way to do it.
So you enqueue a unique
periodic work request.
And a unique periodic
work request,
you can specify what happens if
that work request of that name
already exists before.
So we're saying keep the old
work request in this case.
So if we've enqueue this
before, don't create it again.
Just keep using the
one we already have.
And this is the
right way to do it.
And over to Rahul.
RAHUL RAVIKUMAR: Yes,
thank you, Sumir.
So Sumir touched upon
how to experimentally use
work manager.
And he talked about
initialization before.
So let's look at
initialization in more detail.
There's two types of
initialization, the first one
being automatic initialization.
And the second one is on demand.
So let's look at
automatic first.
Automatic
initialization is useful
when you just want WorkManager
to be initialized automatically
with the default configuration.
That is, you don't want
to customize anything.
You just want the defaults.

Spanish: 
La razón por la que está mal
es porque cada vez
que pones en cola esa solicitud
de trabajo además de Create,
crean una nueva solicitud
de trabajo periódica.
Y tienes más y más trabajo periódico.
Esta es la forma correcta
de hacerlo.
Pones en cola una solicitud
de trabajo periódica única.
Con una única
solicitud de trabajo periódica,
puedes especificar qué pasa
si esa solicitud de trabajo con ese nombre
ya existía.
Deben guardar la solicitud
de trabajo vieja en ese caso.
Así que si antes lo pusimos en cola,
no lo creen de nuevo.
Sigan usando el que ya tienen.
Esta es la manera correcta de hacerlo.
Y ahora hablará Rahul.
Sí, gracias, Sumir.
Sumir habló sobre WorkManager en pruebas.
Y antes habló sobre la inicialización.
Miremos la inicialización
con más detalle.
Hay dos tipos, la primera
es la inicialización automática.
Y la segunda es a pedido.
Veamos primero
la inicialización automática.
Esta es útil
cuando quieres que WorkManager
se inicialice automáticamente
con la configuración predeterminada.
No quieres
personalizar nada.
Solo lo predeterminado.

Chinese: 
因为每次在 onCreate 的时候将工作加入队列
它就会创建出一条新的 PeriodicWorkRequest
然后 周期性工作就会越积越多
正确的做法是这样的
你需要把单一 WorkRequest 加入队列
而针对这条周期性工作 你可以指定
当同名 WorkRequest 已经存在时 该发生什么事情
在本例中 我们建议保留旧的 WorkRequest 
所以如果我们之前已经把它加入了队列
那么就不要再创建一遍
继续使用已经存在的这个便好
这才是正确的处理方式
接下来交给 Rahul
谢谢 Sumir
Sumir 讲的是 如何以实验性的手法使用 WorkManager
并简单提到过初始化
下面我们来仔细讨论一下初始化
初始化可以分为两种
第一种是自动初始化
第二种是按需初始化
先来讲讲自动初始化
如果你想让 WorkManager 采用默认配置自动完成初始化
那么这时自动初始化是有用的
也就是说 在这种情况下你不想更改任何设置

Portuguese: 
porque sempre que colocamos 
solicitações na fila do onCreate,
é criada uma nova
solicitação de trabalho periódico.
Isso causa cada vez mais
trabalhos periódicos.
Vou mostrar a maneira correta.
Adicione à fila uma única solicitação
de trabalho periódico.
Assim, você pode definir o que acontece
com solicitações existentes de mesmo nome.
Ou seja, mantenha a antiga
solicitação de trabalho nesse caso.
Se já adicionamos à fila,
não criaremos novamente.
Basta usar o que já temos.
Essa é a maneira correta.
- Com a palavra, Rahul.
- Obrigado, Sumir.
O Sumir falou do uso experimental
do WorkManager.
Antes, ele mencionou a inicialização.
Entraremos em mais detalhes
sobre a inicialização.
Há dois tipos de inicialização:
automática e sob demanda.
Vejamos primeiro a automática.
A inicialização automática é útil
para iniciar o WorkManager automaticamente
com as configurações padrão.
Ou seja, sem personalizações,
o padrão de fábrica.

Korean: 
틀린 이유는 여러분이 create 뒤에
작업 요청을 추가할 때마다
여기서는 새로운 반복 작업 요청을 
생성하며
여러분은 계속 반복 작업이
더 일어나게만 하고 있기 때문이죠
이게 제대로 된 방식입니다
고유한 반복 작업 요청을 큐에 추가하는데
이러한 작업 요청에서는
이 이름의 작업 요청이 앞에 이미 존재한다면
어떤 일이 벌어지는지
명시할 수 있습니다
즉, 이런 경우에는 
오래된 작업 요청을 유지하라는 겁니다
이걸 전에 큐에 추가해두었다면
다시 생성하지는 마세요
기존의 것을 재사용하면 됩니다
이렇게 하시면 됩니다
이제 라훌에게 넘기겠습니다
고마워요, 수미르
수미르는 WorkManager를 실험적으로 사용하는 법을
간략하게 설명했습니다
그 전에 초기화도 이야기해줬는데요
이제 초기화를 더 자세히 알아보겠습니다
초기화에는 두 종류가 있습니다
하나는 자동화된 초기화이고
다른 것은 주문형 초기화입니다
자동 초기화를 먼저 보겠습니다
여러분이 WorkManager를 기본 구성으로
초기화하고 싶다면 자동 초기화가
유용합니다
맞춤 설정은 없어도 되고
기본 구성만 있으면 되는 경우에 말이죠

Spanish: 
Funciona con un proveedor de contenido
que tenemos
llamado WorkManager Initializer.
Está fusionado en el manifiesto
de tu aplicación.
Así trabajan
los proveedores de contenidos.
Primero, se inicializan,
antes de que ocurra
la aplicación onCreate.
Entonces WorkManager inicializa
el método onCreate.
Llamaremos a WorkManager
para inicializar
y especificar la configuración
predeterminada.
Cuando ocurre la aplicación onCreate,
WorkManager ya está inicializado.
Cuando llamas
a WorkManager.getInstance,
siempre dará una instancia
no nula de WorkManager
Y eso es bueno.
Sin embargo, si miras este diagrama,
en realidad tenemos
tu aplicación onCreate.
Le estamos agregando el costo
de inicializar WorkManager
a tu aplicación Create,
y eso no es bueno.
Para solucionar esto,
ofrecemos la inicialización a pedido.
Esta inicialización es útil
si quieres que WorkManager
se inicialice perezosamente.
No quieres que se inicialice
en el momento
que ocurre la aplicación onCreate.
Y también quieres
quizás personalizar
la configuración predeterminada.
Veamos esto en más detalle.
Lo primero que necesitas hacer

Korean: 
이게 작동하는 방식을 보면
WorkManager 이니셜라이저라는
콘텐츠 공급자가 있습니다
이니셜라이저는 manifest를 
여러분의 앱으로 합칩니다
그리고 콘텐츠 공급자가 작동하는 방식을 보면
애플리케이션에 onCreate가 발생하기 전에
콘텐츠 공급자가 초기화됩니다
그래서 WorkManager는
onCreate 메서드를 초기화합니다
WorkManager.initialize를 호출하고
기본 구성을 명시합니다
그래서 애플리케이션의 onCreate가 발생하면
WorkManager는 이미 초기화된 상태라서
여러분이 Workmanager.getInstance를 호출하면
이 시점에서 여러분은 
항상 null이 아닌 WorkManager 인스턴스를
받게 됩니다
이건 괜찮습니다
하지만 여러분이 이 플로차트에서 깨달았듯이
우리는 실제로 애플리케이션 onCreate를 받습니다
그래서 여러분의 애플리케이션 onCreate에
WorkManager 초기화 비용을 
추가해야 합니다. 좋지 않죠
이를 해결하기 위해
주문형 초기화를 제공합니다
주문형 초기화는 여러분이 WorkManager의
초기화를 지연하고 싶을 때 유용합니다
애플리케이션 onCreate가
발생하는 시점에 초기화하고 싶지 않다면
좋은 방법이죠
그리고 기본 구성도 취향에 맞게
설정할 수 있습니다
이 사례를 더 자세히 보겠습니다
먼저 여러분은 기본 이니셜라이저를

Portuguese: 
Isso funciona com o provedor de conteúdo
chamado Work Manager Initializer.
Ele mescla o manifesto no seu app.
Os provedores de conteúdo funcionam
sendo inicializados primeiro,
antes que aconteça o aplicativo onCreate.
O WorkManager
inicializa o método onCreate.
Chamamos WorkManager.initialize
e especificamos a configuração padrão.
Quando acontece o aplicativo onCreate,
o WorkManager já foi iniciado.
Agora, quando chamarmos
WorkManager.getInstance,
sempre receberemos uma instância
não nula do WorkManager.
Isso é ótimo.
No entanto,
se observarmos este fluxograma,
o aplicativo fica no onCreate.
Então, adicionamos o custo
de inicializar o WorkManager
ao onCreate do aplicativo,
o que não é ideal.
Para corrigir isso, criamos
a inicialização sob demanda.
Ela é útil para atrasar
a inicialização do WorkManager.
Não queremos que ele seja iniciado
junto com o aplicativo onCreate.
Também é possível
personalizar a configuração padrão.
Vejamos isso em mais detalhes.

Indonesian: 
Cara kerjanya adalah 
kita punya penyedia konten
yang disebut dengan 
Penginisialisasi WorkManager.
Dan manifestasi
digabungkan ke aplikasi Anda.
Cara kerja penyedia konten
adalah penyedia konten
diinisialisasi terlebih dahulu,
sebelum Application onCreate diterapkan.
Jadi, WorkManager menginisialisasi 
metode onCreate.
Kita akan memanggil
WorkManager.initialize
dan menentukan 
konfigurasi default.
Dan saat Application onCreate diterapkan,
WorkManager telah diinisialisasi.
Jadi, saat Anda memanggil
WorkManager.getInstance,
saat ini, dia akan selalu memberikan 
instance WorkManager selain null.
Dan itu bagus.
Meski demikian, jika Anda
perhatikan diagram alir ini,
kita sebenarnya sedang memulai 
Application onCreate Anda.
Jadi, kita menambahkan biaya
penginisialisasi WorkManager
ke Application onCreate,
yang tidak bagus.
Untuk memperbaikinya, kami
memberi Anda inisialisasi on demand.
Inisialisasi on demand sangat berguna
saat Anda ingin WorkManager Anda 
diinisialisasi dengan lambat.
Jadi, Anda tidak ingin menginisialisasinya
saat Application onCreate diterapkan.
Dan Anda mungkin juga ingin
menyesuaikan konfigurasi default.
Mari kita lihat lebih detail.
Hal pertama yang
Anda perlu lakukan adalah

Chinese: 
这种做法的原理是 我们有一个内容提供器
名叫 WorkManager Initializer
它可以把 manifest 导入你的应用
内容提供器的工作原理是
内容提供器首先进行初始化
然后才轮到 Application 的 onCreate
而后 WorkManager 会初始化 onCreate 方法
我们会调用 WorkManager.initialize
并指定默认配置
所以在 Application 运行 onCreate 的时候
WorkManager 已经初始化完成了
所以 当你调用 WorkManager.getInstance 的时候
总会返回一个非空实例
这是好事
不过 请注意 在这张流程图中
我们实际上在 Application 运行 onCreate 时
也进行了 WorkManager 初始化
这可不总是好事
为了解决这个问题 我们提供了按需初始化
如果你想要延迟初始化 WorkManager
这时按需初始化就可以发挥作用了
也就是说 你不想让它
在 应用执行onCreate() 的瞬间就被初始化
而且你还想尽可能地定制默认配置
下面我们来详细讲讲

English: 
The way this works is we
have a content provider
called WorkManager Initializer.
And that gets manifest
merged into your app.
And the way content
providers work
is content providers
get initialized first,
before Application
onCreate happens.
So WorkManager initializes
onCreate method.
We will call
WorkManager.initialize
and specify the
default configuration.
And so when Application
onCreate happens,
WorkManager is
already initialized.
And so when you call
WorkManager.getInstance,
at this point, it will always
give you a non-null WorkManager
instance.
And that's good.
However, if you
notice this flowchart,
we are actually getting
your Application onCreate.
So we are adding the cost
of initializing WorkManager
to your application
create, which is not great.
So to fix that, we give you
on-demand initialization.
On-demand
initialization is useful
when you want WorkManager
to be initialized lazily.
So you don't want it to
be initialized the moment
Application onCreate happens.
And you want to also
possibly customize
the default configuration.
So let's look at
that in more detail.
So the first thing
you need to do

Japanese: 
WorkManager Initializerという
コンテンツプロバイダを用意しました
これはマニフェストを
アプリに組み込みます
コンテンツプロバイダは
アプリケーションで
onCreateが実行される前に
初期化されます
WorkManagerは
onCreateメソッドを初期化します
WorkManager.initializeを呼び出し
デフォルト構成を指定します
アプリケーションで
onCreateが実行されるときには
WorkManagerはすでに
初期化されています
WorkManager.getInstanceを
呼び出すときには
nullでないWorkManager
インスタンスが提供されています
これは良いでしょう
しかし
このフローチャートを見る限り
取得しているのは
アプリケーションのonCreateです
WorkManagerの
初期化にかかるコストが
アプリケーションの作成に追加
されるのは好ましくありません
これを改善するために
オンデマンド初期化が用意されました
オンデマンド初期化は
時間をおいてWorkManagerを
初期化する場合に役立ちます
つまりアプリケーションの
onCreateが実行される時点では
初期化されないようにする場合です
デフォルト構成をカスタマイズする
場合にも役立ちます
では詳しく見ていきましょう

Chinese: 
你需要做的第一件事是 禁用默认初始化方法
如果不这样做的话 我们仍会使用内容提供器
来初始化 WorkManager 这不是好事
现在 当你调用 WorkManager.getInstance
并为其提供 context 的时候
我们会检测它是否已经被初始化了
如果答案是肯定的 则会返回实例
如果答案是否定的 则会同步初始化 WorkManager
并返回实例
今后 所有人都会这样得到返回实例
这就是按需初始化的工作原理
那么我们是如何发现 WorkManager 所需的配置的呢
是这样的 你的应用类
子类会实现一个 Configuration.Provider
它有一个单一的方法 名叫 getWorkManagerConfiguration
使得我们能够获取所需配置来初始化 WorkManager
首先 我们从 Application 中获取配置
然后我们再用它来初始化 WorkManager
如果你的应用类没有实现这个接口的话
便会使用默认配置 
并初始化 WorkManager

English: 
is you want to disable
the default initializer,
because if you don't, then we'll
still use the content provider
to initialize WorkManager.
And that's bad.
So now when you call
WorkManager.getInstance
and give it the context,
we'll check if it's already
been initialized.
And if it has, then
you give that--
we'll give you
back that instance.
If it hasn't been
already initialized,
then we'll synchronously
initialize WorkManager
at that point in time and
give you that instance.
And going forward, that
will be the instance
that everybody gets.
So that's how on-demand
initialization works.
So how do we discover the
configuration, though,
because WorkManager
needs the configuration?
So the way this works is
your application class--
the subtype implements a
Configuration.Provider.
And that has a
single method called
get WorkManager configuration.
And that gives us
the configuration
we need to use to
initialize WorkManager.
So first thing we do is
get the configuration
from the application.
And then we use that to
initialize WorkManager.
If your application
class does not actually
implement that
interface, then we'll
just use the default
configuration,
but still initialize
WorkManager.

Portuguese: 
Primeiro, você precisa
desativar o inicializador padrão.
Caso contrário, o provedor de conteúdo
ainda inicializará o WorkManager.
Isso é ruim.
Agora, quando você chamar
WorkManager.getInstance
e der o contexto,
verificaremos se já foi inicializado.
Se sim, devolveremos essa instância.
Caso contrário, o WorkManager
será inicializado sincronicamente
naquele momento
e abriremos a instância.
Daqui para frente,
todos receberão essa instância.
É assim que funciona
a inicialização sob demanda.
Então, como descobrimos a configuração
necessária para o WorkManager?
O subtipo da classe do seu aplicativo
implementa um Configuration.Provider,
que tem um único método chamado
configuração getWorkManager.
Isso nos dá a configuração necessária
para inicializar o WorkManager.
A primeira coisa a fazer
é obter a configuração do aplicativo.
Depois, usamos isso
para inicializar o WorkManager.
Se a classe do seu aplicativo
não implementa essa interface,
usaremos a configuração padrão
para ainda assim iniciar o WorkManager.

Indonesian: 
Anda ingin menonaktifkan
penginisialisasi default,
jika tidak, kita akan
tetap menggunakan penyedia konten
untuk menginisialisasi WorkManager. 
Dan itu tidak baik.
Sekarang, saat Anda memanggil 
WorkManager.getInstance
dan memberinya konteks, kita akan 
memeriksanya jika sudah diinisialisasi.
Jika sudah,
kami akan mengembalikan
instance itu pada Anda.
Jika belum diinisialisasi,
kami akan secara sinkron
menginisialisasi WorkManager
pada saat itu juga dan
memberi Anda instance tersebut.
Dan ke depan, itu akan menjadi
instance yang didapat semua orang.
Jadi, itulah cara kerja
inisialisasi on demand.
Lalu bagaimana kita 
menemukan konfigurasinya,
mengingat WorkManager
memerlukan konfigurasi?
Jadi, cara kerjanya adalah
class aplikasi Anda,
subjenis mengimplementasikan
Configuration.Provider.
Dan cara itu punya
metode tunggal yang disebut
get WorkManager configuration.
Dan itu memberi kita konfigurasi
yang kita perlu gunakan
untuk menginisialisasi WorkManager.
Jadi, pertama, mendapatkan
konfigurasi dari aplikasinya,
lalu menggunakannya untuk
menginisialisasi WorkManager.
Jika class tidak benar-benar 
menerapkan antarmuka itu,
kita gunakan konfigurasi default,
tapi WorkManager tetap diinisialisasi.

Spanish: 
es deshabilitar
el inicializador predeterminado,
porque si no lo haces,
aún usaremos el proveedor de contenido
para inicializar WorkManager.
Y eso es malo.
Ahora cuando llamas
a WorkManager.getInstance
y le das el contexto,
revisaremos si ya está inicializado.
Si lo está, le das...
Te daremos de vuelta
esa instancia.
Si no se ha inicializado,
inicializaremos sincrónicamente
WorkManager
en ese punto de tiempo
y te daremos esa instancia.
Y más adelante,
esa será la instancia
que todos obtengan.
Así es cómo funciona
la inicialización a pedido.
Entonces, ¿cómo descubrimos
la configuración?
Porque WorkManager
la necesita.
La manera en que funciona
es la clase de tu aplicación...
El subtipo implementa
un Configuration.Provider.
Ese tiene un método simple
llamado getWorkManageconfiguration
Eso nos da la configuración
que necesitamos usar
para inicializar WorkManager.
Lo primero que hacemos
es buscar esa configuración
en la aplicación.
Luego la usamos
para inicializar WorkManager.
Si la clase de tu aplicación
no implementa
esa interfaz, entonces usaremos
la configuración predeterminada,
pero igual inicializaremos
WorkManager.

Korean: 
비활성화해야 합니다
그러지 않으면 계속 WorkManager를 초기화하고자
콘텐츠 공급자를 사용할 것이기 때문이죠
그러면 안 되겠죠
그래서 WorkManager.getInstance를 호출하고
여기에 컨텍스트를 제공하면
그게 이미 초기화된 것인지
확인할 것입니다
그리고 초기화가 된 것이라면 우리는
인스턴스를 여러분에게 되돌려줄 것입니다
아직 초기화되지 않았다면
그 시점에서 WorkManager를 동기로
초기화하고 여러분에게 그 인스턴스를 주겠죠
이후 모든 사람이 그 인스턴스를
얻을 것입니다
주문형 초기화는 이렇게 동작합니다
그렇다면 구성은 어떻게 발견할까요?
작업관리자는 그 구성이 필요한데 말이죠
이것은 여러분의 애플리케이션 클래스인
Configuration.Provider를 
구현하는 것입니다
여기에는 단일 메서드인
getWorkManagerconfiguration이 있습니다
이건 WorkManager를 초기화하기 위해
필요한 구성을 제공합니다
그래서 첫 번째로 할 일은 애플리케이션에서
구성을 얻는 것이죠
그리고 이를 WorkManager 초기화에 사용하는 것입니다
여러분의 애플리케이션 클래스가
이 인터페이스를 구현하지 않는다면
그냥 기본 구성을 사용할 것입니다
그래도 WorkManager는 초기화합니다

Japanese: 
まずデフォルトのイニシャライザを
無効にする必要があります
そうしないと
コンテンツプロバイダを
使用し続けてしまいます
これはよくありません
WorkManager.getInstanceを
呼び出し
コンテキストを与えるときに
すでに初期化されているかどうかを
チェックします
初期化後に呼び出し
コンテンツを与えた場合
そのインスタンスを戻します
初期化されていない場合は
同期的にWorkManagerが
初期化され
その時点で
インスタンスが与えられます
これがゆくゆくは
すべての人が取得する
インスタンスになります
オンデマンド初期化は
このように機能します
ところで構成はどのように
検出されるのでしょうか
構成はWorkManagerが必要とします
ここで使用するのは
アプリケーションクラスです
サブタイプが
Configuration.Providerを実装します
Configuration.Providerには
getWorkManagerConfiguration
というメソッドがあります
これにより
WorkManagerを初期化するのに必要な
構成を取得できます
まずアプリケーションから
構成を取得します
その構成を使用して
WorkManagerを初期化します
アプリケーションクラスが
そのインターフェースを実装しない場合
デフォルト構成を使用しますが
WorkManagerは初期化されます

Portuguese: 
Vamos falar dos prós e contras.
São óbvios os prós
da inicialização sob demanda.
Isso gera um maior desempenho
na inicialização do app.
Isso porque não bloqueamos
seu aplicativo no onCreate
para inicializar o WorkManager.
Atrasamos a inicialização.
Isso também pode resolver muitos problemas
específicos aos dispositivos.
Percebemos que OEMs
tratam de qualquer jeito
o protocolo de inicialização
do provedor de conteúdo.
Então, às vezes, o WorkManager
não foi inicializado corretamente
ou executa muitos trabalhos.
Isso acontece quando
o protocolo de inicialização
não é seguido corretamente.
Para tanto, é possível usar
a inicialização sob demanda.
Um dos contras é que, às vezes,
o aplicativo tem fechamento forçado.
Lembre que, em todo fechamento forçado,
seus trabalhos e alarmes são zerados.
Isso não é um problema,
porque como o Sumir disse,
o WorkManager usa o banco de dados interno
como fonte da verdade.
Então sabemos quais workers existem
e como devem ser agendados.
Então, reagendamos tudo.

Indonesian: 
Sekarang mari lihat
pro dan kontranya.
Untuk inisialisasi on demand,
pro-nya sudah jelas.
Ini bisa membuat
performa startup aplikasi lebih baik,
karena Application onCreate
tidak benar-benar diblokir
untuk menginisialisasi WorkManager.
Kita akan menginisialisasinya 
dengan lambat.
Ini juga bisa mengatasi 
masalah khusus perangkat.
Kami perhatikan ada
OEM yang coba mengakali
protokol inisialisasi penyedia konten.
Jadi, kadang Anda menjumpai kasus
di mana WorkManager masih belum
diinisialisasi dengan benar
atau ada
terlalu banyak pekerjaan.
Dan ini biasanya
karena penyedia konten...
protokol inisialisasi 
tidak diikuti dengan benar.
Untuk itu, Anda bisa menggunakan
inisialisasi on demand.
Salah satu kontranya adalah
terkadang aplikasi Anda dipaksa berhenti.
Dan ingat, saat kejadian 
penghentian paksa ini terjadi,
semua pekerjaan 
dan alarm Anda akan dihapus total.
Dan biasanya ini tidak menjadi
masalah, karena ingat,
seperti yang Sumir katakan,
WorkManager memiliki
sumber kebenaran, yaitu
database internal.
Jadi, kami tahu worker mana yang tersedia,
dan bagaimana menjadwalkannya.
Jadi, hanya perlu
menjadwal ulang semuanya.

Korean: 
이번엔 장단점을 알아보죠
주문형 초기화의 장점은 분명합니다
앱 시작 시 성능을 더 끌어냅니다
이는 우리가 WorkManager를 초기화할 때
애플리케이션 onCreate를 차단하지 않기 때문입니다
초기화를 지연할 뿐이죠
그리고 다양한 기기 특정 문제에도 작동합니다
우리는 OEM이 콘텐츠 제공자
초기화 프로토콜을
부정적인 방법으로
사용한다는 것을 알았습니다
그래서 여러분은 종종
WorkManager가 제대로 초기화되지 않거나
작업이 너무 많은 상황도
종종 마주하실 겁니다
이는 대개 콘텐츠 제공자가 
초기화 프로토콜을
준수하지 않아서 생깁니다
그래서 이럴 때는
주문형 초기화를 사용할 수 있습니다
단점이라면 가끔 여러분의 애플리케이션이
강제종료된다는 것이죠
그리고 강제 종료되는 일이 생긴다면
모든 작업과 알람이 삭제된다는 것을 기억하세요
보통 이건 큰 문제가 아닙니다
왜냐하면 수미르가 말했듯이
WorkManager에는
정보 출처인 내부 데이터베이스가 있기 때문이죠
그래서 우리는 어떤 워커가 존재하고
이걸 어떻게 조정해야 할지 알고 있습니다
그래서 모든 내용을 재조정하는 것이죠
하지만 재조정은 WorkManager가

Japanese: 
長所と短所についてお話ししましょう
オンデマンド初期化の長所は明白です
アプリ起動時の性能が上がります
WorkManagerを初期化するために
アプリケーションのonCreateを
ブロックしないからです
WorkManagerは時間を置いて
初期化します
これにより
デバイス固有の多くの問題を回避できます
OEMがコンテンツプロバイダの
初期化プロトコルを
いい加減に扱っていることが
確認されています
そのため
WorkManagerが正常に初期化されない
またはジョブが多くなり過ぎるという
事象が発生する
可能性があります
これは通常
コンテンツプロバイダが
初期化プロトコルに従わないために
発生します
これらの問題に対処するため
オンデマンド初期化を使用できます
短所の１つはアプリケーションが
強制停止されることです
強制停止のイベントが発生したら
すべてのジョブとアラームが
消えてしまいます
通常これは問題になりません
スミアが述べていたように
WorkManagerには
情報源つまり内部データベースがあるからです
存在しているワーカーを把握できます
どのようにスケジュールされる
必要があるかも分かります
すべてを再スケジュールします
ただし再スケジュールは

Chinese: 
下面我们来讨论一下利弊
按需初始化的优势很明显：
它让应用时的效率提高了
这是因为 我们不会阻止你的应用执行 onCreate
来初始化 WorkManager
而是延迟初始化
这种做法还会避开很多由某些设备所特有的问题
我们留意到一些 OEM 企业对 ContentProvider 初始化的处理方式
是非常宽松 只追求处理速度的
所以 有时你会遇到 WorkManager 未能正确初始化
或工作数量过多等情况
通常原因在于 没有正确遵循初始化协议
在这种情况下 你可以使用按需初始化
缺陷之一在于 有时你的应用会被强制停止
请记住 如果发生了强制停止现象
你所有的工作和警报提醒都会被清除
通常这并不算什么问题 
因为 正如 Sumir 所说 
WorkManager 拥有“原始数据” 也就是内置数据库
所以 我们知道有哪些 Worker 是存在的
以及它们该如何安排
所以 我们会重排一切
但只有当 WorkManager 初始化的时候
我们才会进行重排

English: 
So let's talk about
some pros and cons.
So the pros are obvious for
on-demand initialization.
It can lead to a more
performant app startup.
That's because we don't actually
block your Application onCreate
for initializing WorkManager.
We'll initialize it lazily.
It can also work around a lot
of device-specific problems.
And so we have noticed that
OEMs play fast and loose
with content provider
initialization protocol.
So sometimes you
do encounter cases
where WorkManager has not
been initialized correctly
or you have too many jobs.
And this is normally
because the content provider
does not-- the initialization
protocol is not
correctly followed.
So for that, you can use
on-demand initialization.
One of the cons is
sometimes your application
does get force stopped.
And remember, when a
force stop event happens,
all your jobs and
alarms get wiped out.
And so usually this is not
a problem, because remember,
as Sumir said,
WorkManager has a source
of truth, which is
the internal database.
So we know what workers exist.
And we know how they
need to be scheduled.
So we'll just
reschedule everything.
However, that rescheduling
only happens when

Spanish: 
Hablemos de los puntos
positivos y negativos.
Los positivos son obvios
por la inicialización a pedido.
Puede lograr un mejor desempeño
en el inicio de la aplicación.
Eso es porque no bloqueamos
tu aplicación onCreate
para inicializar WorkManager.
La inicializamos perezosamente.
También puede superar
problemas específicos del dispositivo.
Hemos notado que las OEM
funcionan demasiado rápido
con el protocolo de inicialización
del proveedor de contenido.
Algunas veces encuentras casos
donde WorkManager
no se ha inicializado correctamente
o tiene demasiadas tareas.
Normalmente es porque
en el proveedor de contenidos…
el protocolo de inicialización
no se siguió correctamente.
Para esto, puedes usar
la inicialización a pedido.
Algo negativo es que a veces
tu aplicación
se detiene de manera forzada.
Y recuerda,
cuando hay una detención forzada,
todas tus tareas y alarmas
se borran.
Por lo general, esto no es
un problema, porque,
como Sumir dijo,
WorkManager tiene
una fuente de la verdad,
que es la base de datos interna.
Sabemos qué trabajadores existen.
Y sabemos cómo necesitan
ser programados.
Así que solo
reprogramaremos todo.
Sin embargo, esa reprogramación
solo ocurre

English: 
WorkManager is initialized.
So if you're delaying
WorkManager initialization,
the rescheduling is
also getting delayed.
This is usually not a
problem, because you can just
lazily call
WorkManager.getInstance
after the Application on Create.
And we have the-- and you
have the APIs to do that.
So switching gears, let's talk
a little bit about testing,
because unlike [INAUDIBLE]
talk, we actually
have time to talk about testing.
[LAUGHTER]
So when WorkManager was a
1.0 stable and a 2.0 stable,
it had very limited
support for testing.
And we know unit tests
are very important.
So in 2.1, we revamped
our testing story a lot.
So I want to talk about that.
So let's take a
worker, for example.
So here I have a
test worker, which
extends a coroutine worker
and has a suspending do work.
All it does is
delay for a second
and return a Result.success.
Now in an ideal world, if
I was testing this worker--
forget the fact that
this is a worker--
I would just create an
instance of this class.
And I would just call
doWork and assert that it

Indonesian: 
Namun, penjadwalan ulang itu hanya 
terjadi saat inisialisasi WorkManager.
Jika Anda menunda
inisialisasi WorkManager,
penjadwalan ulang 
juga akan tertunda.
Biasanya ini bukan masalah,
karena Anda bisa memanggil dengan lambat
WorkManager.getInstance
setelah Application onCreate.
Dan ada API untuk melakukan itu.
Ganti topik, mari berbicara
sedikit tentang pengujian,
karena tidak seperti pembicaraan
[TIDAK TERDENGAR],
kita sebenarnya masih punya waktu 
untuk membahas pengujian.
Saat WorkManager masih dalam
versi stabil 1.0 dan stabil 2.0,
dukungannya
sangat terbatas untuk pengujian.
Dan kita tahu bahwa
pengujian unit sangat penting.
Jadi, pada versi 2.1,
kami banyak ubah riwayat pengujian.
Saya ingin membahas itu.
Mari kita ambil
worker, sebagai contoh.
Jadi, di sini saya punya worker uji,
yang mengembangkan coroutine worker
dan memiliki penangguhan berfungsi.
Yang dilakukannya adalah
menunda sebentar
dan menampilkan Result.success.
Idealnya,
jika saya menguji worker ini...
lupakan fakta bahwa ini adalah worker,
saya hanya akan membuat 
instance class ini.
Dan saya hanya akan memanggil 
doWork dan menegaskan bahwa

Chinese: 
如果你推迟 WorkManager 的初始化
那么重排进程也会被推迟
通常这不是问题 因为你可以
在应用 onCreate 之后
延迟调用 WorkManager.getInstance
而我们为你准备了专门的 API 来实现这一点
换个话题 我们来简单谈谈测试
这可不是什么只属于极客圈子的东西
这是我们都感兴趣的话题
当 WorkManager 还是 1.0 和 2.0 稳定版的时候
它对测试的支持还是非常有限的
我们知道 单元测试非常重要
所以在 2.1 版本中 我们把测试强化了很多
我想谈的就是这方面内容
那就拿 Worker 来举个例子吧
这里有一个 TestWorker
它继承自 CoroutineWorker
它还有一个 suspend 的 doWork 方法
它的作用是延迟1秒
并返回一个 Result.success
在理想情况下 如果我在测试这个 Worker
先不提它是一个 Worker
我会先创建一个这个类的实例

Korean: 
초기화됐을 때만 발생합니다
그래서 WorkManager 초기화를 연기하고 있다면
재조정도 마찬가지로 연기됩니다
이것도 보통은 별문제가 아닙니다
애플리케이션 onCreate 이후에
그냥 WorkManager.getInstance를
지연 호출하면 되니까요
그리고 이를 할 수 있는 API도 있습니다
그러면 이제 관심을 돌려
테스팅 이야기를 해보죠
여느 개발자 대담과 달리
테스팅을 다룰 시간도 충분하니까요
[웃음]
그래서 WorkManager 1.0 안정판과 2.0 안정판일 때는
테스팅 지원 범위가 제한적이었습니다
그리고 우리는 단위 테스트가 
정말 중요하다는 것을 알기에
2.1에서는 테스트 부문을 뜯어고쳤습니다
이 부분을 이야기하고 싶습니다
워커를 예로 들어보죠
여기에 Coroutine 워커를 확장하고
doWork를 일시 중단하는 테스트 워커가 있습니다
이 구문은 1초간 지연했다가
Result.success를 반환합니다
이게 워커라는 것을 잠시 잊죠
이상적으로는 제가 이것을 테스트하고 있었다면
저는 그냥 이 클래스의 인스턴스를 생성했을 겁니다
그리고 doWork를 호출하고 이게 성공이라는 결과를

Portuguese: 
Só que esse reagendamento só ocorre
na inicialização do WorkManager.
Se você atrasar
a inicialização do WorkManager,
o reagendamento também será atrasado.
Isso não é um grande problema,
basta fazer uma chamada ociosa
WorkManager.getInstance
depois do aplicativo no onCreate.
Já existem APIs para isso.
Mudando de assunto,
vamos falar um pouco sobre testes,
porque, diferente da palestra anterior,
teremos tempo para falar disso.
Nas versões estáveis 1.0 e 2.0
do WorkManager,
havia suporte limitado a testes.
Sabemos como são importantes
os testes de unidade.
Portanto, na versão 2.1,
reformulamos os testes.
Quero falar sobre isso.
Tomemos um worker, por exemplo.
Aqui está um testWorker,
que estende um worker de coroutine
e tem um doWork suspenso.
Ele atrasa isso por um segundo
e retorna um Result.success.
Idealmente, caso eu estivesse
testando este worker,
deixando de lado o fato
de que é um worker,
eu apenas criaria
uma instância desta classe.

Japanese: 
WorkManagerが初期化された
ときにのみ発生します
WorkManagerの初期化を
遅らせると
再スケジュールも遅れます
通常これは問題になりません
アプリケーションのonCreateの後に
WorkManager.getInstanceを
時間をかけて呼び出すからです
またこれを実行するAPIもあります
話題を変えて
テストについて少しお話しします
誰かと違って
私にはまだテストについて
お話しする時間が残っているからです
WorkManager 1.0 安定版と
2.0 安定版では
テスト機能のサポートが
限られていました
単体テストが非常に重要であることは
認識しています
それでバージョン2.1でテスト機能を
大幅に改良しました
そのことについて
お話ししたいと思います
１つのワーカーの例を考慮しましょう
コルーチンワーカーを拡張した
テストワーカーがあり
保留中のdoWorkがあります
このワーカーはすべて
１秒間遅れて実行し
Result.successを返します
理想的な状況では
このワーカーをテストしたら
これがワーカーであるということは
忘れてください
このクラスのインスタンスを作成します

Spanish: 
cuando WorkManager se inicializa.
Entonces si retrasas
la inicialización de WorkManager,
también se retrasa
la reprogramanción.
Por lo general no es 
un problema, porque puedes
hacer una llamada diferida
a WorkManager.getInstance
después de la aplicación onCreate.
Y tienes las API para hacer eso.
Cambiando de tema,
hablemos un poco sobre las pruebas,
porque, a diferencia
de la charla de Yigit,
tenemos tiempo para hablar de eso.
Cuando WorkManager estaba
en 1.0 estable y 2.0 estable,
tenía una compatibilidad
muy limitada para las pruebas.
Sabemos que las pruebas de unidad
son muy importantes.
Entonces en 2.1, modernizamos mucho
nuestro historial de pruebas.
Así que quiero hablar sobre eso.
Tomemos un trabajador, por ejemplo.
Aquí tengo un trabajador
de prueba,
que extiende un trabajador de corrutina
y tiene un doWork suspendido.
Todo lo que hace
es retrasar un segundo
y volver a Result.success.
En un mundo ideal,
si estuviera probando este trabajador,
olviden el hecho
de que es un trabajador,
solo crearía una instancia
de esta clase.
Solo llamaría a doWork y afirmaría

English: 
returned a result of success.
It would be really that simple.
However, you know that
you can't actually
create instances
of workers really
easily, because you have
to use WorkerFactory.
And you have to provide
WorkManager the configuration.
And you have to go through the
full worker initialization.
So we made that easy by
giving you a new class
called Test Listenable
Worker Builder.
So in a test, if I want to test
the test worker that I defined,
the first thing I do is use
TestListenableWorkerBuilder,
give it the test worker, and
supply the context that I want.
And then I set some input data.
And I set some other
additional arguments as needed.
And when I call .build,
it really gives you a real
instance of Listenable Worker
that you can use for testing.
So at this point,
I can just call
startWork, which is a
method on Listenable Worker.
And I call the suspending await.
Await is suspending.
It will block-- it will
suspend until you get a result
from Listenable Worker.
And then once you get
that, you can always
assert on the result.
Because await is suspending,
I just wrapped my test
in a runBlocking block.

Indonesian: 
ini menampilkan hasil sukses.
Ini sangat sederhana.
Meski demikian, Anda tahu bahwa
Anda tidak benar-benar bisa 
membuat instance worker dengan mudah,
karena Anda harus 
menggunakan WorkerFactory.
Anda harus sediakan
konfigurasi untuk WorkManager,
dan harus melalui
inisialisasi worker penuh.
Jadi, kami mempermudah dengan
memberi Anda class baru
bernama TestListenableWorkerBuilder.
Jadi dalam pengujian,
jika saya ingin menguji
worker uji yang sudah saya tetapkan,
hal pertama yang saya lakukan
adalah menggunakan
TestListenableWorkerBuilder,
memberinya worker uji, 
dan memberi konteks yang saya inginkan.
Lalu saya menyetel beberapa data input.
Dan saya menyetel beberapa 
argumen tambahan sesuai kebutuhan.
Saat saya panggil .build, ini memberikan
instance Listenable Worker sebenarnya
yang bisa digunakan untuk pengujian.
Pada tahap ini,
saya cukup panggil startWork,
yaitu suatu metode
pada Listenable Worker.
Dan saya panggil suspending await.
Await ditangguhkan sampai Anda
mendapatkan hasil dari Listenable Worker.
Setelah Anda dapatkan,
Anda selalu bisa menegaskan hasilnya.
Karena await ditangguhkan,
saya baru saja menyelesaikan pengujian
di pemblokiran runBlocking.

Portuguese: 
Chamaria doWork e garantiria
que ele retornasse um Result.success.
Seria simples assim.
Mas, como vocês sabem, não se pode criar
instâncias de workers tão fácil assim,
porque precisamos usar o WorkerFactory
e fornecer a configuração ao WorkManager.
Temos que passar
por toda a inicialização do worker.
Facilitamos isso
ao fornecer uma nova classe
chamada "TestListenableWorkerBuilder".
Se eu quiser testar o worker que defini,
primeiro uso o
TestListenableWorkerBuilder,
atribuo o testWorker
e forneço o contexto que desejo.
Depois, defino dados de entrada.
Se necessário,
defino também outros argumentos.
Quando chamo .build, recebo
uma instância real do Listenable Worker
que posso usar para testes.
Nesse momento, posso chamar startWork,
um método no Listenable Worker.
Chamo de .await suspenso.
Ele permanecerá suspenso
até o resultado do Listenable Worker.
Quando receber o resultado,
você pode verificá-lo.
Como o .await está suspendendo,
envolvo meu teste em um bloco runBlocking.

Spanish: 
que devolverá Return.success.
Sería así de simple.
Sin embargo,
saben que en realidad
no pueden crear instancias
de trabajadores tan fácil
porque tienen
que usar WorkerFactory.
Tienen que darle
a WorkManager la configuración.
Tienen que pasar por toda
la inicialización del trabajador.
Hicimos que sea fácil
dándoles una nueva clase
llamada TestListenableWorkerBuilder.
En una prueba, si quiero probar
el trabajador de prueba que definí,
lo primero que hago es usar
TestListenableWorkerBuilder,
darle el trabajador de prueba
y proveerle el contexto que quiero.
Luego fijo algunos datos de entrada.
Luego fijo algunos otros
argumentos según se necesiten.
Cuando llamo a .build,
da una verdadera instancia
de ListenableWorker
que puedes usar para pruebas.
En este punto, solo puedo llamar
a startWork, que es un método
en ListenableWorker.
Y llamo la espera suspendida.
La espera está suspendida.
Bloqueará... Se suspenderá
hasta que tengas el resultado
de ListenableWorker.
Una vez que tengas esto,
siempre puedes
afirmar el resultado.
Porque la espera está suspendida,
envolví a mi prueba
en el bloque runBlocking.

Japanese: 
doWorkを呼び出し
成功の結果を返したことをアサートします
非常にシンプルなものです
しかし実際には
ワーカーのインスタンスは
簡単には作成できません
WorkerFactoryを使用しなければ
ならないからです
WorkManagerを
設定する必要もあります
ワーカーの初期化もすべて
行わなければいけません
そこで
TestListenableWorkerBuilderという
新しいクラスを作成することによって
これらの作業を簡単にしました
定義したテストワーカーを
テストする場合
まずTestListenableWorkerBuilder
を使用します
これをテストワーカーで指定し
目的のコンテキストを指定します
入力データを設定し
必要に応じて
その他の引数を設定します
.buildを呼び出すと
テストに使用できる
ListenableWorkerの
実際のインスタンスを取得できます
この時点で
ListenableWorkerのメソッドである
startWorkを呼び出せます
保留中のawaitを呼び出します
awaitは一時停止されています
ListenableWorkerから結果を取得するまで
ブロックつまり一時停止されます
結果を取得したら
いつでもアサートできます
awaitは一時停止されるため
runBlockingのブロックでテストを
ラップしました

Chinese: 
然后我会调用 doWork 并判断它返回一个成功结果
就这么简单
但要知道 你无法轻松创建 Worker 实例
因为你必须使用 WorkerFactory
必须为 WorkManager 提供配置
也必须走完整个 Worker 的初始化流程
我们简化了这些步骤 我们给你提供了一个新的类
名叫 TestListenableWorkerBuilder
在测试中 如果我想要测试我定义的 TestWorker
首先就要使用 TestListenableWorkerBuilder
把 TestWorker 交给它 然后提供我想要的 context
然后我会设置一些输入数据
根据需要设置其他的变元
当我调用 .build 的时候 它就会为你提供真实的
ListenableWorker 实例 方便你用来测试
这时 我只需调用 startWork
这是 ListenableWorker 上的一个方法
然后我再调用暂停的 await
await 就是暂停
它会维持这个状态 直到你从 ListenableWorker 那里获取到返回值
得到结果之后 你就可以 assertThat(result)
因为 await 就是暂停
所以我把测试封装进了 runBlocking 代码块
现在我的测试变得简单多了

Korean: 
반환했다고 선언했겠죠
그러면 정말 쉽겠죠
하지만 아시다시피
워커의 인스턴스는
그리 쉽게 만들 수 없습니다
WorkerFactory를 사용해야 하고
WorkManager에 구성도 부여해야 하며
전체 워커 초기화도 거쳐야 하기 때문입니다
그래서 우리는 여러분에게 
TestListenableWorkerBuilder라는
새로운 클래스를 부여하여 
이를 더 쉽게 만들었습니다
그래서 제가 정의한 
테스트 워커를 테스트하고 싶다면
먼저 할 일은 
TestListenableWorkerBuilder를 사용해서
테스트 워커를 주고 
제가 원하는 컨텍스트를 줍니다
그리고 입력 데이터를 설정하고
필요한 대로 다른 부가적인 전달인자도 설정합니다
그리고 제가 .build를 호출하면 실제로
테스트에 사용할 수 있는 
Listenable Worker 인스턴스를 받습니다
그래서 이 시점에서
Listenable Worker에서 메서드가 되는 
startWork를 호출하기만 하면 됩니다
그리고 일시 중단 함수인 await도 호출합니다
Await는 일시 중단 함수이며
여러분이 Listenable Worker에게서
결과를 얻을 때까지
일시 중단해줍니다
그리고 여러분이 결과를 얻으면
언제나 결과를
선언할 수 있습니다
Await가 일시 중단 함수라서
저는 runBlocking 블록에서
테스트를 마무리할 수 있죠

Chinese: 
因为我不需要再初始化 WorkManager
我不需要首先初始化一大堆东西然后才能初始化 Worker
现在我们来看看 测试同步 Worker 是什么样子
正如之前的例子那样 
无需继承 CoroutineWorker 只需继承 Worker 就够了
这样做一样也可以获得 Result.success
CoroutineWorker 和 TestWorker 的区别在于
它运行在一个预先配置好的执行器里
因为它一直都是在背景线程中执行的
所以当我测试这个 TestWorker 的时候
首先需要的就是定义它需要运行在哪个执行器里
这里我定义一个单线程执行器
然后 我不使用 TestListenableWorkerBuilder 
而是使用 TestWorkerBuilder
然后我把 executor 交给它
其余代码不变
我设定一些输入数据
再设定一些变元
当我调用 .build 的时候
就可以像之前一样 得到一个 ListenableWorker 的实例
然后我调用 startWork().await
然后它就整个被封装进 runBlocking 代码块了
因为到 await 这里会暂停

Indonesian: 
Jadi, sekarang pengujian
jauh lebih sederhana,
karena saya tidak perlu
menginisialisasi WorkManager.
Saya tidak perlu menginisialisasi
semua [? infra ?] yang diperlukan
untuk menginisialisasi worker.
Jadi, mari kita lihat seperti apa
pengujian worker sinkron itu.
Jadi seperti contoh sebelumnya,
bukannya
mengembangkan coroutine worker,
saya kembangkan worker.
Dan saya memiliki pekerjaan yang sama
[TIDAK TERDENGAR] 
mengembalikan kesuksesan.
Sekarang, perbedaan utama dalam
worker coroutine dan
worker uji di sini, 
yang mengembangkan ke worker sinkron,
adalah bahwa ini berjalan dalam executor 
yang telah dikonfigurasi sebelumnya,
karena ini selalu dijalankan
pada thread latar belakang.
Jadi untuk itu, saat saya
menguji worker uji ini,
hal pertama yang perlu saya lakukan
adalah menetapkan executor 
yang perlu dijalankan.
Jadi di sini, saya menetapkan
executor thread tunggal.
Dan alih-alih menggunakan Test
Listenable Worker Builder,
saya gunakan Test Worker Builder.
Dan saya berikan executor-nya.
Dan kode lainnya tetap sama.
Saya mengatur beberapa data input.
Saya mengatur beberapa argumen tambahan.
Dan saat saya memanggil .build, 
saya mendapatkan instance
dari Listenable Worker 
seperti yang saya lakukan sebelumnya.

Korean: 
이제 제 테스트는 훨씬 단순해졌습니다
WorkManager를 초기화하지 않아도 되니까
워커를 초기화하기 위해 필요한 인프라를
초기화하지 않아도 되는 거죠
그렇다면 동기 워커 테스트는 
어떻게 생겼는지 보겠습니다
이전 예와 비슷하지만
Coroutine 워커 확장 대신 
워커를 확장합니다
success를 반환하는 doWork가 있는 것은 같고요
Coroutine 워커와 동기 워커로 확장하는
테스트 워커 간 가장 큰 차이는
테스트 워커를 사전 구성 실행자에서
수행한다는 점입니다
이건 항상 백그라운드 스레드에서
실행되기 때문입니다
그래서 제가 이 테스트 워커를 테스트할 때는
먼저 해야 할 일은 이게 실행돼야 할
실행자를 정의하는 것입니다
그래서 여기에 단일 스레드 실행자를 정의했고요
여기서 TestListenableWorkerBuilder를 사용하지 않고
TestWorkerBuilder를 사용합니다
그리고 여기에 실행자를 줍니다
나머지 코드는 모두 같습니다
입력 데이터를 설정하고
부가적인 인수도 설정했죠
그리고 제가 .build를 호출했을 때
이전과 마찬가지로 Listenable Worker의
인스턴스를 얻습니다
그리고 startWork와 await를 호출하면
전체가 runBlocking 블록에 속하게 됩니다
이건 await가 일시 중단이기 때문이죠

Portuguese: 
Agora, meu teste fica muito mais simples,
porque não preciso
inicializar o WorkManager.
Não preciso inicializar a infraestrutura
necessária para inicializar um worker.
Agora, vejamos o teste
de um worker síncrono.
Assim como o exemplo anterior,
em vez de estender um worker de coroutine,
eu estendo um worker.
E o mesmo doWork é bem-sucedido.
Agora, a principal diferença
entre um worker de coroutine e um de teste
que estende para o worker síncrono,
é que este é executado
em um executor pré-configurado,
já que é sempre executado
em uma thread de segundo plano.
Para tanto, quando eu testo
esse testWorker,
primeiro preciso definir o executor
no qual ele será executado.
Aqui, defino um executor de thread única.
Em vez de usar
o TestListenableWorkerBuilder,
uso o TestWorkerBuilder
e forneço o executor a ele.
O resto do código permanece igual.
Defino alguns dados de entrada
e outros argumentos.
Quando eu chamo .build,
recebo uma instância
do ListenableWorker, como antes.
Eu chamo startWork e espero.
Então, tudo é envolvido
em um bloco runBlocking,
já que foi suspenso pelo .await.

Spanish: 
Así que ahora mi prueba
es mucho más simple,
porque no tengo
que inicializar WorkManager.
No tengo que inicializar
todos los infra necesarios
para inicializar el trabajador.
Veamos cómo se ve
un trabajador sincrónico de prueba.
Igual que el ejemplo anterior,
en lugar de extender la corrutina
del trabajador, extenderé el trabajador.
Y tengo el mismo doWork
de Result.success.
La diferencia principal
en el trabajador de corrutina
y el trabajador de prueba,
que se extiende al trabajador sincrónico
es que se ejecuta
en un ejecutor preconfigurado,
porque siempre se ejecuta
en un subproceso de segundo plano.
Para eso, cuando estoy
probando mi trabajador de prueba,
lo primero que necesito hacer
es definir el ejecutor
que debe ejecutarse.
Aquí estoy definiendo
un ejecutor de un solo subproceso.
Luego en lugar de usar
TestListenableWorkerBuilder,
usaré TestWorkerBuilder.
Y le doy el ejecutador.
El resto del código es igual.
Fijo algunos datos de entrada.
Fijo algunos argumentos adicionales.
Y cuando llamo a .build,
solo obtengo una instancia
de ListenableWorker como hice antes.
Y llamo a startWork y espero.
Todo esto está rodeado
por un bloque runBlocking
porque la espera está suspendida.

English: 
So now my test became
so much simpler,
because I don't have to
initialize WorkManager.
I don't have to initialize
all of the [? infra ?] needed
to initialize a worker.
So let's look at what testing a
synchronous worker looks like.
So just like the previous
example, unlike--
instead of extending a coroutine
worker, I'm extending a worker.
And I have the same do work
[INAUDIBLE] return success.
Now, the key difference in
coroutine worker and a test
worker here, that extends
to the synchronous worker,
is that this runs in a
preconfigured executor,
because this is always executed
on a background thread.
And so for that, when I am
testing this test worker,
the first thing I need to
do is to define the executor
that it needs to run in.
So here, I am defining a
single-threaded executor.
And then instead of using Test
Listenable Worker Builder,
I'm using Test Worker Builder.
And I give it the executor.
And the rest of the
code remains the same.
I set some input data.
I set some additional arguments.
And when I call .build, I just
get an instance of Listenable
Worker like I did before.
And I call startWork and await.
And the whole
thing is surrounded
in a runBlocking block,
because await is suspending.

Japanese: 
これでテストは
よりシンプルになりました
WorkManagerを初期化する
必要がなくなりました
ワーカーを初期化するために
必要なものすべてを
初期化せずに済みます
次に同期ワーカーの
テストについて見てみましょう
前の例ではコルーチンワーカーを
拡張しましたが
ここではワーカーを拡張し
同じdoWorkを使用して成功を返します
コルーチンワーカーと
同期ワーカーに拡張する
テストワーカーの主な違いは
こちらが事前に構成した
エグゼキュータで実行することです
バックグラウンドのスレッドで
常に実行されるからです
それで
このテストワーカーをテストする際に
まずそれが実行されるエグゼキュータを
定義する必要があります
ここでシングルスレッドの
エグゼキュータを定義します
TestListenableWorkerBuilderを
使用する代わりに
TestWorkerBuilderを使用します
それにエグゼキュータを渡します
それ以外のコードは変えません
入力データを設定し
いくつかの引数を設定します
.buildを呼び出すと
前の例と同じように
ListenableWorkerの
インスタンスを取得します
startWorkとawaitを呼び出します
全体をrunBlockingのブロックで
囲んでいます
awaitを一時停止するためです

Korean: 
그래서 제 테스트는 쓰기도 쉽고 훌륭해집니다
하지만 가끔 지연이나
제약 조건을 테스트하려고 하며
제약 조건에 변화가 생기면 워커가
어떻게 반응하는지 보고 싶기도 하죠
그런 경우라면 여러분은 테스트 모드에서
WorkManager를 초기화하고 싶을 겁니다
이것도 여러분이 WorkManager를 테스트용으로
초기화하려는 사례에 속합니다
그래서 그 예시를 보겠습니다
제 테스트에는 setUp이 있습니다
테스트 모드에서 WorkManager를
초기화하고 싶다는 구성을 정의합니다
그리고 WorkdManagerTestInItHelper를 호출합니다
그다음에 InitializeWorkManager를 호출하여
컨텍스트와 구성을 부여합니다
이 시점에서 WorkManager는 
테스트를 위해 초기화되어 있을 겁니다
그래서 저는 이제 
제가 일반 애플리케이션처럼
WorkManager.getInstance를 
사용할 수 있습니다
제 테스트는 이런 모양이 되겠죠
먼저 제 워커로 테스트하려는
제약 조건을 생성합니다
그리고 OneTimeWorkRequest의
실제 인스턴스를 생성할 겁니다
OneTimeWorkRequestBuilder를 사용하고
제약 조건을 제시하고
.build를 호출하겠습니다

English: 
So my test became, again, very
elegant and very easy to write.
Sometimes, however, you want
to test delays and constraints.
And you want to test how
your worker is reacting
to changes in constraints.
And in that case, you
want to initialize
WorkManager in test mode.
So that is still
the one use case
where you want to initialize
WorkManager for testing.
So let's look at
an example to that.
So in my test, I have a setup.
So I define the
configuration that I
want to initialize
WorkManager in test mode with.
And I call
WorkManagerTestInitHelper.
And I call initialize
WorkManager,
giving it the context
and the configuration.
At this point, WorkManager
is initialized for testing.
So I can now use
WorkManager.getInstance
like I would in a
normal application.
So this is what my
test would look like.
So I would first
create the constraints
that I want to test
my worker with.
Then I would create a real
instance of One Time Work
Request.
So I would use the
OneTimeWorkRequestBuilder.
And then I supply
the constraints.
And I would call .build.

Indonesian: 
Dan saya memanggil startWork dan await.
Dan semuanya dikelilingi oleh 
pemblokiran runBlocking,
karena await sedang ditangguhkan.
Jadi, pengujian saya menjadi,
sekali lagi, sangat elegan 
dan sangat mudah untuk ditulis.
Meskipun demikian, terkadang Anda ingin
menguji keterlambatan dan batasan.
Dan Anda ingin menguji bagaimana
worker Anda bereaksi
terhadap perubahan batasan.
Dan di kasus ini, Anda
ingin menginisialisasi
WorkManager dalam mode uji.
Jadi, itu masih
satu kasus penggunaan
di mana Anda ingin menginisialisasi
WorkManager untuk pengujian.
Jadi, mari kita lihat
contohnya.
Jadi di pengujian saya, 
saya memiliki penyiapan.
Jadi, saya menetapkan
konfigurasi dari WorkManager
yang ingin saya inisialisasi 
dengan mode uji.
Dan saya panggil
ManagerTestInitHelper.
Dan saya panggil WorkManager,
memberikannya konteks
dan konfigurasi.
Pada titik ini, WorkManager
diinisialisasi untuk pengujian.
Jadi, saya sekarang bisa menggunakan
WorkManager.getInstance
seperti yang saya lakukan 
di aplikasi normal.
Jadi, seperti inilah
pengujian saya nantinya.
Jadi, pertama saya akan
membuat batasan
yang ingin saya uji
dengan worker saya.
Lalu, saya akan buat instance
sebenarnya dari OneTimeWorkRequest
Jadi, saya akan menggunakan
OneTimeWorkRequestBuilder.
Lalu, saya berikan
batasannya.

Spanish: 
Mi prueba es de nuevo
muy elegante y fácil de escribir.
A veces, sin embargo,
quieres retrasar pruebas y restricciones.
Y quieres probar cómo
tu trabajador reacciona
a los cambios de restricciones.
En ese caso, debes inicializar
WorkManager en modo de prueba.
Ese es aún el único caso
en que debes inicializar
WorkManager para prueba.
Veamos un ejemplo de eso.
En mi prueba, tengo una setUp.
Defino la configuración
que quiero
para inicializar WorkManager
en el modo de prueba.
Llamo a WorkManagerTestInitHelper.
Llamo a initializeWorkManager
dándole el contexto
y la configuración.
En este punto, WorkManager
se inicializa para prueba.
Ahora puedo usar
WorkManager.getInstance
como lo haría en una aplicación normal.
Así se vería mi prueba.
Primero crearía las restricciones
con las que quiero probar
a mi trabajador.
Luego crearía una instancia real
de OneTimeWorkRequest.
Entonces usaría
el OneTimeWorkRequestBuilder.
Luego le daría las restricciones.
Y llamaría a .build.

Chinese: 
这样一来 我的测试流程就变得非常轻松简单了
有时 你可能会想测试延迟和约束
测试你的 Worker 在约束条件改变时是如何响应的
在这种情况下 你需要在测试模式下初始化 WorkManager
这个使用案例中 为了测试 你需要初始化 WorkManager
那么我们来看看这方面的例子吧
在我的测试中 我有一个设定
我定义了一个配置 用来在测试模式中初始化 WorkManager
我将其称为 WorkManagerTestInitHelper
然后我调用 initializeWorkManager
为它提供上下文和配置
这时 WorkManager 已经为测试而完成了初始化
于是我就可以像是在一个常规应用中一样
使用 WorkManager.getInstance 了
我的测试看起来会是这个样子
我首先会创建约束条件 用来测试 Worker
然后我会创建出一个关于 OneTimeWorkRequest 的
真实实例
我会使用 OneTimeWorkRequestBuilder
然后提供约束条件
随后我会调用 .build
此时 我拥有一个真实的 OneTimeWorkRequest

Japanese: 
私のテストは非常に洗練された
作成しやすいものになりました
遅延や制約をテストする
必要もあるかもしれません
また制約で変更したことに
ワーカーがどのように反応するかを
テストしたい場合もあるかもしれません
その場合WorkManagerを
テストモードで
初期化する必要があります
これもテスト用にWorkManagerを
初期化するユースケースの１つです
その例を見てみましょう
このテストには
setUpがあります
テストモードでWorkManagerを
初期化する構成を定義します
WorkManagerTestInitHelperを
呼び出します
initializeTestWorkManagerを呼び出します
コンテキストと構成を渡します
この時点でWorkManagerは
テスト用に初期化されます
それで
通常のアプリケーションのように
WorkManager.getInstanceを
使用できるようになりました
私のテストはこのようになります
まずテストするワーカーで使用する
制約を作成します
次に１回限りの作業リクエストの
実際のインスタンスを作成します
OneTimeWorkRequestBuilderを
使用し、制約を指定します
.buildを呼び出します

Portuguese: 
Portanto, meu teste permanece
elegante e fácil de escrever.
Mas, às vezes, queremos testar
atrasos e restrições.
Queremos testar como o worker
reage a alterações nas restrições.
Nesse caso, devemos inicializar
o WorkManager em modo de teste.
Esse é o único caso em que inicializamos
o WorkManager para testes.
Vejamos um exemplo disso.
No meu teste...
Tenho uma estrutura no meu teste.
Defino a configuração que desejo
para a inicialização
do modo teste do WorkManager
e chamo WorkManagerTestInitHelper.
Então, chamo .initializeWorkManager,
dou o contexto e a configuração.
Nesse momento, o WorkManager
está inicializado para testes.
Agora posso usar
WorkManager.getInstance
como o faria em um aplicativo normal.
Meu teste ficaria desse jeito.
Primeiro, eu criaria as restrições
com as quais quero testar meu worker.
Depois, crio uma instância real
de um OneTimeWorkRequest.
E, então, uso o OneTimeWorkRequestBuilder.
Forneço as restrições e chamo .build.

Portuguese: 
Agora, tenho um OneTimeWorkRequest real.
E chamo WorkManager.enqueue.
Como esta é uma instância especial
do WorkManager em modo teste,
este worker não será executado
até as restrições serem satisfeitas.
Por padrão, a instância de teste
do WorkManager
tratará todas as restrições
como não satisfeitas.
Então, precisamos marcar
essas restrições como satisfeitas.
Para fazer isso, precisamos
de uma instância do Test Driver,
que é fornecida
pelo WorkManagerTestInitHelper.
Nesse momento,
você poderá usar o Test Driver.
E você pode definir como satisfeitas
todas as restrições do worker.
Agora, você pode usar
as outras APIs normalmente.
Basta chamar getWorkInfoById
e fornecer request.id.
Assim, você receberá
as informações do trabalho
e poderá garantir que
a solicitação de trabalho foi um sucesso.
Isso é tudo.
Só para concluir, aqui estão
alguns recursos para vocês.
Se precisarem de mais documentação,
visitem developer.android.com/workmanager.
Estes são os artefatos.

English: 
At this point, I have a
real One Time Work Request.
And I call WorkManager.enqueue.
Because this is a special
instance of WorkManager
in test mode, this
worker is actually not
going to run until the
constraints are met.
And by default, the test
WorkManager instance
will treat all
constraints as unmet.
So we have to mark those
constraints as met.
And for that, you
need an instance
of Test Driver, which
WorkManager Test Init
Helper will give you.
At that point, you can
use the Test Driver.
And you can mark all
constraints for the worker
that you just defined as met.
And now you can just use
all the rest of the APIs
like you would normally.
So you can just call
getWorkInfoById,
give it the request.id.
And then you could
get the work info
and then assert that the
state of the work request
was success.
And that's it.
SUMIR KATARIA: And
yeah, just to finish up,
these are some
resources for you.
So if you need to know
any documentation,
we have a lot of it
at developer.androi
d.com/workmanager.
And these are your artifacts.
So the work-runtime, rxjava2,
testing, and GCM artifacts

Spanish: 
En este punto, tengo
un OneTimeWorkRequest real.
Y llamo a WorkManager en cola.
Porque esta es una instancia
especial de WorkManager
en el modo de prueba,
este trabajador
no va a ejecutarse
hasta que se cumplan las restricciones.
De forma predeterminada,
la prueba de instancia de WorkManager
tratará todas las restricciones
como no cumplidas.
Debemos marcar
esas restricciones como cumplidas.
Para eso, necesitas una instancia
de Test Driver, que te dará
WorkManagerTestInitHelper.
En este punto, puedes usar TestDriver.
Puedes marcar
las restricciones para el trabajador
que definiste como cumplidas.
Ahora puedes usar el resto
de las API
como lo haces normalmente.
Puedes solo llamar
a getWorkInfoById,
darle el request.id.
Luego puedes tener
la información del trabajo.
y marcar que el estado
de la solicitud de trabajo fue success.
Y eso es todo.
Y solo para finalizar,
estos son algunos recursos.
Si necesitan conocer
alguna documentación,
tenemos mucha
en developer.android.com/workmanager.
Estos son nuestros artefactos. Encontrarán
work-runtime, rxjava2, testing y gcm.

Korean: 
이 시점에서는 실제
One Time Work Request를 가지며
WorkManager.enqueue를 호출합니다
이것은 테스트 모드의
특별한 WorkManager 인스턴스라서
제약 조건을 충족하기 전까지는 
이 워커를 실행하지 않습니다
그리고 기본적으로 
테스트 WorkManager 인스턴스가
모든 제약 조건을 
충족하지 않은 상태로 처리하겠죠
그래서 제약 조건을 
충족됐다고 표시해야 합니다
그러려면
WorkManagerTestInItHelper가 부여하는
Test Driver의 인스턴스가 필요하죠
그 시점에서 여러분은 
Test Driver를 사용할 수 있고
여러분이 충족함으로 정의한
워커를 위한 모든 제약 조건을
표시할 수 있습니다
그리고 이제 여러분은 평소처럼
다른 모든 API를
사용할 수 있습니다
이제 getWorkInfoByld를 호출하고
여기에 request.id를 줍니다
그리고 작업 요청 상태가
success로 나왔다고
선언합니다
그게 다입니다
이제 마무리하겠습니다
여러분을 위한 리소스가 있습니다
어떤 문서든 확인하고 싶으시면
developer.android.com/workmanager를
찾아주시면 됩니다
그리고 이것은 아티팩트입니다
work-runtime, rxjava2
testing, GCM 아티팩트 등

Chinese: 
然后我调用 WorkManager.enqueue
因为这是测试模式中的 WorkManager 特殊实例
这个工作程序不会真的运行起来 除非约束条件得到满足
在默认状态下 测试 WorkManager 实例
会将所有约束条件视为未满足状态
所以 我们需要把这些约束条件标记为已满足状态
为此 你需要 TestDriver 的实例
而它是可以从 WorkManagerTestInitHelper 那里获取的
这时 你就可以使用 TestDriver
并将你定义过的那个工作程序的所有约束条件标记为已满足
现在 你就可以正常使用其余所有 API 了
只需调用 getWorkInfoById
把 request.id 提供给它
然后你就可以获取 WorkInfo
并断言 WorkRequest 的状态为“成功”
就是这样
最后 我想说的是 这里为大家提供了一些资源
如果大家需要任何文档
可以前往 developer.android.com/workmanager 浏览
大家可以使用这些组件 包括
work-runtime rxjava2 testing gcm 等都在这里

Japanese: 
これで１回限りの
作業リクエストができました
WorkManager.enqueueを
呼び出します
これはテストモードの
WorkManagerの
特別なインスタンスであるため
このワーカーは
制約が満たされるまで
実際には実行されません
デフォルトではテスト
WorkManagerインスタンスは
すべての制約を満たされていない
ものとして扱います
それでこれらの制約を満たされているもの
としてマークする必要があります
そのためにテストドライバの
インスタンスが必要になります
WorkManagerTestInitHelperです
その時点で
テストドライバを使用できます
定義したワーカーのすべての制約を
満たされているものとして
マークできます
これで普段使用しているその他のAPIも
使用できるようになります
getWorkInfoByIdを呼び出して
それにrequest.idを指定できます
workInfoを取得して
作業リクエストの状態が
成功であることをアサートできます
私からは以上です
最後に
いくつかのリソースをお伝えします
ドキュメントが必要な場合
developer.android.com/workmanager
にたくさん用意されています
これらはアーティファクトです
work-runtime rxjava2 
testing GCMといった

Indonesian: 
Dan saya akan memanggil .build.
Pada titik ini, saya memiliki
One Time Work Request yang sebenarnya.
Dan saya memanggil WorkManager.enqueue.
Karena ini adalah instance khusus
dari WorkManager di mode pengujian,
worker ini tidak akan 
berjalan sampai batasannya sesuai.
Dan secara default, 
instance WorkManager uji
akan memperlakukan semua
batasan sebagai tidak sesuai.
Jadi, kita harus menandai
batasan itu sebagai sesuai.
Dan untuk itu, Anda
memerlukan instance Test Driver
yang akan WorkManager Test Init Helper
berikan kepada Anda.
Pada titik itu, Anda bisa
menggunakan Test Driver.
Dan Anda bisa menandai semua
batasan untuk worker
yang baru saja Anda 
tetapkan sebagai sesuai.
Dan sekarang Anda bisa
menggunakan semua API seperti biasa.
Jadi, Anda bisa memanggil
getWorkInfoById,
memberikannya request.id.
Lalu, Anda bisa
mendapatkan info pekerjaan
dan menegaskan bahwa
status permintaan kerja itu berhasil.
Ya, itu saja.
-Dan ya, sebagai penutup,
ini adalah beberapa
referensi untuk Anda.
Jadi, jika Anda perlu mengetahui
dokumentasi apa pun,
kami memiliki banyak dokumentasi 
di developer.android.com/workmanager.
Dan ini adalah artefak Anda.
Jadi, artefak work-runtime, rxjava2,
testing, dan GCM

Korean: 
모두 저기 있습니다
감사합니다
감사합니다
[박수]
[음악 재생 중]

Japanese: 
アーティファクトが揃っています
ありがとうございました
ありがとうございました

Indonesian: 
semua ada di sana.
-Terima kasih.
-Terima kasih.

Portuguese: 
Todos os artefatos work-runtime,
rxjava2, testing e GCM estão aqui.
- Obrigado.
- Obrigado!

Chinese: 
谢谢大家

Spanish: 
Gracias.
Gracias.

English: 
are all there.
And thank you.
RAHUL RAVIKUMAR: Thank you.
[APPLAUSE]
[MUSIC PLAYING]
