Exceptions aside, our apps would be boring if we only had one screen on them, right? To transition from one view controller to another in iOS, we use a concept called segues. In this tutorial, you are going to learn how to navigate from one screen to another.
There are many types of segues. However, not all of them are adequate for all situations. The one you choose between two concrete view controllers depends on the structure of your user interface and the effect you want to achieve. Some segues make sense only in certain scenarios.
However, none of this is written on stone. For every transition between view controllers, you should choose the type of segue that seems right for your application.
A “Show” Segue allows you to navigate back and forth through a pile of views that stack on top of each other. It’s indeed one of the most used segues. To enable this type of navigation, you need to embed your initial view controller in a Navigation Controller. A Navigation Controller appears as a bar on top, usually with a title in the center and an arrow in the left side. It controls the stack of views.
Thus, you will “push” a new view controller to the Navigation Controller, and it will appear from right to left. Conversely, when clicking on the arrow, you will pop a view controller from the stack, going back to the previous one.
This kind of segue is appropriate when you are presenting a set of sequential screens, like a wizard. It can also indicate a “going deeper” flow, where you are taken progressively into a more detailed view.
A “Present Modally” Segue is also one of the most common segue types in iOS. It shows a new view controller on top of the previous one. However, a modal view controller is not supposed to be part of any hierarchy or stack of screens. It just sits on top of the previous view controller.
Modal segues in iOS are quite similar to Bootstrap’s HTML modal dialogs, both in appearance and objective. The goal of a modal segue is presenting the users some information or asking a question that is limited in scope. As a result, you shouldn’t usually bind several view controllers together via modal segues. On the contrary, the flow should be presenting a modal view controller, achieve some goal, and then go back to the initial view controller.
A typical use for a modal segue is creating a new item to add to a list. Imagine that you have a table view with a list of items, and a “plus” button that allows you to add a new one. Generally speaking, it’s a good idea to present the screen where you
Modally presented view controllers can appear and disappear using several animations. The default one is sliding up from the bottom of the screen.
A “Popup” Segue shows the new view controller confined within a popup. Obviously, this type of segues only makes sense in an iPad. On devices with smaller screens, like the iPhone, this segue behaves as a normal modal transition.
This type of segues is useful when on an iPad to show a small view controller closely related to an action or button. You can use a popup to present the user a reduced set of options, or ask for one or two pieces of information (like name and email). As an example, popup segues are great for choosing a file or an image when the user clicks on a “Load file” or “Add picture” button.
Popup segues need an anchor. This anchor is the view where the arrow of the popup will point to. Normally, you want your popup to point to the button or view that triggers its appearance.
The “Show Detail” segue is a special type of segue that’s useful for split view controllers. In a split view controller, you have a “Master” view controller at the left that controls the “Detail” view controller at the right.
If all detail view controllers have the same structure, so just their data is different, no segue is needed. However, if you need to show detail view controllers with different structure or meaning, you need to perform segues.
The catch with these types of segues is that, contrary to what might seem logical, the segue is performed in the master view controller. We will explain the process in depth later.
If we use this segue between two view controllers that are not in a split view controller, it will behave as a modal segue.
There are two ways of performing segues: via the Interface Builder and programmatically.
First, let’s have a look at the easiest way of defining segues: doing it via the Interface Builder. Suppose we have an initial view controller that serves as a menu to choose the type of segue. Suppose also we have four destination view controllers, one for each of the segue types. Our menu view controller has beautifully placed buttons to take us to all those view controllers. Then, for every segue we want to add, we will hold ctrl while we drag from the appropriate button to the destination view controller. Finally, while still holding Ctrl, we will release the mouse. A small popup will appear asking us the type of segue to add.
Nevertheless, take into account that the first thing we need to do is embedding the initial view controller in a Navigation Controller. This is because we need the navigation controller to do Show (Push) segues.
Once created, you need to give an identifier to that segue. This is not strictly necessary for segues that are created in IB and are going to be triggered directly by a button. However, it’s always a good practice to name all your segues.
In order to do that, follow the steps depicted in the figure below. First, click on the segue in the Interface Builder (1). Next, go to the Attributes Inspector at the right (2, you might need to display the panel if it’s not currently showing). Finally, in the “identifier” field, enter a unique name for this segue. Hopefully, something more descriptive that “pushSegue”. Good segue names indicate the meaning of the transition, like “showCarDetails” or “collectUserData”.
When creating the segue from a button, it will automatically bind to that button. You won’t need to define an IBAction for it. However, sometimes you would like to perform the same segue in response to different buttons or controls. You might even want to perform the segue in response to external events. In those situations, we need to trigger it programmatically. We will learn to do that later on.
As we said earlier, modal segues may appear with different animations. To choose how the new view controller will appear in a “Present Modally” segue, you need to click on the segue and go to the Attributes Inspector. Once there, click on the “Transition” dropdown. You will see four animated transitions available:
In this tutorial, we learned about all the possible segues available for us to transition between two view controllers in iOS. Also, we learned how to create segues visually via the Interface Builder. In the next episode of the series, we will learn to trigger segues programmatically and how to send parameters to the destination view controller.
As always, you can download the code from my Github repository.