via emails - blky/IOS-Swift GitHub Wiki

October 20, 2014

What Storyboard can do:

• Choose the initial view controller.
• Handle the common navigation types: push, modal, and tab.
• There is a seque type called Custom which basically leaves you to implement the segue. I haven't found this too useful in the past, I don't know if it's worth bothering with.

For more custom control, Storyboard gives you the option to manually trigger the segue vie performSegueWithIdentifier and intercept the segue via prepareForSegue.

Everything you can do in Storyboard, you can do programmatically as well. The thing that can be somewhat confusing is that there are a number of cases that Storyboard doesn't handle well, so you have to fallback to the old approaches, and you end up with a mix of techniques. This is a non-comprehensive list:

• Custom container view controllers. For example, if you want to make a custom tab bar controller, that's difficult to implement in Storyboard.

• Tab Bar Controllers that have multiple instances of the same view controller w/ different properties. This happened in the Rotten Tomatoes app, and isn't well supported in Storyboard.

Changing the rootViewController. You can set the initial view controller, but you can't set it again in the app. In a real app, you might have a different initial view controller depending on whether a user is logged in or not.

All the examples I have found involve running this in a view controller, where the view controller's Main Window is available. Xcode in Swift seems gets confused about an AppDelegate class having a Window member.

The App Delegate manages the initial window. There is no confusion about the Window. The normal application template with a StoryBoard shows a property at the top of the App Delegate class.

   var  window:  UIWindow?

• If you are using a StoryBoard, the launch process assigns the Initial View Controller as the Root View Controller of the Window.
• The Initial View Controller in the StoryBoard is the one at the far left with the big right-pointing arrow . . .

You don't have to do this assignment with a StoryBoard as it happens under the covers as part of the application launch process.

If you were creating an application without a StoryBoard, you would then be responsible for creating the first View Controller that would act as the Window's Root View Controller.

You could create the View Controller completely from code, or you could create the View Controller by loading a Nib document.

The title this thread mentions among other issues 'and just switching around windows'. Sorry I have not got to writing about the issues you mentioned.

In general, you hardly ever create Window objects, and most of the time, Windows come and go as needed by the UIKit. There is usually only one Window on the screen at a time, although some screens will require a new Window.

However, what does get 'switched around' are your UIView (hierarchies, usually) that are managed by your View Controllers. When a transition is made from one View Controller to another, that new View Controller gets asked for its View (hierarchy) and that View gets added as a sub-view to the Window.

Until your View (hierarchy) is added to the Window, your View and any controls will not be able to receive events from the UIApplication object, because the Window(s) of your application are responsible for dispatching events down through the Responder Chain to any Responder objects (all Views and hence Controls are Responders) that may wish to handle events.