There are different ways to create your Views: the good old option of creating them programmatically, using XIBs, or the latest Apple-provided format, Storyboard. There’s quite a lot of discord over what the best method is, and there is no universal answer.
But let’s not get ahead of ourselves.
So, what are XIBs?
XIBs (derived from “Xcode Interface Builder”) are XML files that define and configure a set of objects, and are specially designed to manipulate Views. Xcode has a built-in editor, the said Interface Builder, that manages those Views, making it easy to configure and design the app layout.
Even if most developers associate a XIB file with a screen or a view controller, XIBs are actually generic containers of objects and can be used together with other object types as UIViews, NSObjects or just alone.
From the desk of Kristijan Delivuk, iOS engineer.
XIBs have some significant advantages in development, since they enable you to quickly put together a user interface and are a good choice for apps with simpler Views.
On the other hand, merging conflicts is more difficult when working in a team environment, and so is creating more complex screens with dynamic content.
There is no one-size-fits-all solutions, so we tend to create Views programatically, but use XIBs when working on apps with simpler View structure.
So, how would we configure Views in our project to remove all the unnecessary responsibilities from the ViewController?
Configuring Views Programatically
We’ll start building the View programmatically and then recreate the process with XIBs to show the difference.
First things first. Let’s create the View that will hold TableView, add it to subview and put constraints superview.
Now let’s create a cell that will hold the city name and temperature. Nothing complicated.
We can already see that setting auto layout configuration programmatically creates a lot of unnecessary code, which can be avoided using XIBs.
At last, let’s configure the connection between the ViewController and the View programmatically. The ViewModel is defined through ViewModelProtocol, but we’ll go over why and how in the next blog post, focusing on the MVVM-C pattern.
That looks nice.
Now we’ll add some dummy data to the TableView for our presentation to work.
The final result should look something like this:
Now let’s get back to the View and try to refactor some things.
We’ll tackle that problem using XIBs.
First, we‘ll create table view cell through XIB. To do that, we need to delete the default View, get the TableView Cell from the list of objects and drag it up as a new main View. We set up all the contraints on it as well.
Now, making two similar cells through XIBs would mean that we’d have to define the look of each cell individually, so to bypass that, we’ll define all additional properties on the subviews programatically, within the weatherview.swift class.
After that we’ll put a custom class property to WeatherXibCell.
Now, we need to make changes to tableview so that it loads the cells from the XIB.
In WeathervView.swift we’ll swap this:
We’ll also set the cell in WeatherVC in cellForRowAtIndexPath to
And voila, here you have the exact same result with less fuss:
You can also see that the View is much neater now and all the different constraints are transferred to XIB, where they are set up more quickly and result in cleaner code.
Next, we can do the same with the Weather View. But that we leave to you. 😉