Styling by subclassing – The.Swift.Dev.

The issue: UI, UX, design

Constructing person interfaces is the toughest a part of the job!

In a nutshell: design is a strategy of determining the perfect resolution that matches a selected downside. Graphic design often means the bodily drawing on a canvas or a paper. UX is actually how the person interacts with the appliance, in different phrases: the general digital expertise of the “buyer” journey. UI is the seen interface that he/she is going to see and work together with by touching the display screen. 👆

If I’ve to placed on the designer hat (and even the developer hat) I’ve to let you know that determining and implementing correct person interfaces is essentially the most difficult downside in a lot of the instances. Frontend programs these days (cell, pill, even desktop apps) are simply fancy overlays on prime of some JSON knowledge from a service / API. 🤷‍♂️

Why is it so arduous? Nicely, I consider that if you wish to be a great designer, you want a correct engineering mindset as nicely. You need to be able to observing the entire system (huge image), assemble constant UI parts (that really look the identical in every single place), plan the specified expertise based mostly on the purposeful specification and plenty of extra. It is also fairly a fundamental requirement to be an artist, assume outdoors of the field, and have the ability to clarify (describe) your thought to others. 🤯

Now inform me whose job is the toughest within the tech trade? Yep, as a free of charge everyone seems to be a designer these days, additionally some corporations do not rent this type of specialists in any respect, however merely let the work executed by the builders. Anyway, let’s concentrate on how one can create good and reusable design implementations by utilizing subclasses in Swift. 👍

Look, themes and types

Let me begin with a confession: I barely use the UIAppearance API. It is a private choice, however I prefer to set design properties like font, textColor, backgroundColor immediately on the view situations. Though in some instances I discovered the looks proxy very good, however nonetheless a bit buggy. Perhaps it will change with iOS 13 and the arrival of the lengthy awaited darkish mode.

Pricey Apple please make an auto change based mostly on day / evening cycles (you realize just like the sundown, dawn choice within the residence app). 🌙

• Fashion is a set of attributes that specify the looks for a single view.
• Theme is a set of comparable trying view types, utilized to the entire software.

These days I often create some predefined set of styling parts, almost definitely fonts, colours, however typically icons, and so on. I prefer to go together with the next construction:

Fonts

• title
• heading
• subheading
• physique
• small

Colours

Icons

You may have much more parts, however for the sake of simplicity let’s simply implement these ones with a very easy Swift resolution utilizing nested structs:

struct App {

    struct Fonts {
        static let title = UIFont.systemFont(ofSize: 32)
        static let heading = UIFont.systemFont(ofSize: 24)
        static let subheading = UIFont.systemFont(ofSize: 20)
        static let physique = UIFont.systemFont(ofSize: 16)
        static let small = UIFont.systemFont(ofSize: 14)
    }

    struct Colours {
        static let title = UIColor.blue
        static let heading = UIColor.black
        static let background = UIColor.white
    }

    struct Icons {
        static let again = UIImage(named: "BackIcon")!
        static let share = UIImage(named: "ShareIcon")!
    }

}


App.Fonts.title
App.Colours.background
App.Icons.again

This fashion I get a reasonably easy syntax, which is good, though this may not let me do dynamic styling, so I can’t change between mild / darkish theme, however I actually do not thoughts that, as a result of in a lot of the instances it isn’t a requirement. 😅

Structs vs enums:

I may use enums as a substitute of structs with static properties, however on this case I just like the simplicity of this method. I do not need to fiddle with uncooked values or extensions that accepts enums. It is only a private choice.

What if you must assist a number of themes?

That is not a giant difficulty, you may outline a protocol on your wants, and implement the required theme protocol as you need. The actual downside is when you must change between your themes, as a result of you must refresh / reload your complete UI. ♻️

There are some greatest practices, for instance you should utilize the NSNotificationCenter class as a way to notify each view / controller in your app to refresh if a theme change happens. One other resolution is to easily reinitialize the entire UI of the appliance, so this implies you mainly begin from scratch with a model new rootViewController. 😱

Anyway, verify the hyperlinks under when you want one thing like this, however when you simply need to assist darkish mode in your app, I would counsel to attend till the primary iOS 13 beta comes out. Perhaps Apple will give some shiny new API to make issues simple.

Customized views as model parts

I promised styling by subclassing, so let’s dive into the subject. Now that we’ve got a great resolution to outline fonts, colours and different fundamental constructing blocks, it is time to apply these types to precise UI parts. After all you should utilize the UIAppearance API, however for instance you may’t merely set customized fonts by the looks proxy. 😢

One other factor is that I like consistency in design. So if a title is a blue, 32pt daring system font someplace in my software I additionally count on that component to comply with the identical guideline in every single place else. I clear up this downside by creating subclasses for each single view component that has a customized model utilized to it. So for instance:

• TitleLabel (blue coloration, 32pt system font)
• HeadingLabel (blue coloration, 24pt system font)
• StandardButton (blue background)
• DestructiveButton (pink background)

One other good factor if in case you have subclasses and also you’re working with autolayout constraints from code, that you could put all of your constraint creation logic immediately into the subclass itself. Let me present you an instance:

import UIKit

class TitleLabel: UILabel {

    override init(body: CGRect) {
        tremendous.init(body: body)

        self.initialize()
    }

    required init?(coder aDecoder: NSCoder) {
        tremendous.init(coder: aDecoder)

        self.initialize()
    }

    init() {
        tremendous.init(body: .zero)

        self.initialize()
    }

    func initialize() {
        self.translatesAutoresizingMaskIntoConstraints = false
        self.textColor = App.Colours.title
        self.font = App.Fonts.title
    }

    func constraints(in view: UIView) -> [NSLayoutConstraint] {
        return [
            self.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor, constant: 16),
            self.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor, constant: -16),
            self.centerYAnchor.constraint(equalTo: view.centerYAnchor),
        ]
    }
}

As you may see I solely must set the font & textColor attributes as soon as, so after the view initialization is finished, I can make certain that each single occasion of TitleLabel will look precisely the identical. The utilization is fairly easy too, you simply must set the category identify in interface builder, or you may merely create the view like this:

let titleLabel = TitleLabel()
self.view.addSubview(titleLabel)
NSLayoutConstraint.activate(titleLabel.constraints(in: self.view))

The factor I like essentially the most about this method is that my constraints are going to be simply in the appropriate place, so they will not bloat my view controller’s loadView methodology. It’s also possible to create a number of constraint variations based mostly in your present state of affairs with additional parameters, so it is fairly scalable for each state of affairs. 👍

View initialization is tough

The draw back of this resolution is that view initialization is sort of tousled, due to the interface builder assist. You need to subclass each single view sort (button, label, and so on) and actually copy & paste your initialization strategies time and again. I have already got some articles about this, verify the hyperlinks under. 👇

With the intention to clear up this downside I often find yourself by making a mother or father class for my very own styled views. Right here is an instance for an summary base class for my labels:

class Label: UILabel {

    override init(body: CGRect) {
        tremendous.init(body: body)

        self.initialize()
    }

    required init?(coder aDecoder: NSCoder) {
        tremendous.init(coder: aDecoder)

        self.initialize()
    }

    init() {
        tremendous.init(body: .zero)

        self.initialize()
    }

    func initialize() {
        self.translatesAutoresizingMaskIntoConstraints = false
    }
}

So any more I simply must override the initialize methodology.

class TitleLabel: Label {

    override func initialize() {
        tremendous.initialize()

        self.font = App.Fonts.title
        self.textColor = App.Colours.title
    }
}

See, it is so significantly better, as a result of I haven’t got to cope with the required view initialization strategies anymore, additionally auto-resizing will probably be off by default. ❤️

My closing takeaway from this lesson is that you simply shouldn’t be afraid of courses and object oriented programming if it involves the UIKit framework. Protocol oriented programming (additionally purposeful programming) is nice when you use it in the appropriate place, however since UIKit is sort of an OOP framework I consider it is nonetheless higher to comply with these paradigms as a substitute of selecting some hacky method. 🤪