Event driven approach: Make your app more predictable, maintainable and easier to debug

MVP, MVVM, MV* are popular architecture design patterns in Android development enabling us to develop smooth and responsive apps. Some time ago I discovered that every time I implemented MVVM, I created a poor man’s state machine.

In this talk, we’ll see how we can make our apps more predictable, maintainable and easier to debug by integrating state machines into the presentation layer of the app architecture

Transcript

1. Event Driven Approach Make Your App More Predictable and Easy to Debug
2. About Me Name: Beatrice Kinya Android Engineer | Google Developer Expert - Android LinkedIn: Beatrice Kinya GitHub: BKinya X: @B__Kinya
3. Shout Out To: Rygel Louv LinkedIn: Rygel Louv X: @Rygellouv
4. Every User Facing Application is a State Machine.
5. On State Machine A state machine is a device that can be in one of a set of stable conditions depending on its previous condition and the present value of its inputs. For example, a light switch Off Press Press
6. S2 Components of a State Machine State: Status of the state machine, e.g whether the light Events: Inputs to the state machine, like pressing a button Transitions: They move the state machine from one state to another when events occur S1 Transtion Transition
7. Data Source Example: Fetching Data Data Request Data
8. Fetching Data Cont’ Initial State Loading Fail success T1 T2 T3
9. on Transitions They move the state machine from one state to another when events occur. We want our state machine to be deterministic. Given the same inputs/events we always want the same output Transitions need to be pure functions. off Press Press
10. Side Effects Fetching Data is not deterministic. We are interacting with the world outside our application, the data source. These interactions are asynchronous and in simple cases they can succeed or fail. In functional programming, a function that performs any actions besides calculating its output, like interacting with the outside world, is said to have side effects. User-facing applications are pretty useless without side effects.
11. So, How Can We Go About Having Functionally Pure Transitions?
12. Finite State Machine A deterministic finite machine can be represented like this: (Q, ∑, δ, q0, F) Q: A finite set of states ∑: A finite set of inputs/events δ: Transition function where the output depends on the current state and input given to the function(δ: Q × ∑ → Q). q0: Initial state F: Set of final state/states
22. Benefits of State Machine The code is easy to reason about App state is predictable and consistent. Easy to debug and more
23. Time Machine An optional feature It saves all states during a session. You can do with it as you may want: log the states to crashlytics, display the states in a debug menu where you’d check all the steps made previously Note: Consider not implementing the time machine by default. You’ll have chatty logs. Just use it for debugging purposes.
25. Should You Implement State Machines in Your Project?
26. It Depends
27. Why Developers never use State Machines We do not need them until we do It is overkill, and by the time it’s not, it’s too late State machines are complex Even if you have two states, a state machine might be easier than implementing a poor man's state machine What are the benefits of implementing state machines? Fit for my team/project? The proof is in the pudding. It’s difficult to appreciate how much easier life can become with state machines until you’ve used one in your project.
28. Resources https://proandroiddev.com/discovering-event-driven-architecture-for- android-717e6332065e https://skorks.com/2011/09/why-developers-never-use-state-machines/ https://github.com/BKinya/RickyAndMorty
29. Thank you for Coming!