10 Tips for Developing with Storyboards

Rather than going into a comprehensive guide on how to create something using Storyboards, I will focus on 10 things here. These are in no particular order, but they may help you along the way.

Storyboards are an area where I spent the most time. I really enjoy visual programming. Simply dragging items onto the canvas, updating the position, and setting some descriptions creates a user interface without writing any code. This is important because user interface code can quickly turn into a mess.

When I get involved in a new project, the first thing I do is find the Storyboard. This is an important place to get an overview of the overall framework of the application.

Without the visual editor, you have to manually work around things to find out what’s going on. You spend a lot of time going back and forth in the code, only getting a rough idea of ​​what’s going on in a given view. You can explicitly refer to the design files or run the app and navigate to the desired area, but I prefer to avoid that. Finally, in some cases, adjusting UI components becomes a tedious process. You’re constantly compiling and running the app to verify that everything is in the right place, rather than quickly adjusting via Storyboards.

Look, that's a lot of code to create a simple interface like the one on the right, and I haven't even written any auto layout code to help us position it. I know there will be stubborn code geeks. But I still don't want to bloat my code with this, it's really unpleasant. Don't get me wrong. For beginners, the value of doing this is to understand how to create a user interface through code. With a given user interface, you have a general idea of ​​what it can do. Instead of looking up the documentation.

List

Maybe it can be classified as one, but don't worry about it.

You don’t need to build your entire app in one storyboard. You can split it into several storyboards. Let’s say you have an admin panel, a settings panel, and a main panel. This can save you a lot of effort when your app grows. It will also be easier to interact with storyboards when working in a team, and it will be faster to find the storyboard you need.

What is an exit segue and how to use it

First, let me explain what a segue is. Suppose you have two scenes in your storyboard, and there is a button in the first scene. When you right-click the button in scene 1 and drag it to scene 2, you are creating a segue.

Now let's say we choose to present modally. The modal indicates that this is the scene that the user has primary focus on. There is no easy way to get back to the first scene, like you might have seen if you pushed a scene onto the navigation stack. We could create a delegate to notify the first controller that we are done. But that's a bit tedious, and we could also send a notification to the first controller, but that's overkill. This is an opportunity to use an exit segue, which works just like a segue, except it returns to where the UIStoryboardSegue action was performed. That's the key!

The exit segue can always navigate back through the segues you created, and can find the exit segue no matter where the segue was created.

Take a look at the full map structure below.

If you just right-click the exit segue indicator on the button, you won't see anything. It needs to detect that you created a UIStoryboardSegue action in the destination controller (the green arrow is pointing to it). For example:

 @IBAction func unwindToSceneA(unwindSegue: UIStoryboardSegue) {
 // be sure to give your unwind segue an identifier so you know where we're coming from  
 }

Storyboard Jump

You don't have to draw a pretty segue in the storyboard to get where you want to go. You just initialize the storyboard and get the controller you want to present. Once you have the controller, you can call the necessary presentation methods.

 var storyboard: UIStoryboard = UIStoryboard(name: "Settings" , bundle: nil)
 var modal: UIViewController = storyboard.instantiateViewControllerWithIdentifier( "settingsStoryboardId" ) as UIViewController
 self.presentViewController(modal, animated: true , completion: nil) 
   
 /* If you're fetching a controller in the same storyboard you're already on,
 * then you can skip initializing a new UIStoryboard object.
 */  
 var modal: UIViewController = self.storyboard?.instantiateViewControllerWithIdentifier( "customStoryboardId" ) as UIViewController
 self.presentViewController(modal, animated: true , completion: nil)

It can be tedious to spend all your time building and running your app to see if your user interface adjusts to your expectations. This is especially true when dealing with Auto Layout.

Now with the preview editor open, you can modify the view and see how it changes. You can also press the + button on the bottom left of the Assistant Editor panel to preview the interface on multiple screen sizes.

#p#

Give your fingers a break

If you have a button that needs to be connected to source code, you can right-click and drag a line into the source file to create an outlet for you.

Additionally, for a given event, you can generate an action by clicking and dragging into your source file.

The final result of the above operations.

So, why do we need to do all this? Well, the most obvious one is the action. If you don't create an @IBAction function, nothing will happen when you press the button. You can assume that you need to add some code to change the image that is initially set in the UIImageView. In order to change this image we need an @IBOutlet so that we can access it.

Avoid extremely complex controllers

Although your controller can manage a large number of subviews, you run the risk of adding view after view and completely breaking things. You'll soon find that you've strayed from the purpose of using a visual editor - to provide a clear view hierarchy. If you have a complex view structure, it's time to think about these settings.

You can use a xib, or you can add a container view object to your scene and hide it until needed. Usually I use a xib, but in some cases I use a container view object.

When you add a xib you also add a source file that you will use to initialize the xib. For example, we created ExampleView.xib and a nice scene. To load this view we need to create ExampleView.swift and initialize the xib.

 import UIKit 
   
 class ExampleView: UIView { 
      
 // normal initialization  
    override init(frame: CGRect) {
 super .init(frame: frame)
        self.addExampleViewSubview()
 } 
      
 // will be loaded if we use this class in a storyboard, for example  
    required init(coder aDecoder: NSCoder) {
 super .init(coder: aDecoder)
        self.addExampleViewSubview()
 } 
   
    func addExampleViewSubview() {
        var xib = NSBundle.mainBundle().loadNibNamed( "ExampleView" , owner: self, options: nil)
        var view: UIView = xib.first as UIView
        view.frame = self.frame
 self.addSubview(view)
 }
 }

Placeholder constraints

This is for those who like to mix code and storyboard manipulation of constraints. Even though I personally try to avoid writing constraints in code as much as possible, this is really useful for views that don't belong in the storyboard.

If you’re trying to create constraints in code that need to interact with a user interface in a storyboard, this can be a very scary experience. But don’t be afraid, you can easily tell Xcode that this particular constraint is a placeholder. This means it will be ignored when you build and run your app.

Default View Controller

You may need to change which scene is loaded with the storyboard. In earlier versions of Xcode you might have selected a scene and then selected **Is Initial View Controller**. This has changed in the latest version of Xcode. Now you search the Object Library, find **Storyboard Entry Point**, and then you can drag it to the desired scene. Only one of these can be active at a time, so you can drag it to whichever controller you want.

Why would you worry about the entry point changing? Personally, I use this to test different controllers and I don't want to have to create a ton of buttons to get into the controller. If you just update the entry point in the storyboard, it will load right away.

Customizing Segue Transition Effects

If you select a segue, you may have noticed that it has some pre-loaded transition effects, such as vertical overlay, horizontal flip, fade, partial curl, etc. What if you want more customization? In this case you need to create a custom UIStoryboardSegue.

To give a simple example, create a new Swift file and name it CustomSegue. When our segue is executed (the button above is clicked), the following code will also be executed.

 import UIKit 
   
 class CustomSegue: UIStoryboardSegue { 
      
    var startingPoint: CGPoint = CGPoint(x: 0 , y: 0 ) 
      
 override func perform() {
        var source = self.sourceViewController as UIViewController
        var destination = self.destinationViewController as UIViewController 
          
 // Add the destination view as a subview (temporarily)  
        source.view?.addSubview(destination.view) 
          
 // Set the start scale  
        destination.view.transform = CGAffineTransformMakeScale( 0.05 , 0.05 ) 
          
 //Original center point  
        var originalCenter = destination.view.center
        destination.view.center = self.startingPoint 
          
        UIView.animateWithDuration( 0.225 , delay: 0.0 , options: UIViewAnimationOptions.CurveEaseOut, animations: { () -> Void in
            destination.view.transform = CGAffineTransformMakeScale( 1.0 , 1.0 )
            destination.view.center = originalCenter
        }) { (finished) -> Void in
            destination.view.removeFromSuperview()
            source.presentViewController(destination, animated: false , completion:nil)
 }
 }
 }

When the button is pressed, this will expand the target view from a starting position that we set. In this case, I set the starting position to the center of the button in scene 1 (the source scene).

 override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
    let custom = segue as CustomSegue
    custom.startingPoint = self.nextImage.center
 }

In the storyboard file we select the segue from scene 1 to scene 2. Change the Segue to Custom and enter the Segue class to match the one we just created.

Avoid source control nightmares

For those who work in teams, storyboards are still a big pain when it comes to source control, although they are getting better. That's why you should split your storyboards into several. If you can avoid it, make sure only one person works on a storyboard at a time. This will avoid conflicts when someone else commits changes to the storyboard into the project. Even if it's not that easy to avoid, be prepared to prevent it. This is probably the biggest reason why teams and small companies don't want to use storyboards.

Even though it's very likely that I'll end up with source control conflicts when I share storyboards with my team, I still feel that speed and efficiency outweigh the annoying patches that come with conflicts. In most cases I make sure others avoid working on them at the same time as me. But it still happens time and time again.

Here is how I handle conflicts:

• (First line of defense) Avoid it in the first place. I always commit early when working on a storyboard and say hi to other people who are also working on the storyboard. When working with others, try to keep the work small and help each other out. Don't push big monolithic updates.
• If I encounter a conflict, I'll look through it in the diff tool [Kaleidoscope](http://www.kaleidoscopeapp.com/). It does take some experience to understand how storyboards work. If you haven't looked at it yet, now is the time. Right-click on the storyboard > open as > source code and see how the controller areas (including the connection information) are laid out.
• (Bad case scenario) I figure out who made the *** changes, who received those changes, what overwrote them, and then we revert those changes.

I've worked on some large projects. Although these merge issues are not often serious enough that the diff tool cannot recover. But you can gain more experience.

I can't stress this point enough. Being proactive is important. Know what your team is like. If you have an incredibly complex storyboard, divide it up into different areas.

Take it, no thanks

Storyboards are extremely useful, especially for something that is very visual. They can also give you a nice speed advantage when prototyping. Without having to worry about code, you can quickly put the various elements in place, connect them, and start working on the logic that drives the interface.