Do the right way with Storyboard
Slim vs Fat: Multi storyboard
Q: What is wrong with this storyboard? A: omg! it is a bad idea.
I have seen a storyboard with more than 25 view controllers, in each there are many subviews. It is real bad idea.
People confused screen wireframe design with Xcode storyboard. It is never meant to be the same.
Have you seen things like these?
Dont do storyboard like this
Why? since storyboard is a big XML, then
1- In design time, loading, parsing, drawing are slow; memory taken for this is huge; the change on screen will be very slow to update. Nobody would fall in love with the spinning cursor.
2- In the development time, going thru this mess will drive you nut, and will drive someone crazy alter you left. Have you tried to find a bug for double binding of the properties? If you are lucky enough, it might take you a few hours, or a few days otherwise. With the mess like the above pictures, you sure cannot be lucky.
3- In the run time, your app loads this huge resource file will take long time. Remember Apple rule: they reject the app takes more than 4 secs loading. You can read further in “Undocumented Appstore”. Even if you are lucky enough to pass it, your users will feel that your app is slow loading comparing to others.
Do like this
Making storyboard for each individual view controller. We have discussed this approach in previous article “do the right thing with Swift”. The idea is
1- Make the viewcontroller class into a component. It will have the swift file for the controller class and the storyboard file for the UI of the class. For examples, under the folder feedback, there are 2 files
- feedbackView.swift // model and controller of the feedback class
- feedbackView.storyboard // the UI or view of the class
2- Programmable load the controller as demand, not to pre-load as it is in the fatty storyboard. The code can be like this
func loadViewControllers(_ named: String) {
let storyboard = UIStoryboard.init(name: named, bundle: nil)
let targetViewController = storyboard.instantiateViewController(withIdentifier: named )
self.navigationController?.pushViewController(targetViewController, animated: true)
}
to load the feedback component, you can do like this
loadViewController(“feedbackView”);
Why? Slim vs fat is the answer.
1- In design time, Xcode loads a slim storyboard no problem.
2- In develop time, you can easy manage all fields and theirs properties with slim storyboard.
3- The compiler will compile the storyboard in separate resource files. In run time, it loads only the main slim resource file, not the rest. You only call them as demand.
4- In debug time, you know exactly where the bug is when it crashes within a component. This is very important that you should follow this practice. Debugging is the most cost and time wasted especially when people do thing in the wrong way.
You might find some sample codes in github with a single storyboard with multi viewControllers. it works fine, like this
If my student submits the assignment with a storyboard like this, I will still pass that assignment, but with a B-, for the fault of taking storyboard for a wireframe design.
In a few workshops from Apple, my team and I attended, they suggest an app with max 12 static screens is good enough. Popup, picker, dialog dont count. This implies that a storyboard with less than 12 viewcontrollers is considered as healthy, not fat not slim.
However, as soon as you starting to do component development, you will definitely stay with slim storyboard for its superiors.
Hardcode the view?
Man! Dont do that. It is the approach people did for last century. It is hard to figure out your screen looks like with hard code. Other members of your team will cry. It is not maintainable way. That is why everyone uses InterfaceBuilder. We must use it in the right way, that is all.
The article of component development is here.
…
