Suas iOS & Android Unidirectional Flow Architecture

Welcome to the Suas documentation. You'll find comprehensive guides and documentation to help you start working with Suas as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    Guides

Why unidirectional architectures

Model View Controller (MVC) and its derivation Model View Presenter (MVP) are the dominant architectures in iOS and Android respectively. Both architectures work well on small apps but are hard to scale for medium to large apps. Let's consider three situations where MVC and MVP struggle.

For starters, the MVC and the MVP patterns do not provide a good way to represent and manage state. In these patterns, the state is divided into logical screens. Having a segregated state per-screen might work when the scope of the screens is small. When screens are small in scope, having a separate and segregated state might work. In more complicated screens and configurations, state management and synchronization starts to become nuanced and complex. In these situations, a holistic approach to the application state is required to maintain consistency.

Second, in highly dynamic applications, the MVC and MVP patterns struggle to maintain consistency. Data is moved from the root/parent elements to the children and actions are moved up and down the view hierarchy. This ambiguity in data and event propagation becomes hard to handle in large applications.

Finally, the controller in the MVC and the presenter in the MVP tend to gather lots of responsibilities. They act as view updates handlers that communicate views events to models. They inform the views about changes in the models and the persistent stores. They store the state (in form of models) for the view or a collection of views. And they represent data sources for UITableView and RecyclerViews.

Suas architecture addresses these shortcomings and others with:

  • Suas applications have a single State for the full application. This state is changed by dispatching events in the form of Actions. Reducers take these actions and generate a new state.
  • By having one state for the application, consistency between screens is easier to achieve. Additionally, since state changes can be tracked this allows the possibility to build better tooling (check Using Suas Monitor and Logging in Suas)
  • Suas architecture concepts, which are heavily inspired by Redux, provide the right level of separation of concern Soc which helps when scaling applications code bases.

What's next