Hi all, got a question on Kotlin/Coroutine, does v...

# android

[David Ng]

Hi all, got a question on Kotlin/Coroutine, does viewModelScope cancel all child coroutine onCleared()?
Here's my view model (use in Profile Fragment)

class profileViewModel: ViewModel() {
    val profileRepository: ProfileRepository
    fun subscribeToProfile(id: Int) {
        viewModelScope.launch {
            profileRepository.subscribeToProfile(id)
        }
    }
}

My repository class

class ProfileRepository {
    fun subscribeToProfile(id: Int) {
        withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
            .....       // Does this get cancelled onCleared()?
        }
    }
}

It seems to me the function in repository class still running despite I've navigated away from Profile Fragment.
I've tried to debug on the view model and override the onCleared() function and call .cancel()

override fun onCleared() {
    super.onCleared()
    viewModelScope.cancel()
}

I was able to breakpoint in onCleared() and execute the .cancel() but it doesn't cancel the job in repository.
Am I missing any steps here?

[David Ng]

On side note, within the withContext is a flow, the flow is still collecting after the viewModelScope is cancelled. Doing some google search shows I need to explicitly cancel the flow as well?

[gildor]

fun subscribeToProfile(id: Int) {
        withContext(<http://Dispatchers.IO|Dispatchers.IO>) {

it’s invalid code, subscribeToProfile must be suspend to use withContext

[gildor]

shows I need to explicitly cancel the flow as well

What kind flow?

[gildor]

also is operation cancellable or not depends what kind code your wrap, you cannot cancel blocking function

[David Ng]

Yup sorry it was a suspend function, I've cleared out most of the unrelevant stuff

[gildor]

now it depends on what is inside of your with context

[David Ng]

It's calling to a backend api using gRPC, and it returns a flow<UserProfile>() which I store/update my current user profile locally

[gildor]

yes, it should be cancelled, if flow implemented correctly and collection should be stopped

[gildor]

you can try to check it on kotlin playground

[David Ng]

stub.subscribeToUserProfile(request)
    .asFlow()
    .collect { updateUserProfile(it) }

[David Ng]

Haven't play with the playground before, let me give it a go

[David Ng]

Just one thing I'm wondering, do I need to explicitly cancel the flow? Or it's part of the cancellation of the coroutine?

[gildor]

viewModelScope.cancel()

it looks unnecessary, standard built-in view model scope cancelled automatically onCleared

[gildor]

do I need to explicitly cancel the flow

No, collect is cancellable suspend function, flow will be cancelled if collect is cancelled

[gildor]

essentially all suspend functions are cancellable if implemented correctly

[gildor]

https://kotlinlang.slack.com/archives/C0B8M7BUY/p1601551599238100?thread_ts=1601549231.224400&cid=C0B8M7BUY

it’s more interesting how flow created in subscribeToUserProfile is implemented

[David Ng]

That's actually generated by the gRPC protoful file...

[David Ng]

Suspecting it's not implemented properly?

[David Ng]

looks like probably something to do with the generated gRPC client. I've tried

.collect {
    cancel()
}

But it's still collecting

[David Ng]

I'll look into it further, thanks!

[gildor]

Would be nice to see a full example to verify

[David Ng]

Sure,

class profileViewModel: ViewModel() {
    val profileRepository: ProfileRepository
    fun subscribeToProfile(id: Int) {
        viewModelScope.launch {
            profileRepository.subscribeToProfile(id)
        }
    }
}

class ProfileRepository {
    suspend fun subscribeToProfile(id: Int) {
        withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
             val channel = ManagedChannelBuilder.forAddress(serviceUrl, 5001)
                .usePlaintext()
                .build()
             val stub = UserProfileGrpc.newBlockingStub(channel)
             val request = SubscribeUserProfileRequest
                .newBuilder()
                .setId(id)
                .build()
             stub.subscribeToUserProfile(request)
                .asFlow()
                .collect { updateUserProfile(it) }
        }
    }
}

[David Ng]

I'm using dagger-hilt for DI and I made the repository singleton (is this a good design?). Not sure if that makes a difference.

[gildor]

too many implementation-delated things

[gildor]

but in general looks that it should work

[gildor]

Though, withContext(Dispatchers.IO) looks suspicios, it shouldn’t be needed

[David Ng]

My bad, was trying to make sure to include things might be relevant

[David Ng]

Hmm isn't viewModelScope is default to Dispatchers.Default? And it might be executing on the main thread? I thought using withContext(<http://Dispatchers.IO|Dispatchers.IO>) would make sure the following code executes in IO thread instead

[gildor]

viewModelScope is default to Dispatchers.Main, not Default

[David Ng]

Let me give it a shot without the explicit context

[gildor]

no, it shouldn’t change anything

[gildor]

my point is that if this function is not blocking, IO context is not neede

[David Ng]

It is blocking, my UI freezes when I navigate to profile fragment

[gildor]

soo, if it’s blocking, then you cannot cancel it

[gildor]

blocking code is not cancellable

[gildor]

coroutine is cancelled, but there is no way to cancel thread which is blocked

[David Ng]

Hmm are you familiar with gRPC? What should be the setup?

[gildor]

only if blocking call supports thread interruption, but coroutine doesn’t interrupt thread

[David Ng]

I'm doing a server side streaming...

[gildor]

a bit

[gildor]

i would try to understand what is blocking

[David Ng]

Alright at least I learned something!

[gildor]

I believe you problem is `UserProfileGrpc.newBlockingStub

[gildor]

it’s blocking

[David Ng]

Yeah I'm thinking the same, but the documentation says it's for unary and server side streaming calls

[gildor]

you probably need newStub

[David Ng]

I'll give it a shot!

[gildor]

newStub “Creates a new async stub that supports all call types for the service”

[gildor]

as I see subscribeToUserProfile is essentially blocking thread, until stream is cancelled, and asFlow there works just as listener

[David Ng]

Now it requires me to pass in a streamObserver along with the request

[gildor]

right, it asyncronous

[David Ng]

Alright this sounds really the cause of the problem!

[David Ng]

Okay I'll look it up how to do that

[gildor]

I mentioned this problem with blocking calls in one of my first messages %)
https://kotlinlang.slack.com/archives/C0B8M7BUY/p1601551257236700?thread_ts=1601549231.224400&cid=C0B8M7BUY

[David Ng]

Guess I took the easy route doing it on blockingStub

[David Ng]

My apologies, I didn't realized it was actually a blocking call

[David Ng]

Thought it was just the way how gRPC name the client, doesn't have anything to do with actual "blocking"

[David Ng]

And the doco says support server side streaming, thought server side streaming is non-blocking by nature

[gildor]

no, not necessary

[gildor]

it still can block thread where you listen it

[gildor]

it’s just also notify callback about new messages

[David Ng]

Cool cool, thank heaps! I'm learning a lot from you, as you answer my previous question as well!

[David Ng]

I'm still having trouble to make to work correct, could you help me take a look again?

class profileViewModel: ViewModel() {
    val profileRepository: ProfileRepository
    fun subscribeToProfile(id: Int) {
        viewModelScope.launch {
            profileRepository.subscribeToProfile(id)
        }
    }
}

class ProfileRepository {
    suspend fun subscribeToProfile(id: Int) {
        val stub = UserProfileGrpc.newStub(channel)

        // Build request

        stub.subscribeToUserProfile(request, object: StreamObserver<UserProfile> {
            override fun onNext(value: UserProfile?) {
                CoroutineScope(coroutineContext).launch {   // This is correct? updateUserProfile is a suspend fun
                    updateUserProfile(value)
                }
            }
        })
    }
}

I tried CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO>) and it works, but it has the same profile, the updateUserProfile() still get executed when I navigate away from profile fragment

[David Ng]

All good, got it figured out. I need to use UserProfileGrpcKt.UserProfileCoroutineStub which is generated after importing the dependency io.grpc:grpc-kotlin-stub . This comes with build in coroutine support. I've been using the java stub the whole time.

[gildor]

Yep, I remember, there is a new official coroutines support