Think about saving/restoring machine in (JSON) for example

[nsk90]

trafficstars

[erdo]

When you get around to taking a look at this, I have some code that could be useful https://github.com/erdo/persista, it will store/read any class that has a kotlin serializer (stored as a JSON text fille). If you think it might be useful, feel free to copy-paste the class / maybe remove its external dependencies, whatever suits you. kstatemachine looks very nice 👍

Edit:adding link to class: https://github.com/erdo/persista/blob/main/persista-lib/src/main/java/co/early/persista/PerSista.kt

[nsk90]

@erdo Hi! Thank you, I really appreciate your help. I will take a look at your code.

Do you need this feature in a kstatemachine?

[erdo]

No not urgently. I have just been thinking about using a state machine to implement navigation on android apps since forever - I think kstatemachine could probably drive something like that

[nsk90]

Ok. In case of UI navigation, to support "navigateUp()" actions, some kind of memory for state machine must be implemented. Currently kstatemachine lacks such functionality.

[SPC-code]

I found out, that I need to save current machine state in DB and there is no obvious way to do so. One of the problems is that I can't use kotlinx-serialization with states because they are not serializable. The obvious way is to add kotlinx-serialization and make states serializable. It would solve the problem.

[nsk90]

currently there is no builtin solution in the library. But you should be able to serrialize your states using kotlinx-serialization if you provide seriazilers for them. I suppose it can be implemented like a new kind of visitor to walk through kstatemachine state/transition hierarchy (like pluntUml export)

[SPC-code]

Right now implementing external serializers is bothersome because you need to implement exhaustive search for appropriate type in KSerializer. I do not think it is possible to implement serializer only to the DefaultState. You need to implement it for all of your states. It requires the same effort to do a DTO for the state. I think marking the stat implementation as @Serializeable should be enough to mark DefaultState as serializeable.

[nsk90]

Is it really necessary to serialize states themselves?

looks there are at least 2 serialization use cases:

1. you have host1 which creates StateMachine structure serializes it into bytes and sends to some other host2 which does not know the StateMachine structure and have to restore it using serialized data, then use this dynamically created StateMachine.
2. you have some code that creates StateMachine structure and at some point in time you need to serialize its current active configuration to be able to restore them later. This is different as you dont need to serialize states or transitions. You need to save just active configuration and be able to start StateMachine from it.

Which one is yours, or maybe you need something different?

[SPC-code]

I have the state machine that represents the state of some process. I need two things:

• Save it to a DB in order to recover it in case of failure.
• Send it to the client to notify that the state is changed.

The first one is probably not critical, because I need a DAO anyway. But requiring a DTO mirroring the state is bothersome.

[nsk90]

Event recording implemented in https://github.com/KStateMachine/kstatemachine/releases/tag/v0.30.0 version