MVI and Orbit

This diagram shows a simple representation of how an Orbit system (or similar systems like MVI/Redux/Cycle) works in simple principles.

1. The UI sends actions asynchronously to a business component.
2. The business component transforms the incoming actions with business logic
3. The business component then emits these events further down the chain
4. Every event is reduced with the current state of the system to produce a new state
5. The state is then emitted back to the UI which renders itself based upon information within

The main thing to remember is that the UI cannot make any business decisions by itself. It should know only how to render itself based on the input state.

Orbit components

We can map the above logic onto real components.

1. UI invokes functions on a class implementing the ContainerHost interface. Typically in Android this might be an Activity, Fragment or a simple View. However, an Orbit system can also be run without any UI, for example as a background service.
2. The functions call through to a Container instance through the intent block which offloads work to a background coroutine and provides a DSL for side effects and reductions.
3. Transformations are performed through user-defined business logic within the intent block.
4. The reduce operator reduces the current state of the system with the incoming events to produce new states.
5. The new state is sent to observers.

Notes:

• All Orbit operators are optional.

Side effects

In the real world such a system cannot exist without side effects. Side effects are commonly truly one-off events like navigation, logging, analytics, toasts etc that do not alter the state of the Orbit Container. As such there's a third Orbit operator that can deal with side effects.

The UI does not have to be aware of all side effects (e.g. why should the UI care if you send analytics events?). As such you can have side effects that do not post any event back to the UI.