Application architecture doesn't have to suck

SUCKAPPLICATION ARCHITECTURE DOESN’T HAVE TO

APPLICATION ARCHITECTURE DOESN’T HAVE TO SUCK

WHO AM I?

▸ Jeremy Tregunna

▸ Programming for 29 years

▸ iOS since the unofficial SDK

▸ Twitter: @jtregunna

▸ GitHub: github.com/jeremytregunna

http://github.com/jeremytregunna


WHO AM I?

▸ Jeremy Tregunna

▸ Programming for 29 years

▸ iOS since the unofficial SDK

▸ Twitter: @jtregunna

▸ GitHub: github.com/jeremytregunna

▸ Aspiring boat builder

http://github.com/jeremytregunna


VIEW CONTROLLER RESPONSIBILITIES

▸ Animations

▸ Orientation changes

▸ Laying out views

▸ Handling user input



▸ Animations




▸ Making network requests

▸ Model Mutation

▸ Synchronizing communication



▸ Animations




▸ Making network requests

▸ Model Mutation

▸ Synchronizing communication

MASSIVE VIEW

CONTROLLER


MVC PROBLEMS

▸ Massive view controllers suck

▸ State synchronization

▸ View controller entanglement

▸ Reuse issues abound

▸ Testing

▸ Many more, but that’s another talk.


VIEW CONTROLLER

▸ Animations


▸ Binding views to data

VIEW


▸ Laying out subviews


MVVM PROBLEMS

▸ Data binding support isn’t native

▸ High barrier to entry for new team members

▸ FRP helps, but tends to spread through your code like the plague

▸ Real world examples tend to pair ViewModels and ViewControllers, more like MVC-N

REDUX-ISH


INTRODUCTION

▸ Web world


INTRODUCTION

▸ Web world

▸ Application state easy to conceptualize


INTRODUCTION

▸ Web world


▸ Unidirectional data flow


INTRODUCTION

▸ Web world



▸ Changing state means firing an action


INTRODUCTION

▸ Web world




▸ State transformers isolated


INTRODUCTION

▸ Web world




▸ State transformers isolated

▸ Foreign, but easy to understand

CLOSER LOOK


STOREclass Store<S: State> { var subscriptions: [NewStateDeliverable] = [] var dispatchFunction: ((Action) -> Any)! var state: S! { didSet { subscriptions.forEach { $0.newState(state) } } }

func subscribe(subscriber: NewStateDeliverable) { guard _alreadySubscribed(subscriber) else { return } subscriptions.append(subscribe) if let state = state { subscriber.newState(state) } }

func dispatch(action: Action) -> Any { return dispatchFunction(action) } }


REDUCERstruct CounterReducer: Reducer { func handleAction(action: Action, state: AppState?) -> AppState { var state = state ?? AppState()

switch action { case _ as IncrementAction: state.counter += 1 case _ as DecrementAction: state.counter -= 1 default: break }

return state } }


ACTIONstruct IncreaseAction: Action {}

struct DecreaseAction: Action {}

// More realistic example…

struct SignInAction: Action { let email: String let password: String }

NAVIGATION


PROBLEMS

▸ View controllers tend to know about other view controllers


PROBLEMS


▸ Complicated state synchronization between VCs to share state changes


PROBLEMS



▸ External routers contain some of these problems, VCs still dependent


PROBLEMS



▸ External routers contain some of these problems, VCs still dependent

▸ Lack of dynamic hierarchies

SOLUTIONS?

APPLICATION ARCHITECTURE DOESN’T HAVE TO SUCKTEXT

FIRE AN ACTION

▸ Track navigation state as part of our application state, because it is.

▸ Router acts as a reducer over navigation state

▸ Fire an action when you want to present something

APPLICATION ARCHITECTURE DOESN’T HAVE TO SUCKTEXT

RESPONDER CHAIN

▸ Built in

▸ Passes messages along a chain of responsibility

▸ Message ignored if nobody can answer it

▸ Familiar pattern


REASONS FOR THIS ARCHITECTURE

▸ MVC defers complexity to controller level




▸ MVVM non-native binding mechanism





▸ Actions can be persisted, and replayed






▸ Avoids hidden dependencies






▸ Avoids hidden dependencies

▸ State manipulation is standard

QUESTIONS?

THANK YOU!https://github.com/Greenshire/Calibre

https://github.com/Greenshire/Calibre

Application architecture doesn't have to suck

Software

Transcript of Application architecture doesn't have to suck