Alternative UI Architectures with Android

This blog post is an excerpt of a step-by-step experiment in app development authored by Carter Hudson, Android Engineer here at Method. In his original post, published on Medium, Carter documents the thought process and code he used to approach UI architecture using state machines.

Some time ago, I noticed something about architectural patterns like MVP and MVVM that hadn’t occurred to me before: the contracts for these patterns loosely describe state machines. It seemed to me that each time I’d implemented an MVP contract, I’d ended up creating a poor man’s state machine.

While working on an internal Android application here at Method, I had the opportunity to experiment and test out a few ideas about this—specifically, a different approach to UI architecture. What I learned is that we can, in fact, make apps more predictable, maintainable, and easier to debug with a common UI architecture driven by state machines.

In this post, I’ll show you how I got there, and how you can go about implementing your own.

What a State Machine Is & Why It Matters

Let’s draw a few comparisons first because we need to know a) what a state machine is, and b) what its constituent components are. If you’ve dabbled in computer science, chances are you’re passingly familiar with these guys:

• States are descriptions of the status of your machine. While in any given state, your machine is waiting to execute a transition.
• Transitions are actions. They move your machine from one state to another when events occur.
• Events are the inputs for your machine. They’re responsible for triggering transitions.
  

A state machine will receive an event, which may trigger a transition, which may move your machine to a different state. Does this sound familiar? If you develop applications with user interfaces, it should.

What is a user-facing application if not a finite state machine?

In a standard application, a user generates events by interacting with your application through a UI. Sure, there are other ways to interact, especially on mobile devices, but let’s focus on this case for the moment. Your View notifies your Presenter of interaction through its API. Your Presenter, in turn, carries out some actions. When those actions are complete, it invokes methods on the View that reflect changes in data.

Sounds like a state machine to me.

Earlier, I said we’re implementing a poor man’s state machine. What’s the alternative, then? Well, to stop imitating and actually implement a state machine! To do this, though, we need a little more knowledge.

Continue reading and see sample code on Medium…

Want to be part of an innovative team to help business shape their digital future? Our award-winning agency is looking for people who embrace change, choose to be happy and thrive on solving complex digital challenges. Join us—read more about what makes a good fit here.