MANUEL VIVO: Hi. I'm Manuel Vivo. I'm an Android engineer
in the Developer Relations Team at Google. This video is about an
introduction to coroutines. We will talk about the
problems that coroutines are trying to solve, how to
use coroutines in Android, how to test them, et cetera. The first thing we
want to talk about is, what programs are they
actually trying to solve? They basically simplify
asynchronous programming on Android. So whenever we talk about
asynchronous programming, we cannot forget about
synchronous programming. Here, we have the
function loadData, which is going to
display on the screen the result of a networkRequest. And because this
is synchronous, it means that it will
block the thread where this has been running on. So imagine if we call loadData
from the main UI thread, networkRequest will
block their thread whenever it is waiting for
that networkRequest to happen. And so in this case,
if the operating system is trying to call onDraw,
that is not going to happen. And therefore, the user will
see a frozen UI and unresponsive application. It will get unblocked whenever
the networkRequest finishes and it calls show,
as we can see. Let's see the definition
of networkRequest here. networkRequest is just a
function that returns data. And inside it, we have the
blocking network request code. Blocking the main UI
thread is something that we shouldn't do in Android. So how can we move
this networkRequest to a different thread? How can we make it asynchronous? A solution for this
is using callbacks. We have the same
version of loadData. We're just going to
make the networkRequest on a different thread. Here, as we can see, if
we execute this code, we can see that
networkRequest will be called, and we will see later that
the function networkRequest is going to be moving the
execution of the networkRequest to a different thread. And in this case, the
main UI thread is free, and the operating system
can call onDraw and refresh the screen as much as it wants. Whenever the
networkRequest finishes, it will call this
lambda, a callback, that is going to display the
result of the networkRequest on the screen. If we take a look
at networkRequest, now it's just a function that
doesn't return data anymore. Returns unit. And instead, it takes
in a callback, a lambda that we call in
this case onSuccess, with what to do after the
networkRequest finishes. We can call
DefaultScheduler.execute to move the execution
of the networkRequest to a different thread. And after that
finishes, then we can post to the main thread
calling onSuccess. So while callbacks might be OK
solution for some use cases, it has some problems. First thing is that now this is
a simple function that it just makes another
request and displays something on the screen. But now, the logic
can get complicated. We start adding a
nesting networkRequest after the other one happens. And now we can add more, and
more, and more, and more stuff. This is what becomes
the callback hell-- whenever there is a
lot of indentation, error propagation
might be difficult. You have hard-coded
posting to main thread wherever something happens, and
you might not want to do that. It's complicated. What if we could have
the best of both worlds-- the simplicity of
synchronous code with all the power from
asynchronicity and moving things between threads? And this is where
current things come in. Here, we have the same
function, loadData, written with coroutines. It might look a
little bit suspicious, and you might think it will
block the main UI thread, but it won't. The only difference that we
have is this suspend modifier in the function definition. That's basically telling
the Kotlin compiler that this function needs to be
executed within a coroutine. So how does it work? How can networkRequest not
block the UI thread whenever it moves to a different thread? Well, coroutines can
suspend execution without blocking the thread. And that's going
to happen whenever we move to execute something
to a different thread. So that's what we call
the suspension point. But also, whenever that
networkRequest finishes, then it will resume execution. So whenever the
networkRequest is done with whatever it
has to do, loadData can resume execution and
continuing with the result of that networkRequest. If you take a closer
look, you will see that apart from
networkRequest, the rest of the function
is that what we used to have before as a callback. So what is happening
with the callback? The Kotlin compiler will
write that callback for you under the hood when the
computation can suspend. And actually, coroutines call
those callbacks a continuation. Continuation is just a
generated callback interface with extra information in it. So how is the compiler going to
modify the function loadData? Well, it will take
the suspend modifier and replace it by a parameter
of type continuation. And continuation form
this state machine in which it will be executed
depending if the function is suspended or not. So we can say that when it
starts, the function start, it will start with a state 0. When it will suspend,
it will change state. When it will resume, it will
be back to a different state, and then we will finish. This is what it's called
continuation-passing style. And because it's quite
a complicated topic, it is not going to be
covered in this presentation. But as you can see, just a
fancy way to say callbacks. So with coroutines,
computations can get suspended without blocking
the thread, as we said before. Back to our function
loadData, we're going to see what networkRequest
looks like, in this case. We will see that networkRequest
is another suspend function, but now it returns data as
the synchronous version of it. How can networkRequest
the execution to a different thread? Well, it uses with context. With context is a suspend
function from the coroutines that takes in a
dispatcher as a parameter. Dispatcher is basically
a way to say, hey, I want to run this computation
in this particular thread. And in this case, in IO. And inside with
context, we can have our blocking
networkRequest code. It doesn't matter if it's
blocking the IO thread. What is important
is that it's not blocking the main UI thread. What other dispatchers
do we have available? We have Dispatchers.IO, but also
.Default and Dispatchers.Main. IO is optimized to do network
and disk cooperations. They use default for
CPU-intensive tasks and main for UI code or non-blocking
code that executes quite fast. So here, networkRequest, we
can say that this is main safe. You can call networkRequest
from the main UI thread, and it will be OK,
because it will be in chart to
move the execution to a different thread. So now, we saw what problems
coroutine are trained to solve, which is simply find
asynchronous programming in Android. But what is a coroutine? You can think of a coroutine as
a runnable with super powers. If you do think about it, it is
going to take a block of code, and it will be able to run
it in a particular thread. What I like about coroutines
is that asynchronicity can be expressed in a sequential way. And that's going to be easier
to read and understand. Also, it comes with other perks,
such as exceptional handling and cancellation. That is typically more difficult
to do with other versions-- for example, callbacks. Back to our function loadData. Imagine that we want to
execute that whenever the user taps on a button. For example, we can have
this function onButtonClicked that will trigger loadData. But this is not
going to compile, because suspend functions must
be called inside a coroutine. We don't know how to
create coroutines yet. We will see that later. But in a nutshell, you
can see we can use launch to trigger a coroutine. So imagine that this works. Here, some problems may arise. For example, who can cancel the
execution of that coroutine? Does it follow a
particular lifecycle? For example, if the [INAUDIBLE]
is moving away from the screen, can you automatically cancel it? Who is going to get the
exception if that fails? These are the questions that
a structured concurrency is trying to solve. So structured concurrency
is a design pattern system in coroutines that tries
to solve memory leaks. And structured
concurrency forces you to think about
those questions whenever you are
working with coroutines. And it does it by introducing
this new concept, which is a scope-- a coroutine scope. Coroutine scope is going to
keep track of the coroutines it creates. It's going to give you the
ability to cancel them. And it's going to be notified
whenever a failure happens. So now, back to our
function onButtonClicked, that will actually give
another compiler error. That's because launch must
be called within a scope. How can we create
a coroutine scope? A scope is just a simple
variable that is really [INAUDIBLE] to credit. It is not going to hold
references to heavy objects. So whenever you want to control
the lifecycle of a coroutine, you can create a
coroutine scope. So in this case, we
can use this scope to trigger the computation. And that computation
will follow, that coroutine will
follow the lifecycle of that particular scope. So in this case, if loadData
throws an exception, the scope will
get that exception and will handle it in some way. Coroutines also
create this hierarchy in which the root of
the hierarchy, it's going to be the
scope, which is going to be the parent of the other
coroutines that it creates. So in this case, for
example, whenever we don't need the scope anymore-- for example, if we are
in a view model, whenever we call onCleared, we
can call a scope.cancel. And cancelling a scope means
that it will counsel all the children coroutines
that it started, and it means as well that you
cannot start more coroutines with that scope. So with our function
loadData, we can see that this suspend
function, because this will suspend, means that it has
to be run inside a coroutine. It will run in a scope. And this is quite important. If we take a step back and we
think about synchronous code again, we can see that
when a function returns, it means that it has
completed all work. So imagine about the
synchronous version of loadData. Even it block the
thread, it's OK, but it returned
whenever it completed everything it had to do. With coroutines, it's
kind of the same. When a suspend
function returns, means that it has completed all work. And this is a very
nice contract to have in asynchronous operations. So now we're going to see
how to handle exceptions. Scopes can also take a job. And a job is going to define the
lifecycle of either the scope, and also the coroutines. And whenever we passing
a job to a scope, that means that it's
going to handle exceptions in a particular way. When a child fails, it is going
to provide the cancellation to other children. And when a failure is
notified, the scope is going to cancel himself and
propagate the exception up. That means that in this case,
whenever loadData fails, it will notify the
scope that it failed. The scope will cancel
the other children that it may have created
before it will cancel itself and will propagate
the exception up. In this case, because
we are in a view model and there is nothing
else in the hierarchy, it will make your
application crash. But this might not be
desired in every situation. For example, here we are
in a UI-related scope, and therefore, we might
not want that behavior. So you can use the alternative,
which is SupervisorJob. And with a SupervisorJob,
the failure of a child, it is not going to
affect other children. And so when a
failure is notified, the scope is not
going to do anything. So in this case, loadData,
if it throws an exception, the scope will say, OK,
I have these exceptions, but it's not going to
cancel other children. But FYI, the exception
can be propagated still, so you might have
to try catch it. TL;DR for a structured
concurrency. When I suspend
function returns, it means that it has
completed all work. When the scope is canceled,
it means that the children will be canceled too. When the coroutine errors out,
the scope will get notified, and depending on
the job, it will behave in a way or another. We're going to see how
to create coroutines now. Before, we saw that we
can use launch to do that, but it is not the only
way you can do it. You have to launch
and async as well. We are going to compare
them with the similarities and differences between these
two different approaches. As I said, the first
similarity is that they can create a new coroutine. They can start a
computation where you can call suspend functions. But they create coroutines
with a different purpose. So launch is going to create
a coroutine that is meant to be fired and forgotten. So imagine that we have
our loggingService where we can upload logs that
happened in our application. So we can use this scope.launch
to trigger that computation, and that's it. We don't care about it anymore. That's launch. Async is going to create
a new coroutine that can return a value. So for example, we have
this function, getUser, that takes in a user
ID as a parameter, and it returns a user object. Because we are in
a suspend function, we don't have a scope
available, so if we want to create a coroutine,
we can use coroutine scope. And inside here, we can fetch
our user with our user service. And that computation can be
happening in Dispatchers.IO, for example. So we have that. And that is going
to-- async is going to return a deferred object. And you can think of a
deferred object as a future or a promise in Java. And with that future,
or that deferred object, you can call await. And await will wait-- actually, it will suspend
execution of the coroutine until async has finished
doing its computation, and it will return the
value of that coroutine. And this is what we
return back to getUser. Another similarity, as you
saw, is that both of them take a dispatcher. Where do you want to
run that computation? Also, both of them are
executed in a scope. Launch and async are extension
functions on the scope. On coroutine scope,
in this case. And so in order to create
[INAUDIBLE],, you need a scope. They are not a
suspend functions, so launch and async are the
entry point to coroutines. How you can create
a coroutine so that you can call suspend
functions, but they are not suspend functions. And they differ on the way
they handle exceptions. So launch is going to
throw the exception as soon as it
happens, and async is going to hold on that
exception until you call await. We're going to see more
of that in a second. So how are you going to
handle those exceptions? Basically with a try-catch. Here in our version
of launch we had before, because loggingService
can throw an exception, you can grab it
inside a try-catch, and that will handle the
exception thrown by the logging service. With async, it's
a bit different. As we said, async is not
going to throw the exception. Therefore, you don't need to
grab it inside the try-catch. You have to do it with await. Await can throw the
exception that happened in the async block of code. Therefore, you have to
wrap it inside try-catch. And there you will
handle that exception. Now we are going to move
on to a different topic. I have this coroutine
on the screen that is called with
launch, and it's going to happen in an IO thread. So we have a for
loop, which is going to read files from a list. What happens if we
call scope.cancel? Is that going to cancel the
execution of that coroutine or not? Well, the fact it is
not going to do that, because cancellation
requires cooperation. Whenever you are doing something
very expensive-- in this case, we can spend a lot of
time reading the files-- you have to cooperate and
make this canceller work. If you think about it, the
coroutines or the thread is going to be really
busy reading files, and it is not going to be
listening for cancellation. So in this case, you have
to cooperate and check if the coroutine
is active or not. And you can do that by checking,
for example, or calling ensureActive or yield. Whenever the coroutine is
cancelled and that function is called, then it will stop the
execution of this coroutine. So again, if you are
doing a heavy computation, make sure that you
check for cancellation. We created a lot of functions
throughout the presentation. And some of them were
marked with suspend, some others weren't. When do you actually have to
mark something as suspend? Well, this is easy. Whenever it calls other
suspend functions. So imagine our loadData
function we had before. It is a suspend function. Why is that a suspend function? Because it calls networkRequest. That is also a suspend function. Why is networkRequest
a suspend function? Well, because it
called with context. And with context, it
is a suspend function that comes from the
coroutines library. This is the reason why. But now, when don't you have
to mark it as a suspend? Well, whenever it doesn't
call other suspend functions. So onButtonClicked
is just a function that triggers the coroutine. It calls launch. And because a launch is
not as a suspend function, onButtonClicked doesn't
need to be either. So the tip is don't
mark a function suspend unless you are forced to. And in this case, you
either mark it as a suspend or you start the coroutine, as
we did with onButtonClicked. We're going to see how
to test coroutines now. So testing asynchronous
code is quite difficult, because you want a
deterministic behavior. You want the test to behave
always in the same way. And we're going to
see different use cases for the different ways
that you have to do that. The first use case,
for those tests that don't trigger the
execution of a new coroutine. So for example, let's say
we want to test loadData. loadData, it is not
calling async or launch. It's a suspend function. It's not triggering
new coroutines. Even though it is moving to a
different thread with context-- that is what
networkRequest is doing-- it is not creating a new
coroutine, so we are OK here. This is the first use case. You can test these
using runBlocking. runBlocking is a method from
the coroutines library that is going to start a
coroutine, and it's going to block the
thread where it's been called until
everything finishes, until the block
of code finishes. So in this case, we can create
a viewModel instance called loadData, and loadData is going
to be executed synchronously. And so we can make sure that
the next line after loadData means that loadData has
finished doing everything. So now we can assert
that show did something. That was quite easy, right? The second use case
is more complicated, and it's for tests that
trigger new coroutines. So for example, we
have MyViewModel, and we want to test
onButtonClicked. onButtonClicked is
triggering a new computation, is triggering a new
coroutine calling launch. Can we use the same way as
we did before runBlocking? Well, if we think
about it, whenever you call onButtonClicked, it is
going to run a new coroutine. And that coroutine might
be potentially running on a different thread. And so it is going to
happen asynchronously. So onButtonClicked is
going to call launch, and it's going to move on. It's going to end the function. So whenever you call
assert, it might be happening that the other
coroutine is still running. Therefore, it's not reliable. You cannot use it. Another way is waiting
for something to happen. So imagine that you update
some result somehow, and you wait for that
to have a new value. Either having a CountDownLatch,
or using LiveDataTestUtil if you're using live data,
or with Mockito await. You have different ways to
wait for something to be there. But that's a code smell. That's because the test is
not going to be running fast. Might take a couple of seconds
for something to be there. And that's kind
of a bad practice. The thing is that you might have
to run it sequentially, as we did before with runBlocking. And how can you do that? Well, basically, we can do
that by forcing the coroutine to run in a
particular dispatcher. And a good practice for this
is injecting dispatchers. So in this case
for the viewModel, you can inject the dispatcher
in the constructor, and then use that dispatcher
to trigger the coroutine inside onButtonClicked. And now we know our tests,
we can use a test coroutine dispatcher. We create this test
coroutine dispatcher instance that we are going to
pass into the viewModel. So that coroutine is going to be
executed in this test coroutine dispatcher. And in the test,
instead of using runBlocking to wrap our
test body within it, we are going to use the
function runBlockingTest from the testDispatcher. That means that every coroutine
running on that dispatcher is going to be executed
simultaneously. In that case, whenever
we call onButtonClicked, it is going to execute that
coroutine simultaneously. That means that whenever
onButtonClicked finishes, means that the coroutine
has finished too. And now you can assert
whenever show did something without having to wait
for that to happen. But now, imagine
that onButtonClicked has to do something else
before running the coroutine. How can we test that? Well, testCoroutineDispatcher
comes with nice functions to be able to post execution of
coroutines, and to resume them. So in this case, we can call
testDispatcher.pauseDispatcher to assert that something
happened before the coroutine, and then call
testDispatcher.resumeDispatcher to test what happened
after the coroutine run. So for testing, use runBlocking
when the test doesn't create new coroutines. And as a good practice,
inject dispatchers and use TestCoroutineDispatcher
in tests whenever you want to test
something that is going to trigger new coroutines. That's going to be
the end of the video. We went through a lot of stuff. So we said what
problems coroutines are trying to solve in
Android, which is simplifying asynchronous programming. How we can move the execution
to a different thread using dispatchers and withContext. What a coroutine is. Basically, you can think
of it as a runnable with super powers. How coroutines work
under the hood. The Kotlin compiler will
rewrite the suspend functions to use callbacks. The principles of
structure concurrency that is going to
avoid memory leaks and is going to force you to
think of who is going to manage the lifecycle of that
coroutine whenever you are working with them. How to create coroutines, and
the differences between launch and async. How to handle exceptions. When to mark a function
as a suspend, or not. And testing coroutines,
and the usage of TestCoroutineDispatcher. If you are interested in
more things about coroutines, I suggest that you go through
the different Codelabs that we have available. We have two of them--
a basic Codelab and advanced Codelab that uses
live data, coroutine builder, and more advanced topics. If you are more interested
in testing coroutines, there is a video at Android
Developer Summit 2019 where I give a talk with [INAUDIBLE]. And now, for cancellation
and exceptions, another video in KotlinConf
2019 with Florina Muntenescu. Thank you for watching. Bye.
