I’ve a question regarding `intent` , I’ll add details in thread:

# orbit-mvi

[Guilherme Delgado]

I’ve a question regarding intent , I’ll add details in thread:

[Guilherme Delgado]

let’s consider the following code:

override val container = container<LandingState, LandingSideEffect> (LandingState(hasSession = sessionManager.hasSession()), stateHandle) {
    intent {
        //runBlocking
    }
}

If I’m querying async data (network or repo) what’s the right approach?
A:

intent {
    viewModelScope.launch {
        if (!sessionManager.hasSession()) {
            //val result = ...fetch online operation
            state.copy(hasSession = result)
        }
    }
}

B:

viewModelScope.launch {
        if (!sessionManager.hasSession()) {
            //val result = ...fetch online operation
            intent {
                  state.copy(hasSession = result)
            }
        }
    }

My confusion is regarding the runBlocking from intent :

@OrbitDsl
public fun <STATE : Any, SIDE_EFFECT : Any> ContainerHost<STATE, SIDE_EFFECT>.intent(
    registerIdling: Boolean = true,
    transformer: suspend SimpleSyntax<STATE, SIDE_EFFECT>.() -> Unit
): Unit =
    runBlocking {
        container.orbit {
            withIdling(registerIdling) {
                SimpleSyntax(this).transformer()
            }
        }
    }

[Mikolaj Leszczynski]

the answer is neither, you’re reading too much into internal code. intent will launch a new coroutine internally.

You can see real examples in our samples and worth reading through our documentation, but generally something like this will be enough:

intent {
  if (!sessionManager.hasSession())
    val result = networkCall() // Suspending function running within IO context
    reduce {
      state.copy(hasSession = result)
    }
  }
}

[Guilherme Delgado]

yup I’ve read your documentation and saw the Stock List - Jetpack Compose example, but it wasn’t clear for me. Thanks for point out 🙂

[Guilherme Delgado]

Threading guarantees#
• Calls to Container.intent do not block the caller. The operations within are offloaded to an event-loop style background coroutine.`
• Generally it is good practice to make sure long-running operations are done in a switched coroutine context in order not to block the Orbit "event loop".
found it!

[Mikolaj Leszczynski]

TL;DR don’t do blocking work within intent

[Mikolaj Leszczynski]

😛

[Mikolaj Leszczynski]

but that advice applies pretty much everywhere not only orbit

[miqbaldc]

replied: Did it means we don’t need to use viewModelScope.launch anymore even we use AndroidX ViewModel? cmiiw

[Mikolaj Leszczynski]

@miqbaldc was viewModelScope.launch ever something that we recommended? I think it should be avoided because you’re launching a coroutine outside of orbit container’s scope. If you’re thinking about coroutineScope { } then that is only needed for parallel decomposition or if you absolutely need to launch a coroutine within intent

[Guilherme Delgado]

we don’t need to use viewModelScope inside intent, but the container is scoped to ViewModel lifecycle or am I wrong? 🤔

creating containers scoped with ViewModelScope to automatically cancel the Container whenever the ViewModel is cleared.

[Mikolaj Leszczynski]

Yes it is.

[appmattus]

@Guilherme Delgado the posts sample would be a better sample to look at as that makes suspending network requests for its data whereas the stocklist gets all its data from a a streaming api using flows