Type-Safe Storyboard Segues
I thought I had my share of Storyboard Segue-related tips already to make them less brittle when I found yet another approach to use Swift’s enums for segues by Ricardo Pereira.
Flow Controllers to Replace Segue-based View Transitions
Krzysztof Zabłocki wrote about the concept of “Flow Controllers”. Assimilating the concept, I imagine they’re similar to the bootstrappers I use during app launch, only Krzysztof says there’s just one initial flow controller after launch while the others are used when transitions need to take place.
Separating state from transitions is a higher-level goal of architecting apps – and is especially amiss in UIViewController-centered iOS apps. “Flow Controllers” encapsulate the change or transition. This includes setting up the view controller according to the presentation needs:
- Configuring view controller for specific context - e.g. different configuration for an Image Picker shown from application Create Post screen and different when changing user avatar
- Listening to important events on each ViewController and using that to coordinate flow between them.
- Providing view controller with objects it needs to fulfill it’s role, thus removing any need for singletons in VC’s
The singleton Krzysztof talks about is the usual way app state is modelled.
Here’s a slightly modified example to illustrate how a flow controller manages transitions between view controller scenes with configureProgramsViewController, configureCreateProgramViewController, or similar:
func configureProgramsViewController(
viewController: ProgramsViewController,
navigationController: UINavigationController) {
viewController.state = state
// Add button action callback to show the next scene
viewController.addProgram = { [weak self] _ in
guard let strongSelf = self else { return }
let createVC = // recreate a view controller, e.g. from a Storyboard
strongSelf.configureCreateProgramViewController(createVC,
navigationController: navigationController)
navigationController.pushViewController(createVC, animated: true)
}
}
The flow controller owns the state here and takes care of pushing view controllers onto the navigation stack. This will not work with segues. It’s a replacement for them.
Segues: How to Use Them While Saving Lines of Code
In “What’s New in Storyboards” of WWDC 2015, we’re presented with implementations of unwind segues. Now I’ve stated part of my concerns with segues and app architecture already. The sample code was very straight to the point:
How to Change the Detail of a UISplitViewController in the Background
A UISplitViewController has a master and a detail view controller. When the selected item is deleted and the detail is visible, you can perform a segue. If the detail is not visible, performing a segue to change the detail will present it. I didn’t want that. There are two cases where you will want to change the detail although it’s not visible:
Dismissing a Modally Presented Scene on Both iPad and iPhones Using Unwind Segues
UISplitViewController is the way to go when you want to make your iOS app universal without much hassle and can model the scenes in terms of master/detail. While getting Calendar Paste ready for the upcoming iOS 9 release, I discovered that using UISplitViewController across devices is one thing, while Storyboard segues are another.
Using Swift Enums to deal with Storyboard Segues
I like when the code is explicit. Unlike Brent Simmons, I don’t feel comfortable using string literals in code especially not when I’m still fleshing things out and change values in Interface Builder a lot. In Objective-C, I would’ve used plain old constants. For storyboard segues, for example:
Storyboard Segues VS Tell Don't Ask Principle
UIStoryboardSegues are a blessing to add rudimentary navigation between view controllers in iOS projects. User interaction can trigger segues without any code. That’s all good and well to move back and forth between mostly static scenes in your Storyboard. Passing data around is not so easy, though, without making things more complicated.