My take on Coded Views
When building an iOS app there are multiple ways in which you can create the UI. You can use Storyboards and Xibs or create all components on runtime. Each approach has advantages and disadvantages and, in the end, it will all come up to the team goals and preferences.
However, no matter what you choose, it is extremely important to make sure everyone in the team follows the same style and organization. You don't want a giant, messy storyboard or dozens of View Controllers without a consistent pattern.
That is why I experimented and created a simple, handy protocol to control the order in which my UI components are created in all my classes. This is far away from being a complete framework, but gets the job done and is pretty consistent. I call it the ViewCodable protocol.
This protocol consists of just a few methods which are called in a specific order. Here is its declaration:
You might wonder now: how is this protocol easy to use if there are so many methods to worry about?
Well, thanks to Swift extensions , all these methods have default implementations. In fact, some of those methods initially do nothing, making them optional in most cases.
And what does each method do?
func setup(with views : [UIView])This is the main setup method. The argument is the list of views you wish to add to the views hierarchy and it will run all the other methods. I usually call it in the viewDidLoad function of UIViewControllers or in the initializers of custom UIViews .
func addToHierarchy(_ views : [UIView])Here we lay down the work to actually add the views to the hierarchy. Thanks to a neat protocol oriented programming trick, where the views are actually going to be added depends on the kind of component you use. For example, if the component is a subclass of UIView , the views will be added to itself. If the component is a subclass of UIViewController the views will be added to its view property. Last, but not least, if the component is a subclass of UITableViewCell the views will be added to its contentView property.
Furthermore, you can extend the protocol and add default implementations for other kinds of components.
func setupConstraints()This method is pretty straightforward. Here you can enable your Autolayout constraints or adjust your views frames manually. Now, how to do it is completely up to you. Maybe some frameworks will come in handy here, right?
func setupStyles()This is where you can customize the styles of your views. Change fonts, colors, alignments, texts. Whatever your pick.
func bindComponents()When creating interactive components such as buttons or sliders we must manually bind its actions. It could be as simple as adding a selector, or, if you are into reactive programming, enable reactive bindings.
But, if your setup is not interactive at all, you can simply leave this method as it is.
func setupAccessibilityIdentifiers()If you project is not covered by UI tests, than you can leave this method as it is too. If not, then maybe you will find it useful to setup your views' identifiers here.
This pretty much covers everything the protocol does and how can you use it. Want to see it in a real usage example?
Hands on Time!
Imagine a simple one-screen app with only a button and a label. You press the button and the label shows a random number between 1 and 100.
Something just like this:
This entire screen was created with a just a few lines of code.
For instance, this is our ViewController declaration:
We just declared our label and a button and called the main setup method.
Now the important part: how we use the protocol methods. In this case, we will only use the following three: setupConstraints , setupStyles and bindComponents .
Both label and button have fixed width and heights and are positioned around the safe area center using constraints. This is what you usually do in Interface Builder, but with code!
For the styles part, I just changed a few properties, like colors, fonts and texts.
Finally, we create a method that generates a random number between 1 and 100 and attach it to our button.
And that's it! We have a fully view coded app.
You can see it by yourself here. And, if you really like it, here is the full source code of the ViewCodable protocol. You can improve it and use it in your projects.
So, this is my take on coded views. It might not be better or worse than the way you already do things and it certainly can be improved over time but it already paid off in the projects I have been working on. That is why I thought it was worth sharing. I hope you eventually think it is worth too.
I am André. A young brazilian mobile developer that loves everything related to technology. If you have any doubt or suggestion, feel free to contact me here.
