Orbit v4.3.2 is released https://github.com/orbit-mvi/orbit-mvi/releases/tag/4.3.2 This is a minor release with the following features: Features • Initial state can now be omitted when putting the ContainerHost in test mode, in which case the real initial state will be used • Jetpack Compose version updated to 

1.1.0

Fixes • Jetpack Compose collect functions now correctly subscribe only when the lifecycle owner is at least 

STARTED

•

repeatOnSubscription

 used to hang forever in unit tests - now it always executes in a unit test As always, massive thank you to our community for the suggestions, discussions and contribution 🙇 If you’re using Compose, do check it out as it fixes an important issue with Compose extensions! @Rak you might want to take a look at this one for unit test improvements

Hi guys! I’m experiencing a strange behaviour. My container is getting created 2 times and thus the init (

onCreate: ((state: STATE) -> Unit)?

) it’s called 2 times. I’m using jetpack compose: • ActivityA has ViewModelA and everything is ok. • ActivityB has a NavHost with 3 composable (“screens”). When they’re first created I get this 2 time problem, but after that, when I change between them, the container is created only once as expected. For now, this is the best hint I can give you, but I’ll look deeper. Any clue? Thanks for your time.

Hey guys, I've got a question about the internals of Orbit, why is the

intent

function using

runBlocking

? What's the point of using a

CoroutineScope

when creating the

ContainerHost

like so

scope.container(...)

?

Hello! I’ve a question for the authors regarding this:

fun <STATE : Parcelable, SIDE_EFFECT : Any> ViewModel.container(...)

Why forcing 

kotlinx.parcelize.Parcelize

 when we could also use 

kotlinx.serialization.Serializable

 ? 🤔 According to the docs if we want to store something in disk, Serializable would be preferable, where Parcelize would be the choice for IPC situations. SaveStateHandle also supports Serializable What do you think about adding an extension that receives as 

STATE: Serializable

?

Hey guys, using Orbit's testing framework, how can I test this?

containerHost.assert( initialState ) {
    states({ dataFromCache })             // first state
    refreshCache()                        // update cache
    states({ updatedDataFromCache }).     // updated state emitted AFTER cache update
}

For some reason the 1st option fails fails, but if I run the following it passes:

refreshCache() 
containerHost.assert( initialState ) {
    states({ dataFromCache }, { updatedDataFromCache })
}

However, the 2nd option doesn't guarantee that the second state was only emitted after the

refreshCache()

function was called. It feels like there's no way to assert the timing at which new states are emitted using the

states

function. Any idea?

Hello @Mikolaj Leszczynski @appmattus! Do you think it would be useful to have

ContainerHostExtensions.kt

using

state: Lifecycle.State = Lifecycle.State.STARTED

as a parameter? 🤔 This way if for some reason we need to change it, we could.

Hey guys, I'm trying to understand the difference between

test()

and

liveTest()

From what I understand,

liveTest()

creates a real container host whereas

test()

creates a "fake" one. The

test()

function has an

isolateFlow

boolean, if set to

true

(default value) then it will only test 1 intent. If an intent is fired inside another intent, the 2nd intent won't run.

containerHost.testIntent {
    change1()
    change2()
}
containerHost.assert(initialState) {
    states(
        {
            copy(...)
        },
        {
            copy(...)
        }
    )
}

If I run it with

test(isolateFlow = true)

or with

liveTest()

I get the same error "expected states but never received" But when I run it with

test(isolateFlow = false)

then my test passes Shouldn't be the opposite? Shouldn't

liveTest()

behave like

test(isolateFlow = false)

?

Hi, is the general consensus that sharing viewmodels across screens is bad? Its better to have unique viewmodels with their own state/side effect class?

Hi all, could use help setting up Orbit MVI on KMM. • orbit-sample-posts-multiplatform project doesn't seem to build for iOS off the bat. ◦

unable to open file (in target "iosApp" in project "iosApp")

• When following sample project & adding to Podfile : ◦

pod 'sharedOrbitSwift', :path => '../shared'

◦ In running

pod install

get: ▪︎

No podspec found for "sharedOrbitSwift" in "../shared"

• orbit-swift-gradle-plugin, What's it for? Is it necessary to run Orbit MVI in KMM? Readme doesn't say much. • Here's my sample project. I'm a big Orbit fan(placed you guys on various awesome-lists 😄). I promise to write up adequate documentation covering KMM setup once we figure this out. (I'm counting on you guys sticking around.) (See my sample project Readme as reference) Thanks!

Any suggestions/ideas to fetch paginations list until it becames empty in one

intent

? Our attempts in 🧵

Hi, I came across this talk, where the guy is criticising MVI. I’m struggling to understand his objections, do you know what he means?

Hi, is it necessary to have atleast 1 state for a viewmodel?

My tests are failing due to different object instances even though the side effects are same.

Expected :
[LoadingSideEffects$NavigateToLandingPage@4bc90c14]
Actual   :
[LoadingSideEffects$NavigateToLandingPage@46a28b7f]

My side effect -:

class NavigateToLandingPage(val id:String) : LoadingSideEffects()

However when I try the same on side effects with no parameters, then the tests are passing e.g

object NavigateToLandingPage : LoadingSideEffects()

The latter will pass, however the former will fail. For assertion, I am using

viewModel.assert(initialState = initialState) {
    postedSideEffects(
        LoadingSideEffects.NavigateToLandingPage(scheduleId)
    )
}

This fails. If I use,

val result = viewmodel.testIntent {
    fetchStatus(id)
}

assert(result.sideEffectObserver.values.first() is LoadingSideEffects.NavigateToLandingPage)

This passes Is this (result.sideEffectObserver.values.first()) the right way to test? And does it mean that we cannot use the format.

viewModel.assert(initialState = initialState) { }

when our side effect accepts some values/parameters?

Hey guys, the context: we want to process user input from the TextField (Compose) through the state – so

onValueChange

triggers

intent

and

reduce

that creates a new state which is propagated into this TextField as a

value

; the problem: orbit seems to be too slow to reduce the text into new state object if the user taps quickly - text field shows funny text. Has anyone faced with this problem? What is your solution? Currently we gave up idea to hold the TextField text in the state of container and keep it in the Composable’s remeberSaveable

Hi guys, Just a curiosity for the authors. Regarding your KMM implementation, have you looked into https://github.com/rickclephas/KMP-NativeCoroutines or you don’t want this kind of dependency in your framework? I’m doing some tests by managing it by myself and now I’m trying the same but using KMP-NativeCoroutines. What are your thoughts about it? Thanks!

Hi, if i did want to write activity/fragment tests, whats the best way? Mock the viewmodel and what it exposes or directly call the render/sideeffect methods or something else?

Anyone running into something similar? KMM - kotlin.native.concurrent.InvalidMutabilityException

@Mikolaj Leszczynski here’s a working sample with my state persistence approach: https://github.com/GuilhE/Expressus

it’s also the playground for my latest story: https://guidelgado.medium.com/kotlin-multiplatform-mobile-sharing-the-ui-state-management-a67bd9a49882

it's nice to see googles samples finally moving in this direction! the thing i found interesting though is the inconsistencies between the different public functions... as an example looking at AddEditTaskViewModel, whether its the positioning of viewModelScope.launch or the state.update calls. don't get me wrong, the codes not incorrect, but it does tend to look messier. its one of the reasons we were strict with our API, forcing you to wrap your public functions in intent blocks - non-blocking by default, as well reduce only being accessibly internally

https://medium.com/androiddevelopers/viewmodel-one-off-event-antipatterns-16a1da869b95 any thoughts on this as I’m using

SideEffect

pattern from

orbit-mvi

Hi guys! I know you must be busy and with other priorities at hand, but do you have any idea when will you have spare time to look into this PR? Thanks 🙂

👀 https://twitter.com/Zhuinden/status/1547119623732174849?s=20&t=CR9hhgIGKkaNsqwwXB2iCg

https://github.com/orbit-mvi/orbit-mvi/issues/128 any suggestions for this issue

Hello guys! @appmattus @Mikolaj Leszczynski any ETA for the swif-gradle-plugin to be updated (it’s on pause since kotlin 1.5.X)? It would be awesome to have it working and I believe it would push forward Orbit-Mvi adoption. I can try to help, just point me towards the problem 😉 Thanks 🙏

Whenever I’m changing list present in state below crash happening, It is intermittent and happens when i scroll the lazyverticalgrid very fast. Compose version -

1.2.0-beta02

https://github.com/freeletics/FlowRedux the MVI authors @Hannes along with @Gabriel Ittner wrote a State Machine MVI library, any though on this? *I just got this from Android Weekly newsletter

Is there any alternative to calls

async {

builder inside

intent {

? Code in 🧵

After what feels like ages fighting our release pipeline, Orbit

4.4.0

has been released! This release focuses on unit testing fixes and improvements. https://github.com/orbit-mvi/orbit-mvi/releases/tag/4.4.0