Compose API: no public way to know when a state machine finishes

[oblakr24]

Submission checklist

• I have confirmed the issue is present in the latest version of rive-android
• I have searched the documentation and forums and could not find an answer
• I have searched existing issues and this is not a duplicate

Description

We show short Rive animations as TV overlays. When the animation finishes,
we remove the overlay from the screen. To know when it finishes, we need a
signal from the runtime.

What we did on 11.7.1

We collected RiveWorker.settledFlow and waited for our state machine's
handle. When it settled after our trigger fired, we removed the overlay.

What changed in 11.8.0

settledFlow is gone. The replacement, StateMachine.settled: StateFlow<Boolean>, is internal. So there is now no public way to know
that a state machine has finished.

We also can't use Rive events for this: our files fire an "eventDone" event,
but the Compose API has no way to listen to events (the legacy
RiveFileController.addEventListener does, but we migrated off the legacy
view).

Ask

One of these would unblock us:

1. Make StateMachine.settled public. The docs on it are already written,
   and Rive() and RiveCanvasSession both use it internally.
2. Or expose state machine events (like eventDone) in the Compose API,
   like the legacy listener API does.

We would rather not call the internal member through
@Suppress("INVISIBLE_MEMBER") or a Java bridge, so an official API would
be great.

Previous working version

11.7.1,

Reproduction steps / code

No response

Upload your reproduction files / stack trace

No response

Source .riv / .rev file

No response

Screenshots / video

No response

Rive Android runtime version

11.8.0

Rive API

Compose

Device

Any

Device OS

Any

App minimum SDK level

21

App target SDK level

36

App NDK level

No response

Other Rive runtimes affected

No response

Dependencies with native libraries

No response

Additional context

No response

[ErikUggeldahl]

Hi @oblakr24, thanks for the report. Making it internal was indeed intentional. State machine settling is an implementation detail that should never have been made public - it's an optimization to minimize CPU use when nothing would change. It should not be used as you're suggesting to determine when a state machine has "finished".

In fact, arguably a state machine never exactly finishes, at least from a runtime's point of view, though you may end in a terminal state, which is an editor side consideration.

If you as a developer need to know when you've reached a terminal state, that is the role of data binding, likely a trigger. You would fire that trigger from the editor when you reach that terminal state (or any other state that should dismiss Rive) and listen for that trigger in Kotlin just as you did the settled state previously.

Apologies for having made the previous settled state public incorrectly, but this is the correct long term solution for this use case. The legacy listener interface is also not being considered, as that was created before data binding existed, and it is no longer necessary now that that more flexible system has taken its place.

I'm closing this issue based on this response, but please let me know if you have any follow-up questions.