Do we really need a big, fancy framework to enhance our app’s architecture? What if we could drastically improve our app’s architecture with just a simple snippet of code?
The problem
Many of the apps I’ve seen have a very naive approach to screen navigation. Usually the view controller decides itself what view should be pushed/presented next. It looks a bit like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
TutorialViewControler { … func onNext() { let vc = LoginViewController() self.navigationController?.pushViewController(vc, animated: true) } … func onBack() { self.navigationController?.popViewController(animated: true) } … } LoginViewControler { … func onNext() { let vc = MainScreenViewController() self.navigationController?.pushViewController(vc, animated: true) } … func onBack() { self.navigationController?.popViewController(animated: true) } … } // etc… |
It’s not a very good design. It doesn’t show clearly what the flow in the application is. If you are seeing to codebase for the first time, and would like to understand what pushes LoginViewController – it would be hard without reading most of the codebase (unless you use search usages…). This approach spreads application flow throughout the app. It would be much better if have application flow grouped in one, easy to read and maintain place.
The alternative approach I came up with is possible with a short snippet of code called “Flow” (It’s so short that I wouldn’t even call it a framework or a library). Imagine you define flow in your app in a dedicated Flow classes:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
class MainFlow { /// …. lazy var loginScreen: Flow = Flow { [unowned self] lets in let screen = LoginViewController() // < screen.onLogin = lets.push(self.mainScreen) screen.onBack = lets.pop() screen.onSayHello = { print("Howdy?") } return screen } } class LoginViewController { var onLogin: (() -> Void)? var onBack: (() -> Void)? var onSayHello: (() -> Void)? } |
In above snippet LoginViewController doesn’t know what happens after successful login. It doesn’t care since it’s not his responsibility. It only informs, that login was successful. The part of interaction and transition to other view controllers was extracted and moved into a Flow part. Within a flow we define how LoginViewController should be created and what transitions are possible to/from it. Flow decides when the (de)initialization of the view controller happens. It also provides a helper called lets helper, that allows to easily define push/pop/present/dismiss operations. In this concrete example LoginViewController pushes MainViewController when a successful login happens.
Good parts here are:
- LoginViewController doesn’t know what happens after a successful login. It doesn’t even care about that and that’s good, since it’s not its responsibility
- All views are loosely coupled, coupling is done only through MainFlow class
- Transitions are described using concise and descriptive syntax, without boilerplate code
- ViewControllers in the app can be grouped by user scenario into different Flows, e.g. LoginFlow, Registration Flow, BlogPostFlow, etc…
Let me show that on a slightly bigger example
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
class MainFlow { lazy var tutorialScreen: Flow = Flow { [unowned self] lets in let screen = TutorialViewController() screen.onContinue = lets.push(self.loginScreen) return screen } lazy var mainScreen: Flow = Flow { [unowned self] lets in let screen = MainViewController() screen.onBack = lets.pop() screen.onLogOut = lets.popTo(self.loginScreen) screen.onExit = lets.popToRoot() return screen } lazy var loginScreen: Flow = Flow { [unowned self] lets in let screen = LoginViewController() screen.onLogin = lets.push(self.mainScreen) screen.onBack = lets.pop() screen.onSayHello = { print("Howdy?") } return screen } } |
As you can see, all transitions that happens in our application are stored within one file, making it easy to see how app works at first sight.
This is the first approach to the solution I call FlowKit. In upcoming days/weeks I’d like to publish Flow implementation on GitHub, please drop me a comment if you’re interested in it. At this place it’s worth mentioning Krzysztof Zabłocki’s excellent and inspiring article about FlowControllers. The main difference between his approach and mine is that his one doesn’t require any new entities (like Flow), however more boiler-plate code needs to be written because of that.
Leave a Reply