From the talk I've learned how to use coroutines to reduce double downloading: The worker receives IDs from a ReceiveChannel. It remembers which one were already added. It sends the IDs (after removing the doubles) to a worker pool via a SendChannel. The worker pool requests the object that belongs to each ID and parses the data, then sends it back to the worker using another SendChannel. The worker receives all the objects, waits until everything is here, then ends and returns the final result.

So far I believe I understood most of it.

Also, can do write suspending operators? Like

suspend operator fun get...

I am facing a weird issue while unit testing Coroutines. There are two tests on the class, when run individually, they both pass and when I run the complete test class, one fails with assertion error. I am using

MainCoroutineRule

to use the

TestCoroutineScope

and relying on the latest Coroutine Testing Library Here is the test :

@ExperimentalCoroutinesApi
    @Test
    fun testHomeIsLoadedWithShowsAndFavorites() {
        runBlocking {
            // Stubbing network and repository calls
            whenever(tvMazeApi.getCurrentSchedule("US", currentDate))
                .thenReturn(getFakeEpisodeList())
            whenever(favoriteShowsRepository.allFavoriteShowIds())
                .thenReturn(arrayListOf(1, 2))
        }

        mainCoroutineRule.runBlockingTest {
            // call home viewmodel
            homeViewModel.onScreenCreated()
            // Check if loader is shown
            assertThat(LiveDataTestUtil.getValue(homeViewModel.getHomeViewState())).isEqualTo(Loading)
            // Observe on home view state live data
            val homeViewState = LiveDataTestUtil.getValue(homeViewModel.getHomeViewState())
            // Check for success data
            assertThat(homeViewState is Success).isTrue()
            val homeViewData = (homeViewState as Success).homeViewData
            assertThat(homeViewData.episodes).isNotEmpty()
            // compare the response with fake list
            assertThat(homeViewData.episodes).hasSize(getFakeEpisodeList().size)
            // compare the data and also order
            assertThat(homeViewData.episodes).containsExactlyElementsIn(getFakeEpisodeViewDataList(true)).inOrder()
        }
    }

The other test is almost similar which tests for Shows without favorites. I am trying to test

HomeViewModel

method as:

fun onScreenCreated() {
        homeViewStateLiveData.value = Loading
        val coroutineExceptionHandler = CoroutineExceptionHandler { _, exception ->
            onError(exception)
        }

        viewModelScope.launch(coroutineExceptionHandler) {
            // Get shows from network and favorites from room db on background thread
            val favoriteShowsWithFavorites = withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
                val favoriteShowIds = favoriteShowsRepository.allFavoriteShowIds()
                val episodes = tvMazeApi.getCurrentSchedule(COUNTRY_US, currentDate)
                getShowsWithFavorites(episodes, favoriteShowIds)
            }
            // Return the combined result on main thread
            withContext(Dispatchers.Main) {
                onSuccess(favoriteShowsWithFavorites)
            }
        }
    }

I cannot find the actual cause of why the tests if run separatly are passing and when the complete class is tested, one of them is failing. Pls help if I am missing something

I got this from https://stackoverflow.com/questions/55270732/how-do-i-correctly-launch-kotlin-coroutines-to-implement-a-caffeine-asyncloading and it seems like nobody commented there, but it just doesn't look right...

Or maybe I'm completely going in the wrong direction?

Or maybe each coroutine that does a request should provide the channel over which it should get the reply? Like:

// I want to request ID 12
val results = Channel<Int, Channel<Result>>()
cacheManager.send(12, results)
val result: Result = results.receive()

Maybe this is where Flows would be useful?

I guess it depends on how cheap Channels are, and since they need to handle synchronisation I guess they're not...

This question may have been asked already, but I'm getting a crash when I try to use the

coEvery

method on mockk to to mock out a suspending call. The crash is caused by a

ClassNotFoundException

for kotlinx.coroutines.experimental.BuildersKt Has anyone run into this?

Also, I'm getting a message that

coEvery

is deprecated but I can't find any documentation that says that it's deprecated...

Update: I was using the wrong version of the

mockk

library!

hello guys, what is the proper way of cleanup code after some coroutine work is completed? like rxjava Disposables.fromAction

the example is like this

here, 'finally' won't work, because the code is suspended, and 'finally' happens before the callback

is there any mechanism, besides the 'normal' way of manual cleanup before each resumeXXX call ?

I was wondering, if retrofit uses call.enqueue to forward to continuation callback, which means it actually runs the requests on its executor. Wouldnt it be better to run it manually withContext on IO dispatcher to save threads?

Also, maybe even keep it synchronous since most likely next operations will be database operations, which are meant for io dispatcher anyways, so save anothee thread spawn (I take it that IO is unbounded) / thread switch

Both would be bad choices. OkHttp runs multiple connections from a single thread and only switches to a dedicated thread once the response has had its header processed. If you want to share those dedicated threads, you can create an OkHttp Dispatcher with an

Executor

wrapped around the IO dispatcher. Synchronous calls would be even worse since you entirely defeat HTTP/2's connection multiplexing.

hmm, but when I used rxjava Singles as return type of the calls, it was run and emitted on the caller thread (subscribeOn)

was I dreaming?

only if you used

create()

and not

createAsync()

when creating the adapter

🧵

🚫

well, yes the default setup so

create

, .. so is that still bad because of the multiplexing thing?

Oh, looks like I've seem that before, but can't remember where 🙂 . (source: )

I just spent an hour debugging an ambiguity in

public interface CoroutineScope {
    public val coroutineContext: CoroutineContext
}

vs

public suspend inline val coroutineContext: CoroutineContext

With great power...

The idea here is to get a flow where subscribers are shared. It would also be nice if you were able to share an active flow but when all collectors are gone it cancels the upstream flow (like

replay(1).refCount()

in RxJava)

Good day everyone! My name is Aldo; I’m currently learning about coroutine.

How can I see what happens internally when launching a new coroutine? I can't go further this function

AbstractCoroutine.start

, Where can I go from there? maybe I should check the Kotlin compiler? any starting points?