I have the following code in which I launch a coroutine to handle the retrieving of data and storing them into the local database:
private var lastRequestedPage = 1
private var isRequestInProgress = false
private val viewModelScope = CoroutineScope(viewModelJob + Dispatchers.Main)
// function that is called from several places
private fun requestAndSaveData(){
if(isRequestInProgress) return
isRequestInProgress = true
viewModelScope.launch{
withContext(Dispatchers.IO){
// 2 heavyweight operations here:
// retrieve some data via Retrofit & place it into the local data via Room Persistence Library
}
}
lastRequestedPage++
isRequestInProgress = false
}
Description of the code snippet
The network call and database operation is done based on a boolean value called isRequestInProgress. When that is false, it is set to true, the network & database operations can be started by the coroutine and after that the lastRequestedPage is incremented before we set isRequestInProgress again to false so that the whole process can be started again by the program from any place.
Note that lastRequestedPage is passed to the Retrofit network call function as argument since the web service from which the data comes uses Pagination (for the sake of brevity I left that out).
My question
Can I assume that this logic works with a coroutine like this ? Can I have some bad threading issues with a solution like this ? I am asking because I am new to the concept of coroutines and I was adapting this logic from another project of mine where I used listeners&callbacks with Retrofit to perform asynchronous work(whenever the Retrofit#onResponse method was called I incremented lastRequestedPage variable and set the isRequestInProgress to back to false).
Short answer: No, this won't work. It's incorrect.
When you call viewModelScope.launch { } or for that matter GlobalScope.launch { }, the block inside the launch gets suspended. And the program flow moves on to the next statement.
In your case, viewModelScope.launch { } will suspend the call to withContext(...) and move on to lastRequestedPage++ statement.
It will immediately increment the lastRequestedPage and toggle isRequestInProgress flag before even actually starting the request.
What you want to do is move those statements inside the launch { } block.
This is how the flow works.
Main thread
Suspend the block (launch call)
Proceed forward - Don't care about the suspended block - Make UI changes, etc.
To get a better sense of how it works, try this code.
Log.d("cor", "Hello, world!") // Main thread
GlobalScope.launch {
// Suspend this block. Wait for Main thread to be available
Log.d("cor", "I am inside the launch block") // Main thread
withContext(Dispatchers.IO) {
delay(100L) // IO thread
Log.d("cor", "I am inside the io block") // IO thread
}
Log.d("cor", "IO work is done") // Back to main thread
}
Log.d("cor", "I am outside the launch block") // Main thread
The output is
D/cor: Hello, world!
D/cor: I am outside the launch block
D/cor: I am inside the launch block
D/cor: I am inside the io block
D/cor: IO work is done
Related
Repository implementation where a suspend function of uploading and getting back the urls. the await() function said that it should be "suspend". so i added a Coroutine Scope block . inside the block have added urls to a list. the log statement inside the scope has required downloaded urls in the arraylist . but outside the block the list is empty. how to make the list updated outside the coroutine block and can anyone help me to understand how to work with Coroutine thanks
my code
override suspend fun addProductImagesToFirebaseStorage(
productImages: List<Uri>
): AddProductImagesResponse {
return try {
val downloadUrls = mutableListOf<Uri>()
val tasks = mutableListOf<UploadTask>()
productImages.forEach { downloadUrl ->
val task = categoryImageStorage.reference
.child("Home").child("PP")
.child("images")
.putFile(downloadUrl)
tasks.add(task)
}
Tasks.whenAllSuccess<UploadTask.TaskSnapshot>(tasks).addOnSuccessListener { uploadTask ->
uploadTask.forEach {
// downloadUrls.add(it.storage.downloadUrl.await()) Error: Suspension functions can be called only within coroutine body
CoroutineScope(Dispatchers.Default).launch {
downloadUrls.add(it.storage.downloadUrl.await())
Log.i(TAG,"Inside the block : $downloadUrls")
}
Log.i(TAG,"Outside the block : $downloadUrls")
}
}
Success(downloadUrls)
} catch(e:Exception) {
Failure(e)
}
}
That's because the outside log will be probably executed first, since changing the thread to Dispatchers.DEFAULT takes more time than it takes JVM to execute the next line.
What I'm trying to say is, the coroutine will start, immediately after that, the outside log will print the list(which is empty), then the coroutine job will do it's work on another thread (Dispatchers.DEFAULT), independently of the main program execution flow.
What I would suggest, is to use the MutableLiveData or LiveData so you can observe them to let the main program react when the list gets filled with downloadUrl
Here's more to LiveData and MutableLiveData
As was stated by ndriqa, outside logging happens before the inside logging, since your coroutine will run in parallel and wait for download to complete before logging. During download, your code written outside of coroutine block continues to execute and your downloadUrls remains empty until download completes. Therefore you get empty value in outside log.
Your goal is to make sure that your method addProductImagesToFirebaseStorage return Success() with downloaded value after download completes. Since your method is suspend, it is able to wait for some long operation to complete (in your case download.await()). However, you are calling await() in the listener's method, therefore compiler does not know the context and cannot be sure that it is called from a coroutine or a suspend function.
Just call it like this to ensure that Success will be created with up to date value
val tasks = mutableListOf<UploadTask>()
productImages.forEach { file -> // I renamed downloadUrl to file here to be clearer
val url = categoryImageStorage.reference // I also renamed task to url since the result will be not a task but a downloaded url
.child("Home").child("PP")
.child("images")
.putFile(file)
.await() // wait for it to be put
.storage
.downloadUrl
.await() // wait for it to download
downloadUrls.add(url)
}
I'm reading the article about flows on kotlinlang.org: https://kotlinlang.org/docs/flow.html
They show the next example:
fun simple(): Flow<Int> = flow {
println("Flow started")
for (i in 1..3) {
delay(100)
emit(I)
}
}
fun main() = runBlocking<Unit> {
println("Calling simple function...")
val flow = simple()
println("Calling collect...")
flow.collect { value -> println(value) }
println("Calling collect again...")
flow.collect { value -> println(value) }
}
And they say that the output is:
Calling simple function...
Calling collect...
Flow started
1
2
3
Calling collect again...
Flow started
1
2
3
Therefore, it seems like the UI thread is waiting for the first flow.collect function to finish, before continuing to print "Calling collect again..."
I would expect that while the first flow builder runs, the system will print "Calling collect again...", so the output would be:
Calling simple function...
Calling collect...
Calling collect again...
Flow started
1
2
3
Flow started
1
2
3
What am I missing?
collect is a suspend function. Suspend functions are synchronous in the calling code, so collect is no different than calling forEach on a List, as far as code execution order is concerned.
It's not blocking the calling thread, but it is suspending, which means the code in the coroutine waits for it to return before continuing. This is the primary feature of coroutines--that you can call time-consuming code synchronously without blocking the thread. Under the hood, the suspend function is doing something asynchronously, but to the coroutine that calls it, it is treated as synchronous.
Under the hood, the coroutine dispatcher is breaking up your coroutine into chunks that it passes to the calling thread to run. In between these chunks, where it is suspending, the calling thread is free to do other stuff, so it's not blocked.
My answer here might help with explaining the concept further.
I'm putting together a simple demo app in Kotlin for Android that retrieves the title of a webpage with Jsoup. I'm conducting the network call using Dispatchers.Main as context.
My understanding of coroutines is that if I call launch on the Dispatchers.Main it does run on the main thread, but suspends the execution so as to not block the thread.
My understanding of android.os.NetworkOnMainThreadException is that it exists because network operations are heavy and when run on the main thread will block it.
So my question is, given that a coroutine does not block the thread it is run in, is a NetworkOnMainThreadException really valid? Here is some sample code that throws the given Exception at Jsoup.connect(url).get():
class MainActivity : AppCompatActivity() {
val job = Job()
val mainScope = CoroutineScope(Dispatchers.Main + job)
// called from onCreate()
private fun printTitle() {
mainScope.launch {
val url ="https://kotlinlang.org"
val document = Jsoup.connect(url).get()
Log.d("MainActivity", document.title())
// ... update UI with title
}
}
}
I know I can simply run this using the Dispatchers.IO context and providing this result to the main/UI thread, but that seems to dodge some of the utility of coroutines.
For reference, I'm using Kotlin 1.3.
My understanding of coroutines is that if I call launch on the Dispatchers.Main it does run on the main thread, but suspends the execution so as to not block the thread.
The only points where execution is suspended so as to not block the thread is on methods marked as suspend - i.e., suspending methods.
As Jsoup.connect(url).get() is not a suspending method, it blocks the current thread. As you're using Dispatchers.Main, the current thread is the main thread and your network operation runs directly on the main thread, causing the NetworkOnMainThreadException.
Blocking work like your get() method can be made suspending by wrapping it in withContext(), which is a suspending method and ensures that the Dispatchers.Main is not blocked while the method runs.
mainScope.launch {
val url ="https://kotlinlang.org"
val document = withContext(Dispatchers.IO) {
Jsoup.connect(url).get()
}
Log.d("MainActivity", document.title())
// ... update UI with title
}
Coroutine suspension is not a feature that magically "unblocks" an existing blocking network call. It is strictly a cooperative feature and requires the code to explicitly call suspendCancellableCoroutine. Because you're using some pre-existing blocking IO API, the coroutine blocks its calling thread.
To truly leverage the power of suspendable code you must use a non-blocking IO API, one which lets you make a request and supply a callback the API will call when the result is ready. For example:
NonBlockingHttp.sendRequest("https://example.org/document",
onSuccess = { println("Received document $it") },
onFailure = { Log.e("Failed to fetch the document", it) }
)
With this kind of API no thread will be blocked, whether or not you use coroutines. However, compared to blocking API, its usage is quite unwieldy and messy. This is what coroutines help you with: they allow you to continue writing code in exactly the same shape as if it was blocking, only it's not. To get it, you must first write a suspend fun that translates the API you have into coroutine suspension:
suspend fun fetchDocument(url: String): String = suspendCancellableCoroutine { cont ->
NonBlockingHttp.sendRequest(url,
onSuccess = { cont.resume(it) },
onFailure = { cont.resumeWithException(it) }
)
}
Now your calling code goes back to this:
try {
val document = fetchDocument("https://example.org/document")
println("Received document $document")
} catch (e: Exception) {
Log.e("Failed to fetch the document", e)
}
If, instead, you're fine with keeping your blocking network IO, which means you need a dedicated thread for each concurrent network call, then without coroutines you'd have to use something like an async task, Anko's bg etc. These approaches also require you to supply callbacks, so coroutines can once again help you to keep the natural programming model. The core coroutines library already comes with all the parts you need:
A specialized elastic thread pool that always starts a new thread if all are currently blocked (accessible via Dispatchers.IO)
The withContext primitive, which allows your coroutine to jump from one thread to another and then back
With these tools you can simply write
try {
val document = withContext(Dispatchers.IO) {
JSoup.connect("https://example.org/document").get()
}
println("Received document $it")
} catch (e: Exception) {
Log.e("Failed to fetch the document")
}
When your coroutine arrives at the JSoup call, it will set the UI thread free and execute this line on a thread in the IO thread pool. When it unblocks and gets the result, the coroutine will jump back to the UI thread.
I am learning Kotlin coroutines. I've read that runBlocking is the way to bridge synchronous and asynchronous code. But what is the performance gain if the runBlocking stops the UI thread?
For example, I need to query a database in Android:
val result: Int
get() = runBlocking { queryDatabase().await() }
private fun queryDatabase(): Deferred<Int> {
return async {
var cursor: Cursor? = null
var queryResult: Int = 0
val sqlQuery = "SELECT COUNT(ID) FROM TABLE..."
try {
cursor = getHelper().readableDatabase.query(sqlQuery)
cursor?.moveToFirst()
queryResult = cursor?.getInt(0) ?: 0
} catch (e: Exception) {
Log.e(TAG, e.localizedMessage)
} finally {
cursor?.close()
}
return#async queryResult
}
}
Querying the database would stop the main thread, so it seems that it would take the same amount of time as synchronous code? Please correct me if I am missing something.
runBlocking is the way to bridge synchronous and asynchronous code
I keep bumping into this phrase and it's very misleading.
runBlocking is almost never a tool you use in production. It undoes the asynchronous, non-blocking nature of coroutines. You can use it if you happen to already have some coroutine-based code that you want to use in a context where coroutines provide no value: in blocking calls. One typical use is JUnit testing, where the test method must just sit and wait for the coroutine to complete.
You can also use it while playing around with coroutines, inside your main method.
The misuse of runBlocking has become so widespread that the Kotlin team actually tried to add a fail-fast check which would immediately crash your code if you call it on the UI thread. By the time they did this, it was already breaking so much code that they had to remove it.
Actually you use runBlocking to call suspending functions in "blocking" code that otherwise wouldn't be callable there or in other words: you use it to call suspend functions outside of the coroutine context (in your example the block passed to async is the suspend function). Also (more obvious, as the name itself implies already), the call then is a blocking call. So in your example it is executed as if there wasn't something like async in place. It waits (blocks interruptibly) until everything within the runBlocking-block is finished.
For example assume a function in your library as follows:
suspend fun demo() : Any = TODO()
This method would not be callable from, e.g. main. For such a case you use runBlocking then, e.g.:
fun main(args: Array<String>) {
// demo() // this alone wouldn't compile... Error:() Kotlin: Suspend function 'demo' should be called only from a coroutine or another suspend function
// whereas the following works as intended:
runBlocking {
demo()
} // it also waits until demo()-call is finished which wouldn't happen if you use launch
}
Regarding performance gain: actually your application may rather be more responsive instead of being more performant (sometimes also more performant, e.g. if you have multiple parallel actions instead of several sequential ones). In your example however you already block when you assign the variable, so I would say that your app doesn't get more responsive yet. You may rather want to call your query asynchronously and then update the UI as soon as the response is available. So you basically just omit runBlocking and rather use something like launch. You may also be interested in Guide to UI programming with coroutines.
I feel like i'm missing some crucial part to my understanding to how this code below is working:
private fun retrieveAndStore() {
launch(UI) {
val service = retrofit.create(AWSService::class.java)
val response = service.retrieveData().await()
store(data = response)
}
}
private suspend fun store(data: JsonData) {
val db = Room.databaseBuilder(applicationContext, AppDatabase::class.java, "app-db").build()
db.appDao().insert(storyData)
}
This is the error i get when run:
java.lang.IllegalStateException: Cannot access database on the main thread since it may potentially lock the UI for a long period of time.
I don't understand why the network code via retrofit works but the store function fails. I'm hoping someone can tell me what's going on?
Interestingly if i wrap db call with async {}.await it works, does that mean coroutines can only call other coroutines?
Coroutines aren't about running in either foreground or background. They are about the ability to get suspended, just like a native thread gets suspended by the OS, but on the level where you are in control of that behavior.
When you say launch(UI) { some code }, you tell Kotlin to submit "some code" as a task to the GUI event loop. It will run on the GUI thread until explicitly suspended; the only difference is that it won't run right away so the next line of code below the launch(UI) block will run before it.
The magic part comes around when your "some code" encounters a suspendCoroutine call: this is where its execution stops and you get a continuation object inside the block you pass to suspendCoroutine. You can do with that object whatever you want, typically store it somewhere and then resume it later on.
Often you don't see the suspendCoroutine call because it's inside the implementation of some suspend fun you're calling, but you can freely implement your own.
One such library function is withContext and it's the one you need to solve your problem. It creates another coroutine with the block you pass it, submits that coroutine to some other context you specify (a useful example is CommonPool) and then suspends the current coroutine until that other one completes. This is exactly what you need to turn a blocking call into a suspendable function.
In your case, it would look like this:
private suspend fun store(data: JsonData) = withContext(CommonPool) {
val db = Room.databaseBuilder(applicationContext, AppDatabase::class.java, "app-db").build()
db.appDao().insert(storyData)
}
I'll also add that you're better off creating your own threadpool instead of relying on the system-wide CommonPool. Refer to this thread for details.