Support for Hierarchical State Machine? about swiftstate HOT 9 CLOSED

Hi @Bouke, thanks for your feedback.

Your situation can be solved using condition in addRoute(state:condition:).
To do that, try

machine.addRoute(nil => .StateC, condition: { transition in
    // from anywhere to .StateC at first, but restrict fromState to only A or B, using condition
    return transition.fromState == .StateA || transition.fromState == .StateB
}

For more information, please see blacklisting technique in: StateMachineTests.swift#L116-L129

from swiftstate.

Oops, I forgot the handler part. Please use this instead: addRoute(state:condition:handler).

You can also do like this:

machine.addHandler(nil => .StateC) { context in
    if context.fromState != .StateA || context.fromState != .StateB { return }

    // do whatever handling you want for A => C or B => C only
    ...
}

from swiftstate.

Well that's also what I meant by using the nil state. However, add another 20 states and it becomes very hard to maintain or even grasp the states of the machine by looking at the routes. For example, take the following picture of a HFSM:

source

This state machine allows to go from (Dive | Crouch) => Roll => Crouch. This is a very clear state transition.

Another solution would be to use SFSM (nested FSM), this could be modelled as 4 different state machines:

source

Or the following picture, where an UML state machine is shown. In my example case both A and B would be within s1, and the transition from s1 to s2 would equal the nil => C case in the example.

source

from swiftstate.

Thank you for detailed information!
Your post gave me a good insight 😉

To achieve your (Dive | Crouch) => Roll transition (HFSM),
I added a simple helper in #9 (db73c10) as:

machine.addRoute([.Dive, .Crouch] => .Roll)

Now complex routing becomes more declarative and understandable :)

For nested FSM, please let me take some more time to dig into.

from swiftstate.

Thanks for the changes, that already cleaned up some code. 👍

Being able to also specify handlers that way, would also be great. However these changes somewhat eases the burden on complex state machines; it would still be able to address so-to-speak categories. Like in the example above only define s1 -> s2 transition, without worrying about the sub-states of s1 and s2.

from swiftstate.

I added a HierarchicalStateMachine feature in #10.
Please take a look and tell me your thoughts :)

from swiftstate.

I will merge #10 anyway and close this issue.
If you've got any opinions, feel free to reopen.

from swiftstate.

Sorry, i haven't been able to look at this thoroughly. Good to hear that you'll be merging your solution. However, would it be somehow possible to also create a HSM with static typed states, with enums?

from swiftstate.

In ver 4.0.0, I refactored many codes and now states with enums are supported for hierarchical state machine.
Please see Ver 4.0.0 Release Notes and new HierarchicalMachineTests.swift for more info.

from swiftstate.