In software development one of the most prevalent things is state management or simply put, knowing what to do and when to do it. The main focus of this series would be the presentational layer of an app and devise modelling of received data into a state object and interpretation at the view i.e managing the view in correspondence to emitted state.
Every user interaction event triggers a process, this could be an HTTP request, a CRUD operation, a scroll action, or simply launching a new activity. It’s very important to note that each process can lead to a new state.
A state is the set of values of all variable aspects of the particular system under concern at an instant in time. i.e the remembered information is called the state of the system. “Stephen Kurtzman PhD”
A finite state machine is an abstract machine that can be in exactly one of a finite number of states at any given time. “Wikipedia”
It’s safe to say, that when building screens in our apps, whether we choose to define finite states for these screens or not they already exist and how we access them or group such state-based data is important to both the sanity of the app and that of other developers involved, as well as guarding against irregular transitions or leaks in state.
a typical state transition from app start to loaded screen or error screen
The above diagram shows a typical applications state lifecycle or as we like to call it a “flow”. Each state represents either the presence of a certain type of data or the absence of it, and we would have associative views to show the user the current state of the app, which could be a progress bar for the loading state, an error message/screen for error state or a scrollable list for depicting a successful data load. Representing this data in our code in concise and clear fashion is important as it helps us to successfully separate and group operations particular to each state.
The snippet above represents a general state overview of what our diagram tries to represent. Defining a class to represent finite states in our Views is important because this helps us group operations to perform on emittanceof a particular object ViewState, rather than checking across wide form factors of data variables and have a “guess” as to what state the application is in.
After creating our Abstract state model, in our fragments or activities, we would have a resolver (usually a when or a switch case statement) that would match functions or grouped procedures to each emitted state. In other instances the states would be mapped to a Viewholder or widget and we would emit a StatefulViewObject and when resolving in the View we would just inflate the view object, we would take a look at this in the next part of this series.
