An app with Katana and Tempura: the Basics
Hi everybody, I’m Riccardo. Senior iOS Engineer at Bending Spoons, I breathe iOS development, both apps and tools and I love to share my knowledge with others.
Hi everybody and welcome to my first tech article! Today I’ll introduce you to a couple of open source technology we constantly use at Bending Spoons to develop our apps: the goal is to talk about their foundation to then walk you through writing your first app with them. They are Katana and Tempura.
Katana
Katana is strongly inspired by Facebook’s Redux framework. The main idea is to have a single, immutable place where you can save the state of your application. This place is the State and it is managed by a Store: an object whose purpose is to regulate access to the state.
I wrote that the state is immutable, but we should be able to update it to implement some real-life logic. Katana offers a controlled way to update the state with some special structs called StateUpdater. These structs have a method that takes the current state and returns an updated copy of it, leveraging the Swift copy-on-write mechanism. The state is therefore immutable because each instance of the state is cannot change and when it comes to updating it, we are actually creating a copy of it and we use that copy as the new current state.
Katana helps also in organizing the logic of the app. The suggested way to implement it is by using managers that expose the logic in pure functions. Those managers live in a DependenciesContainer, a class maintained by the Store and that can be accessed through some other structs called SideEffect: these are the glue that connects the State, the Dependencies, the View Controllers and the managers and they orchestrate the execution of your app.
The missing piece here is… How can we invoke state updaters and side effects? They both conform to a special protocol called Dispatchable. The Store offers a method, called dispatch, that issues the dispatchables and takes care of executing the stateUpdate or the sideEffect.
Tempura
Tempura is our MVVM implementation. We evaluated several alternatives when we had to chose the fittest architecture for Bending Spoons. We started from the classic Apple’s MVC, but everyone knows its shortcomings (and if not, read this article! ;) ).
We evaluated MVP and VIPER. The first was not really convincing and still presented some of the flaws of MVC. The other was really too complex for the kind of apps we develop. Our motto was: “try to pick the right tool for the right job”.
Tempura uses the ViewController (VC) as the glue between the logic and the view. Their only responsibility is to create the ViewModels (VM) and the Views (V), and passing the former to the latter. We use Katana and Tempura together, therefore our Model (M) is the Katana’s State. By leveraging the subscriber feature of Katana’s Store, which notifies its observers whenever the state changes, we automated the update of the view: every time a StateUpdater updates the State, the active VC receives the notification, creates a new VM and passes it to the V. The V can now update its content and its layout based on the data provided.
The other responsibility of Tempura is to handle the navigation of the app. We implemented a mechanism that relies on the native navigation system to obtain some facilities of the OS out of the box. Tempura provides also side effects to show and hide your VC. Once the VCs are configured properly, by defining the set of rules that let you navigate from a VC to another, Tempura will take care of the rest.
Whoa. It has been an intense dive into some basic concepts of our app architecture! I hope you followed me: next week we will dig into the code and I’ll show you how to set up an app with these frameworks.
