Graphics Programs Reference
In-Depth Information
• Storyboards screw up version control. If two people are working on the story-
board at the same time - which happens every day in a team environment - your
version control system, like
Subversion
, will find conflicts that you must resolve
manually.
• Storyboards disrupt the flow of programming. Let's say you are writing a view
controller and adding the code for a button that presents a view controller mod-
ally. We can do that pretty easily in code -
alloc
and
init
the view controller,
and send
presentViewController:animated:completion:
to
self
.
With storyboards, you have to load up the storyboard file, drag some stuff onto
the canvas, set the
Class
in the identity inspector, connect the segue, and then
configure the segue.
• Storyboards sacrifice flexibility and control for ease of use. When you need to get
your hands dirty, which is often, a storyboard is more of a wall than a trampoline.
The work required to add advanced functionality to the basic functionality of a
storyboard is often more than the work required to put together the advanced and
basic functionality in code.
• Storyboards always create new view controller instances. Each time you perform
a segue, a new instance of the destination view controller is created. Sometimes,
though, you'd like to keep a view controller around instead of destroying it each
time it disappears off the screen. Storyboarding does not allow you to do this.
Overall, storyboards make easy code easier and difficult code more difficult. We won't be
using them in this topic, and we do not use them when writing our own applications. It is
up to you to decide if a particular application would benefit from storyboarding. Of
course, your opinion may change as your project gets more complex. Don't say we didn't
warn you!
