This is a BREAKING CHANGE and release candidate for next version 4.0.0, greatly improved typing and RouteMapping support (handling states/events with associated values).

See Also: https://github.com/ReactKit/SwiftState/issues/34

Simple Class Names

I renamed many verbose class names e.g. StateTransition to simple Transition. (Even if the name collides with other frameworks, we can just simply add framework-prefix e.g. SwiftState.Transition to avoid it.)

Better Typing

As requested in https://github.com/ReactKit/SwiftState/issues/34 by @frogcjn, current version 3.x needs to use StateType/EventType which conforms to NilLiteralConvertible to represent .Any state/event, but it was quite ugly because we needed to add extra case Any in their enums.

To alleviate this, I added extra enum wrappers (State<S> & Event<E>) so that users no longer need to implement .Any anymore.

RouteMapping

RouteMapping and StateRouteMapping are new ways of adding routes which has a closure type

public typealias RouteMapping = (event: E?, fromState: S, userInfo: Any?) -> S?
public typealias StateRouteMapping = (fromState: S, userInfo: Any?) -> [S]?

to navigate StateMachine to preferred toState without using traditional arrow style, e.g. fromState => toState. These closures help resolving states & events with associated values.

Please see ~~FrogcjnTest.swift#L124-L180~~ RouteMappingTests.swift#L77-L133 for more details.

Simple Machine class (works like Redux)

StateMachine (which can tryState() as well as tryEvent()) is now a subclass of simpler class Machine which is capable of tryEvent() only. By splitting these codes, along with RouteMapping, Machine will now behave like rackt/redux in JavaScript, a safe state container. For more information on Redux, see http://redux.js.org/ .

Easy Disposable of routes & handlers

There were previously RouteID and HandlerID being passed as return value for asking StateMachine to unregister, but now Disposable (derived from ReactiveCocoa) will take care of it.

Others

• Support watchOS & tvOS.

There is a case that the event has associate values which cannot be enumerated all the possible values, so that it is not possible to add all Event Route into State Machine.

In this case, the only way to do it is to use condition.

But unfortunately, condition only includes transition which has no information about the event.

So I suggest to add Event information into transition.

Why can't I use the event handler by itself without adding a route? Shouldn't this be a design decision up to the client programmer?

machine.addEventHandler(.GotoPreviousCard, handler: { (event, transition, order, userInfo) -> Void in
  println("FeedView ! GotoPreviousCard")
})

Instead, I have to add a route that messes everything up. Sure, I can make it work but it's pretty pointless when I don't want to change states and instead I have code firing twice I would rather not be.

I would like my view to react to events without making state changes. If anything, I would rather filter events for certain states. For example, if someone "likes" a picture, you might send a Like event during the ShowingPhoto state. Your library could make the validation and what not.

In lieu of this functionality, I made transitions with nil => nil

Hi @inamiy, I really like your take on state machines in Swift. I'm now running into an issue in which support for a Hierarchical State Machine would benefit the architectural design. For example, I have three states: A, B and C. A and B are two variants; and it is possible to go from either A or B to C. However, from C it is only possible to go to A. So I would need a handler (A, B) => C and C => A. However SwiftState doesn't allow me to create a handler (A, B) => C, so either I duplicate the handler (no good), or disregard the current state and add nil => C (but that also allows C => C, and a future D => C). As the states grow complexer, this would result in headaches; as adding yet another state would require re-evaluating all the current handlers.

I modified the basic test case as following and it's failing. Any ideas to get rid of ?

    func testREADME_tryEvent()
    {
        var handlerCalled = false
        let machine = StateMachine<MyState, MyEvent>(state: .State0) { machine in

            // add 0 => 1 => 2
            machine.addRoutes(event: .Event0, transitions: [
                .State0 => .State1,
                .State1 => .State2,
            ])
            machine.addHandler(.Any => .Any) { _ in
                handlerCalled = true
            }
        }

        // initial
        XCTAssertEqual(machine.state, MyState.State0)

        // tryEvent
        machine <-! .Event0
        XCTAssertEqual(machine.state, MyState.State1)

        // tryEvent
        machine <-! .Event0
        XCTAssertEqual(machine.state, MyState.State2)

        // tryEvent (fails)
        machine <-! .Event0
        XCTAssertEqual(machine.state, MyState.State2, "Event0 doesn't have 2 => Any")

        XCTAssertTrue(handlerCalled) // Failure
    }

When I try to build the swift/2.0 branch on XCode7, I'm getting nearly a hundred errors about private class names. I think what's happening is that the private type aliases are being misinterpreted by the swift compiler. It's difficult to test this assumption because I'm getting so many build errors that I can't find the root of the type/alias dependencies. Have you seen anything like this?

Hi there! The current swift/3.0 branch doesn't work on projects that target Swift 4.0. This PR is a result of running Xcode 9 migrators, cleaning up new warnings, and fixing making one value public instead of internal.

There's no swift/4.0 branch yet so I had to target swift/3.0. If you create a 4.0 branch I'll change the PR's target.

I've got a question regarding iOS support.

Do you know if SwiftState will work if I include the code in an iOS project that has min deployment target of iOS 7?

Thanks

This pull request is a new feature for #40 to support addAnyHandler() which works for both event-based & state-based transitions.

See test case: StateMachineEventTests.swift#L382-L446

From the README, I can see that you could construct state entry and exit handlers likes so:

// onExit handler
machine.addHandler(.State0 => .Any) { context in
   print("0 => 1")
}

// onEntry handler
machine.addHandler(.Any => .State0) { context in
   print("0 => 1")
}

But will these handlers be executed in the expected order? I don't really want to have to manage order through the int myself...

This pull request will introduce fastlane as easy command-line tool.

I also added test_universal_framework.rb as "fastlane-action" to explicitly specify destination (e.g. iphonesimulator) for single-target universal framework.

Hi

I'm having some trouble understanding the 'State & Event enums with associated values' example on the main project page. I'm specifically confused by incomplete enum definitions ...

enum StrState: StateType { case str(String) ... } enum StrEvent: EventType { case str(String) ... }

Can someone please respond to this question with a complete example or update the project README ?

Thanks Dave

Apologies for creating an issue for this but it's hectic to keep track of your releases. Would be really helpful if you can start versioning it in a better way. Thanks. :)

On carhage update, build fail:

carthage version: 0.27.0 xcode version: 9.2

Build Failed Task failed with exit code 65: /usr/bin/xcrun xcodebuild -project /Users/vml933/Documents/XCodeProject/PalLinkTest3/Carthage/Checkouts/SwiftState/SwiftState.xcodeproj -scheme SwiftState -configuration Release -derivedDataPath /Users/vml933/Library/Caches/org.carthage.CarthageKit/DerivedData/9.2_9C40b/SwiftState/4.1.0 -sdk iphoneos ONLY_ACTIVE_ARCH=NO BITCODE_GENERATION_MODE=bitcode CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES archive -archivePath /var/folders/c6/cmhy9djd5y52994tjg3lsq7c0000gn/T/SwiftState SKIP_INSTALL=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO CLANG_ENABLE_CODE_COVERAGE=NO (launched in /Users/vml933/Documents/XCodeProject/PalLinkTest3/Carthage/Checkouts/SwiftState)

This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/c6/cmhy9djd5y52994tjg3lsq7c0000gn/T/carthage-xcodebuild.WbBQpz.log

Suggestions and comments about the design (not a bug.)

Should state be an attribute of the machine, or the object which is going through the machine?

My use case is a game having many tokens (AKA sprites) each having state and a state machine. I don't mind each token owning an instance of StateMachine, but then I must configure each instance the same way (easy enough to workaround.) But possibly a StateMachine should have a Design which is configured and passed to a StateMachine instance.

In other implementations of FSM 'context' seems to mean: the object which has state, which the state machine sets the state of, and which is passed to all actions (what you call Handlers) for them to act on. Your context is not the same thing? Maybe a solution is a delegate for the state machine?

On another topic, I don't understand the use case for AnyState. Is one use case adding transitions from any state to a reset state, so that you don't have to specify a transition from every state to the reset state? Maybe you could explain in your document. But I should read the code, and for example study what a transition from AnyState to AnyState would mean.

Thanks, SwiftState is rather elegant.