Event destination state should be state dependent

[kurige]

As I understand it, events in TransitionKit can only have a single destination state. This is a result of the set of valid event transitions being state-independent, rather than a function of the current state.

As an example, here's the state machine from the README:

All of the events have a single destination state, regardless of the current state. So, the following state machine is currently impossible to model:

Well, not impossible. You can create two "View Message" events, two "Mark as Unread" events, and two "Delete Message" events... And then fire the correct one in a if/else if block by checking the current state. But that quickly becomes unwieldy in a larger state machine.

• Is my understanding correct that this is a limitation of the current API?
• Is this something that you would be willing to accept a pull request for, or is this part of the design that you wouldn't be open to changing?
• If you are open to a pull request, how open are you to API changes? The API will have to change, but hopefully not too much. Something along the lines of:

TKState *S1 = [TKState stateWithName:@"S1"];
TKState *S2 = [TKState stateWithName:@"S2"];
TKState *S3 = [TKState stateWithName:@"S3"];

// Simple transition
TKEvent *simple = [TKEvent eventWithName:@"Simple Event" transitioningFromStates:@[S1, S2] toState:S3];

// Add more transitions to existing event
[simple addTransitionFromStates:@[S3] toState:S1];

// Or add them all at once
TKEvent *complex = [TKEvent eventWithName:@"Complex Event" transitions:@{ @[S1, S2]: S3, @[S3]: S1 }];

[egokt]

+1

I like this pod, but our team also pointed out the shortcoming @kurige mentioned. I also agree with him that it can be added in a clean way.

@kurige, please do let me know if you already have a fork with the implementation. I might be interested.

[sachams]

+1 too.

I'm modelling device registration and unregistration, and i'd like to be able to send a single NetworkUp signal to the SM. If the SM is in the WaitingForNetworkWhileRegistering state it would proceed to Registering, and if it is in the WaitingForNetworkWhileUnregistering state it would proceed to Unregistering. At the moment I have to implement by sending two signals - NetworkUpWhileRegistering and NetworkUpWhileUnregistering which doesn't feel right - the external source of network availability shouldn't have to know about the internal state of the SM - it just wants to tell it that the network is up or down.

@kurige, I too would be interested if you currently have a fork with implementation.

[pilot34]

+1

I found such functionality in https://github.com/luisobo/StateMachine

[blakewatters]

PR is worth a thousand +1’s

[egokt]

@blakewatters: I agree with "PR is worth a thousand +1s" :)

We have been able to navigate around any need for this feature, for now. But I suspect we will need this for a cleaner implementation. I'm willing to implement a solution when that time comes.

[jakobsa]

+1