https://kotlinlang.org logo
#orbit-mvi
Title
# orbit-mvi
g

Guilherme Delgado

08/12/2021, 8:42 AM
I’ve a question regarding
intent
, I’ll add details in thread:
let’s consider the following code:
Copy 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:
Copy code
intent {
    viewModelScope.launch {
        if (!sessionManager.hasSession()) {
            //val result = ...fetch online operation
            state.copy(hasSession = result)
        }
    }
}
B:
Copy code
viewModelScope.launch {
        if (!sessionManager.hasSession()) {
            //val result = ...fetch online operation
            intent {
                  state.copy(hasSession = result)
            }
        }
    }
My confusion is regarding the
runBlocking
from
intent
:
Copy code
@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()
            }
        }
    }
m

Mikolaj Leszczynski

08/12/2021, 8:57 AM
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:
Copy code
intent {
  if (!sessionManager.hasSession())
    val result = networkCall() // Suspending function running within IO context
    reduce {
      state.copy(hasSession = result)
    }
  }
}
g

Guilherme Delgado

08/12/2021, 8:59 AM
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 🙂
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!
m

Mikolaj Leszczynski

08/12/2021, 9:02 AM
TL;DR don’t do blocking work within
intent
😛
but that advice applies pretty much everywhere not only orbit
👍 2
m

miqbaldc

08/12/2021, 12:09 PM
replied: Did it means we don’t need to use
viewModelScope.launch
anymore even we use
AndroidX ViewModel
? cmiiw
m

Mikolaj Leszczynski

08/12/2021, 12:19 PM
@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
👍 1
g

Guilherme Delgado

08/12/2021, 3:37 PM
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.
1
m

Mikolaj Leszczynski

08/12/2021, 3:58 PM
Yes it is.
👍 2
🙏 1
a

appmattus

08/13/2021, 1:00 PM
@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
👍 2
20 Views