you should have created #babylonlibraries (like #squarelibraries )

Version

1.2.0

has been released with a minor improvement to the DSL 🙂

Hello everyone! Breaking the ice here with the first question, or more precisely asking for general feedback about how do you usually organize action transformations, and if do you consider scalable an approach like the one below: - Have a

Status<T>

class to be used as the output of any transformation (basically the result type of our use case executions). It can take the values

Status.Failure(e: Throwable

,

Status.Loading

, and

Status.Result(payload: T)

. - Listen to any possible resulting status of a given type and reduce them all together. - If necessary, listen to specific result statuses separately. In the case shown below, side effects are different (

Status.Loading

doesn't have side effects,

Status.Result

posts a side effect,

Status.Failure

has both internal and view related side effects).

👋 Orbit 2.0.0 has been released with many DSL improvements! https://github.com/babylonhealth/orbit-mvi/releases/tag/2.0.0

Hello Orbiters. Quick question. What would be the easy way to achieve retry 3 times for a given network request while showing to the user

First/Second/Third retry attempt

and then either fail or succeed at that point? Thanks

Orbit

3.0.0

has been released! 🎉 https://github.com/babylonhealth/orbit-mvi/releases/tag/3.0.0

@Mikolaj Leszczynski as I understand it, a new Thread/Scheduler is created for every Container https://github.com/babylonhealth/orbit-mvi/blob/e9c071487167ce21114a260514d2482b727be52f/orbit/src/main/java/com/babylon/orbit/BaseOrbitContainer.kt#L133 . shouldn’t the scheduler be shutdown when disposing ?

Hey @Mikolaj Leszczynski. We were talking about this previously, but I am using orbit with rx, and on the transformation, I pass the

eventObservable

and

currentState

to my transformers that I have defined outside (similar to the example). When I pass that

currentState

, I am passing its value on the cretion of the stream so it will always be the initial version of that state. In order to have the latest value of that state, the actual current state, what I did was looping back an object that had the things I needed from the state to make my request. That solves my problem, but I was thinking what other alternatives we have. One would be modifying the stream with a

map

but maybe there is a more obvious one I am missing. Thanks in advance.

Hey, is there any other sample app out there that covers navigation, side effects and chain reactions a little better? I am struggling a bit to piece everything together

Hi @Ravi, this is on our TODO list. See: https://github.com/orbit-mvi/orbit-mvi/issues/8 https://github.com/orbit-mvi/orbit-mvi/issues/10

@Mikolaj Leszczynski can we change the public val stateFlow: Flow<STATE> in Container to public val stateFlow: StateFlow<STATE>. Also while initialzing container in viewmodel we will be setting up initial state. In jetpack compose while consuming this I've to set that initial value again. Please let me know your thoughts on this, I can add the same on github discussion

@Composable
fun SomeCompose(viewModel: SomeViewModel){
    val someState = viewModel.container.stateFlow.collectAsState(initial = initialState)
}

we can get initial state from (Mutable)StateFlow and collectAsState()

Hello. I have a feature request, wanna discuss quickly: what do you think about new property for

Container.Settings

of type

CoroutineExceptionHandler

, so we could have a default exception handler for Android ViewModel?

Hey guys, do you have a date to release a new version with the latest changes?

thanks for the exception handler features guys ❤️ https://github.com/orbit-mvi/orbit-mvi/blob/main/samples/orbit-calculator/src/main[…]lin/org/orbitmvi/orbit/sample/calculator/CalculatorViewModel.kt is it possible to idiomaticly make the exception catch as a flow?

val state = MutableStateFlow(...)

state.map {
  // a reducer
}.catch {
  // catch the exception happened in a reducer
}

suggestion:

reduce { 
   // omitted
}.catch {
   when (exception) {
     // to distinguish between stateA & stateB exception, unless it's a general toast
     ExceptionFromStateA -> state.copy(a = // do something with data specific to stateA)
     ExceptionFromStateB -> state.copy(b = // similar to the above apprach)
   }

   // or a general error message
   state.copy(errorMessage = it.message)
}

Does orbit-mvi also support SingleLiveEvent-like alternative?

unable to find the samples in orbit-mvi though, did I miss something? 🙏

Been reading this article and seems

StateFlow

& Android lifecycle required additional configuration (there’s a new API from google to support this) also there’s an interesting discussion about it in here

Hey guys, hi! I wonder, how do you handle infinite flow subscriptions? Currently, the only way works for me is

flow<Unit> {
            while (true) {
                delay(3000)
                emit(Unit)
            }
        }.flowOn(<http://Dispatchers.IO|Dispatchers.IO>).onEach { _ ->
            intent { reduce { it } }
        }.launchIn(viewModelScope)

Unfortunately

intent

coroutine couldn’t be used for this, as it would block all new messages from the RealContainer’s channel

intent {
            flow<Unit> {
                while (true) {
                    delay(3000)
                    emit(Unit)
                }
            }.flowOn(<http://Dispatchers.IO|Dispatchers.IO>).onEach { _ ->
                intent { reduce { it } }
            }.collect()
        }

Orbit v3.1.1 has been released, containing a hotfix for a bug blocking event loop mechanics. https://github.com/orbit-mvi/orbit-mvi/releases/tag/3.1.1

found this from Luca Nicoletti, the sample shown using orbit earlier version with alpha version of jetpack compose Stocklist, Post &amp; Calculator seems using Views, cmiiw if there’s a sample on v3.1.1 using Jetpack Compose already that I’m not aware of 🙏

Hey guys, I’m kinda dumb, but can’t make it work: how you test the

delay()

if occurs inside the

intent

block? I’ve tried to pass

TestCoroutineDispatcher

as the

orbitDispatcher

and then

advanceTimeBy

but it has no effect and I have to wait for the delay to finish 😞

Hi folks! 👋 In looking at the framework I'm rather impressed & am considering up-taking it for a professional project. I can't help but wonder why BabylonHealth dropped support for the project. I couldn't find an article describing the thought process there. Were there pain-points with the framework in production? Was MVVM found easier to deal with in the long run? etc. Any insights would help with my decision process & sell to management. Thanks!

Does below snippet considered as multiple streams? Also, is it currently possible to do this approach (in snippet)? Detailed in thread~

Orbit MVI 4.0.0 has been released! This release includes big improvements to unit tests that result in breaking changes. Special thanks to @Oleksii Malovanyi for contributing! https://github.com/orbit-mvi/orbit-mvi/releases/tag/4.0.0

Hey guys, me again ¯\_(ツ)_/¯ I’ve been adopting new 4.0.0 test model and found an issue: the

exceptionHandler

is never used so any exception would go to the

TestCoroutineExceptionHandler

which would fail the test afterwards (runBlockingTest is used)

I have another proposal on testing 😬 https://github.com/orbit-mvi/orbit-mvi/pull/52

Unfortunately, I have another change request: it’s about

runOnCreate

in tests -> it blocks, so if you have a delay or withTimeout call right when the container is created, your test would still be live timed 😞 https://github.com/orbit-mvi/orbit-mvi/pull/53

https://github.com/orbit-mvi/orbit-mvi/discussions/57 Curious about the time travel debugging features 🙏

More changes will happen to testing in future? coz recent breaking changes caused a lot of rewrite of Unittest cases for us. Should we stick to the existing test framework or write UTs by asserting stateFlows and sideFlow results using https://github.com/cashapp/turbine.

Hey guys, I’ve found a nasty issue: the neverending flow collection from the

intent{}

– it’s never canceled on parent’s

scope.cancel

in case there is an

exceptionHandler

installed, e.g.: something like this would create a mem. leak:

) : ViewModel(),
    ContainerHost<ProfileState, ProfileEffect> {

    override val container: Container<ProfileState, ProfileEffect> = container(
        initialState = ProfileState(authorized = null, account = null),
        savedStateHandle = savedStateHandle,
        settings = Container.Settings(exceptionHandler = exceptionHandler.asCoroutineExceptionHandler()),
    ) {
        intent {
            subscribeToSessionUseCase().collect {
                reduce { state.copy(authorized = it != null) }
            }
        }
    }

Here is the sneak peak of the fix – I gonna create a test for that, but wonna let you know early https://github.com/orbit-mvi/orbit-mvi/pull/58