Is it possible to set a new event handler of an

AndroidViewModel

? I’m trying

attachEventHandler()

, but still only the previous handler is called. Background: I’m building with Compose and keep the ViewModel around longer than the screen, and I pass a

SnackbarHostState

to the EventHandler to display snackbars. That also means that I need to regularly update the SnackbarHostState to match the currently used one and thus also the EventHandler.

@Casey Brooks I'm upgrading from v2 to v4 and I used to have an interceptor which used

BallastNotification.ViewModelStarted

to send an initial input to the view model queue. What would the replacement be now that there is no

ViewModelStarted

option. I see

ViewModelStatusChanged

, and I can do

if (it.status == Status.Running)

but I see that

Status.Running

is in an internal package. Is there a better approach now?

@Casey Brooks After the upgrade to 4.0.0, things seem to be mostly working, but I am able to quite easily reproduce a

ClosedSendChannelException

in the browser, after which my VMs stop working. Its not clear from the console log where the exception is coming from. Is it perhaps an incompatibility with Kotlin 1.9.20 -- 4.0.0 appears to be compiled against 1.9.10?

I'm using ballast 4 with 1.9.20 without problems

Using the browser history router, I get a route with

/null

if going back past the top of the back stack

I have an issue with TextFields, namely that text is being added in inconsistent places

Hi, what's the status of wasm support in ballast? I would like to try helping a bit, but I have problems configuring ballast project in my environment. It seems there are some external gradle plugins used in the project.

After a long wait, Ballast 4.1.0 is now released! There are no significant changes in this release and should be backward-compatible with previous versions, but does include a few small additions and bugfixes, along with support for Kotlin 1.9.22. The biggest new feature in Ballast 4.1.0 is the addition of a new Scheduling module, allowing you to send Inputs to your VM at a regular intervals. This can be helpful for regularly refreshing data in a VM, but is also precise enough to be used for applications like a stopwatch. Additionally, these same schedules can also be used to configure Android’s WorkManager (though WorkManager support is still highly experimental)

Hey everyone, I've used the Kotlin Multiplatform Wizard tool to generate a project with shared UI. I've noticed both the general project structure as the

build.gradle.kt

file are a bit different as opposed to prior KMM projects. And now when I try to add the ballast dependencies to my

commonMain.dependencies

definition, the retrieval for the iOS targets fails (in the past, defining an

ios()

was enough, now you need to be more specific e.g.

iosArm64

,

iosX64

, ...). When I move the dependencies to the

androidMain

section however, the retrieval succeeds. Is there something I'm missing in my gradle setup, or does the library need to define new target definitions to support these iOS sub-targets?

Hello @Casey Brooks When we popBack using

Inputs.GoBack()

, data in the previous screen is lost. Like if we had a query parameter in there before and we navigate back to the screen, there’s a null pointer exception that the parameter doesn’t exist Is that intended??

We experimented with making Ballast navigation more type safe using annotation. This is the result. It is experimental but if you are curious here is the source. Using KSP adds additional setup, it’s okay because it’s a one time thing, but we always love minimal configuration.

@Casey Brooks I've successfully tested Ballast 4.2.0 with my Kotlin/Wasm Kilua framework. Thank you for your work! Here is an example app: https://github.com/rjaros/kilua/tree/main/examples/todomvc-ballast

Hey everyone, Ballast now fully supports WasmJS targets since v4.2.1! All modules are supported except for

ballast-debugger-client

, since that depends on Ktor which does not yet have a stable release with WasmJS. The only other notable change in this release is that

ballast-navigation

no longer depends on

ktor-http

, so it should result in a smaller binary for apps not using Ktor HTTP client. It is now using eygraber/uri-kmp for parsing URIs, which should just be an internal change and not require any updates to your codebase. However, there may be some differences in how the two libraries parse URIs, so if you notice any navigation URIs that worked in previous version but seem to not be handled correctly now, please let me know so I can fix it for you.

Hello, I've tried to test new ballast-navigation with KVision, but it doesn't work. The same module is failing now at runtime with an

IllegalStateException

and

initialState required

message.

This class seems to be problematic with 4.2.1: https://github.com/rjaros/kvision/blob/master/kvision-modules/kvision-routing-ballast/src/jsMain/kotlin/io/kvision/routing/Routing.kt

@Casey Brooks do you have any suggestion what could be wrong?

From the stacktrace I see the error is coming from

build()

used in this class: https://github.com/rjaros/kvision/blob/master/kvision-modules/kvision-routing-ballast/src/jsMain/kotlin/io/kvision/routing/KVRouterViewModel.kt#L53

Is it possible to migrate from an Android app and web site in Next.js to KMP and eventually compose mulitplatform step-by-step, or is it a complete rewrite? How would one approach this?

Hello. Why do we have both

send

and

sendAndAwaitCompletion

? Is using the latter somehow less performant?

Hey yall, apologies for the silence since the last release. A combination of a new project at work, a baby due to be born any day, and getting hit with the Houston hurricane has kept me too busy to look into the issues yet. But I finally have some time to investigate them tonight

Hello Casey, I see you’ve closed this issue . Are you open to merging what we’ve done to Ballast? Like an optional feature?

Hey all, I've been using the Ballast MVI library for a while now and I'm a big fan of the general approach. I did notice it could get heavy on the boilerplate-side when creating the mental-model files repeatedly for different features, and I finally took the time to learn how to create an IntelliJ plugin and made one for Ballast as well: https://plugins.jetbrains.com/plugin/25295-ballast-template-files-generator?noRedirect=true https://github.com/sigmadeltasoftware/BallastCompanion It's currently still in review but please feel free to let me know if you have any additional ideas or remarks

Hello. I'm using a custom interceptor and want to send back an Input to the view model. I'm using

sendToQueue(Queued.HandleInput(null, MyContract.MyInput(...)))

. Is this correct? What is the first parameter of

HandleInput

-

val deferred: CompletableDeferred<Unit>?

. Is passing

null

ok?

👋 I am trying out Ballast on an app I'm developing. I'm in a classic situation with frameworks: Ballast feels great for simple scenarios but I'm struggling with the right mental model for more complex scenarios. One such complex scenario is dealing with stateful composables like

BasicTextField()

-- details in 🧵.

Me again! 😁 Ballast Navigation seems nice, but it feels like it is designed for navigation triggered purely by UI actions. In particular, it is unclear what the intended pattern is for when the navigation is triggered in part by other work. For example: • User clicks a button • That triggers some I/O (database, Web service, whatever) • Where we navigate to is determined by the results of that I/O, and we cannot do that navigation until that I/O is done I can see having the UI layer be the bridge code: when the state from the I/O viewmodel says "I/O complete and here are the results", trigger navigation. That feels mildly icky. Is the vision that we graft Ballast Navigation onto an I/O-handling viewmodel, eschewing

withRouter()

and

BasicRouter

and instead building some sort of composite viewmodel? Or, is the vision that the I/O-handling viewmodel hold a reference to the router and tell it to navigate as needed? Or is there something else? Thanks!

Hey @Casey Brooks, I too sometimes encounter issues like these where I for example want to initialise a homepage by loading local objects and multiple remote objects and once 1 of them completes, the other routines get cancelled. When I use FIFO, this problem seems to resolve itself but I'm still left wondering what the "optimal" approach is?

Hey @Casey Brooks (and everyone), Another question in terms of nested navigation. From the reading I’ve done regarding the previous questions it seems the preferred solution is to avoid nested routers which I agree with. The only thing I’m wondering is how this paradigm can best align with Compose. E.g.:

// ... when (screen) { ... 

AppScreen.Account,
AppScreen.AccountViewProfile -> {
  val vm = remember { AccountScreenViewModel(scope) }
  val state by vm.observeStates().collectAsState()
  when (screen) {
    AppScreen.Account -> AccountScreen(state) { vm.trySend(it) }
    AppScreen.AccountViewProfile -> AccountViewProfileScreen(state)
    else -> throw IllegalStateException("Can't have a different screen here for Account")
  }
}

In this example I have a screen called

Account

with a nested screen which shows more of the profile in details. The problem is that I would like to persist (the state of) the ViewModel but as the recomposition happens, Compose creates a new instance of the ViewModel and the state gets cleared. So there are several ways to approach this issue that I thought of: • Create a nested navigation where

Appscreen.Account

is the main entry point and has several

AccountScreen.xxx

destinations with its own router (did a similar thing for

Login

) • Persist the state and recreate when

Account(ViewProfile)

is opened • Move

AccountViewModel

outside of recomposition space (will live in memory with app lifecycle so not ideal) Is there a better approach I’m missing? I’ve also considered the option of using Ballast Sync, but I’ll basically have the same issues here as the Source (

AccountViewModel

) will still be recreated with navigation.

I am attempting to migrate an older project to Ballast. The project used a Jetpack

ViewModel

and does work in

onCleared()

. Two questions: 1.

BasicViewModel

doesn't seem to offer

onCleared()

or an equivalent. How do I know when the viewmodel is going out of scope, so I can do cleanup work there? 2. If I need to stick with Jetpack so I get an

onCleared()

, and so therefore should use Ballast's

AndroidViewModel

... how are we supposed to handle the

CoroutineScope

? We're not supposed to use

viewModelScope

, but it is unclear if we are on our own to

cancel()

some other

CoroutineScope

that we create. Do I just

cancel()

it myself in

onCleared()

? Thanks!

I am running into difficulties using

ballast-test

to test

observeFlows()

. I suspect that I'm just missing where/how to trigger the flow updates. Details in 🧵.

Hi @Casey Brooks, checking out the repo to build it locally seems not to work. It can’t find the gradle convention plugin stuff. Could you give us a quick guide how to PR for ballast, I would have some time and would like to help you out a bit. I also depend on the project going on😁