0
votes

I'm building a finite state machine in Kotlin to handle BLE state management. I know Tinder has a DSL library for FSM but I'm looking to write something on my own.

Here's what I have so far.

FSM's state and actions are represented using sealed classes. For example, a BLE device can be in Connected or Disconnected state - each of which in turn would have sub-states (a Connected state could mean it's in one of ReadingCharacteristic, WritingCharacteristic, SubscribingToCharacteristic or simply Idle)

sealed class BleState {
    sealed class Connected : BleState() {
        object Idle : Connected()
        object ReadingCharacteristic : Connected()
        object WritingCharacteristic : Connected()
        object SubscribingToCharacteristic : Connected()
    }
    object Error: BleState()
}

The actions are also represented using sealed classes.

sealed class BleOperation {
    data class Connect(val bleDevice: BleDevice) : BleOperation()
    object ConnectionCompleted : BleOperation()
    .
    .
    data class Disconnect(val bleDevice: BleDevice) : BleOperation()
    object ErrorOccurred : BleOperation()
}

What I need is a way to represent the transitions. Should this be something like a table/2-D array? Should this be a map of <State, List(Events)> where each state would list all possible events that it can accept? Or do I model Transition as a class with properties like currentState, action & newState? I need to be able to ensure that the transitions are valid.

1
I have been able to successfully handle BLE events with XState in the browser (thinking about extending my SDK up to Node.js). @nsk's answer seems very appealing to me because I try to port the same concepts and align the teams (mobile, web app, edge computing) on a single Model (Actor based / Hiererchical State Machines) ... How are your progresses on this ? - Alan Hortz

1 Answers

0
votes

I don`t think that Tinder library will completely fit your needs. BLE api is rather complicated, so I suppose that you may need nested and parallel states support.

I think that OOP way is that state should have a list/set of its transitions. And transition parameters are:

  • event that triggers this transition;
  • mandatory source state;
  • optional target state or a function which may calculate it.

You can take a look at my library source code: https://github.com/nsk90/kstatemachine