Some Stuff I was thinking about state machines and types

SOME STUFF I WAS THINKING ABOUT STATE
MACHINES AND TYPES

1. About Finite State Machines
2. Finite State Machines and Types
3. Using State in an View Controller

QUESTION: HAS ANY ONE
USED STATE MACHINES?

FINITE STATE MACHINES ARE
A SERIES OF STATES AND
TRANSITIONS.

THEY CAN BE USEFUL FOR VARIOUS REASONS:
▸ They are simple to draw
▸ They are simple to understand
▸ They make the state of your application explicit
▸ They are easy to program

FOR THIS REASON, THEY CAN
BE A NICE WAY TO MODEL THE
BEHAVIOR OF YOUR
APPLICATION.

AN EXAMPLE API
var machine = StateMachine()
var loadingState = State(name: "Loading")
var emptyState = State(name: "Empty")
var displayState = State(name: "Display")

loadingState.addTransition(with: "loaded", to: emptyState) { state in
guard loadedModel.count > 0 {
machine.transition(with: "firstItemAdded")
return
}
tableView.backgroundView = EmptyMessageView()
}
emptyState.addTransition(with: "firstItemAdded", to: displayState) { state in
tableView.backgroundView = nil
tableView.reloadData()
}
displayState.addTransition(with: "onlyItemRemoved", to: displayState) { state in
tableView.backgroundView = EmptyMessageView()
}
displayState.addTransition(with: "itemAdded", to: displayState) { state in
// animate item addition
}

machine.states = [loadingState, emptyState, displayState]
machine.initialState = loadingState

RUNNING A TRANSITION
// Inside of a network callback
func deleteObject() {
// delete object
if loadedModel.count == 0 {
machine.transition(with: "onlyItemRemoved")
}
}

QUESTION: WHAT SHOULD HAPPEN IN THIS CASE?
// I am in the "loading" state

QUESTION: IF STATE
MACHINES ARE EASY TO
MAKE AND EASY TO REASON
ABOUT, WHY DON'T WE USE
THEM MORE?

THE NUMBER OF STATES
OFTEN INCREASES VERY,
VERY QUICKLY.

2 STATES
class ViewController: UIViewController {
let switch1: UISwitch
}

4 STATES
}

8 STATES
}

UI CODE OFTEN HAS A LOT OF
STATES, AS A CONSEQUENCE,
MAKING THOSE STATES
EXPLICIT MEANS YOU HAVE
TO DEAL WITH THEM

SO STATE MACHINES MAY WORK BEST WHEN
THE NUMBER OF STATES IS SMALL.

PART 2: STATE
MACHINES AND
TYPES

YOU MIGHT NOT NOTICE IT BY LOOKING AT A
LOT OF STATE MACHINES LIBRARIES, BUT IT
IS ACTUALLY VERY EASY TO MAKE STATES
INTO INSTANCES AND TRANSITIONS INTO
METHODS.

struct LoadingState {
func loaded() -> EmptyState
}
struct EmptyState {
func oneItemAdded() -> DisplayState
}
struct DisplayState {
func onlyItemDeleted() -> EmptyState
func itemAdded() -> DisplayState
}

THIS WAY YOU CAN USE THE
COMPILER TO PREVENT THE
APPLICATION FROM EVER
ENTERING AN INCONSISTENT
STATE.

E.G. THE PREVIOUSLY DISCUSSED PROBLEM CAN'T HAPPEN
// Might cause an issue at runtime
// vs.
// Won't compile
state = loadingState.onlyItemRemoved()

PART 3: USING STATE IN A
VIEW CONTROLLER

// This item is expensive to load.
// I show the view controller,
// then set the item property once
// it is loaded.
var item: Item?
}

A CONSEQUENCE
func tableView(_ tableView: UITableView, didSelectRow at: IndexPath) {
guard let item = item else {}
// ...
}
func tableView(_ tableView: UITableView, cellForRowAt at: IndexPath) {
// ...
}
func tableView(_ tableView: UITableView, shouldDoSomethingElse at: IndexPath) {
// ...
}
// ...

ONCE THE OBJECT IS LOADED, IT NEVER
BECOMES UNLOADED, BUT I STILL HAVE TO
DEAL WITH THE OPTIONAL VALUE FOR THE
LIFECYCLE OF THE VIEW CONTROLLER.

OPTIONALITY DOES NOT HAVE
A WAY OF EXPRESSING THAT
ONCE SOMETHING IS SET,
IT CANNOT BE UNSET.

UNLESS IT CAN?
var data: [Item]!

I DON'T WANT TO USE AN IMPLICITLY-
UNWRAPPED OPTIONAL HERE BECAUSE I AM
INTERACTING WITH APPLE'S FRAMEWORKS.

I AM NOT SURE ABOUT THE TIMING OF THE
CALLS WHEN DEALING WITH A FRAMEWORK I
DON'T CONTROL.

protocol State {}
class LoadingState: State {
func loaded() -> EmptyState
}
class EmptyState: State {
// We know that data is not nil here, so it
// can have a non-optional reference
var item: Item
func oneItemAdded() -> DisplayState
}
// Display State could just be the tableView data source
class DisplayState: State, UITableViewDataSource {
var item: Item // We know that data is not nil here
func onlyItemDeleted() -> EmptyState
func itemAdded() -> DisplayState
}

I MADE THE STATE OBJECTS CLASSES
RATHER THAN STRUCTS SO THAT
DisplayState CAN ACT AS A TABLE
VIEW DATA SOURCE.

QUESTION: DOES ANYONE ELSE USE OBJECTS
RATHER THAN STRUCTS IN CERTAIN CASES
JUST BECAUSE YOU WANT TO INTERACT WITH
APPLE FRAMEWORKS?

var state: State
var item: Item?
init() {
state = LoadingState()
}
}

var item: Item? {
didSet {
if let item = item, let loadingState = state as? LoadingState {
let emptyState = loadingState.loaded()
emptyState.item = item
self.state = emptyState
}
}
}

func addObject() {
// add object
if item.listOfSomething.count == 1, let emptyState = state as? EmptyState {
self.state = emptyState.oneItemAdded()
}
}

func deleteObject() {
// delete object
if item.listOfSomething.count < 1, let displayState = state as? DisplayState {
self.state = displayState.onlyItemDeleted()
} else {
// Problem: What if state is not a DisplayState?
}
}

DisplayState IS ACTUALLY THE TABLE VIEW DATA
SOURCE, SO THE ITEM IS NOT NIL OR EMPTY.
func tableView(_ tableView: UITableView, didSelectRow at indexPath: IndexPath) {
let something = item.listOfSomething[indexPath.row]
// ...
}

QUESTION: WAS THIS EXERCISE IN MAKING
EXPLICIT STATE NECESSARY? COULDN'T WE
JUST, FOR EXAMPLE, MAKE CHILD VIEW
CONTROLLERS AND TRANSITION IN BETWEEN
THEM?

CONCLUSION:
▸ In some cases we might be able represent view controller state
explicitly with a state machine.
▸ If the state instances have references to objects which must not be
nil in their scope, we might be able to avoid needing to unwrap a lot
of optionals. (More generally, we might be able to more closely
model the lifecycle of the object.)

Some Stuff I was thinking about state machines and types

Recommended

Recommended

More Related Content

Similar to Some Stuff I was thinking about state machines and types

Similar to Some Stuff I was thinking about state machines and types (20)

More from gillygize

More from gillygize (8)

Recently uploaded

Recently uploaded (20)

Some Stuff I was thinking about state machines and types