to add on top of what lubonay wrote, this unidirectional data flow allows to solve a wide range of problem in how we handle state (and its changes). so you hav

to add on top of what lubonay wrote, this unidirectional data flow allows to solve a wide range of problem in how we handle state (and its changes). so you have - the state, only containing pure java/kotlin objects) - reducers to handle state changes. Basically a reducer is a method that takes a state as input (and often another parameter, like e.g. an user input) and creates another state as output. - and a model of your ui, that is created from each state. This works very well to have fully testable business logic (which is where the no Android objects is nice, so tests can just run on the JVM) and think about how both state and view changes (both state and view states are immutable, and are altered by copy). Again, not necessarily something I say that grandparent absolutely needs, but if they want to try something new, it is there.