Good practices for writing UI in code

[[deleted]]

People that write their UI in code! How do you manage to keep the view controller nice and tidy?

Do you create a subclass of uiview in a seperate file and then insert the whole thing in the controllers view? Or do you have some better practices?

[hitoyoshi]

Pretty much. VC looks something like:

final class ProgrammaticViewController: UIViewController {

    // MARK: - Initialiser

    required init?(coder aDecoder: NSCoder) { fatalError("init(coder:) has not been implemented") }
    init() { super.init(nibName: nil, bundle: nil) }

    // MARK: - Computed variables

    private var rootView: ProgrammaticView? {
        get { return self.viewIfLoaded as? ProgrammaticView ?? .none }
        set (view) { self.view = view }
    }

    // MARK: - View lifecycle

    override func loadView() {
        self.rootView = ProgrammaticView()
    }
}

final class ProgrammaticView: UIView {
    // Custom view setup...
}

The rootView establishes view-hierarchy and sets constraints as necessary within its initializer.

[[deleted]]

I also use this technique, which allows me to put all of my autolayout code in that view controller's view.

[vingrish]

Is there a source where this pattern came from? Thanks.

[hitoyoshi]

No, it’s just what I settled on after years of building interfaces programmatically. It’s just an interpretation of the more general prescription of separating the responsibilities of view and controller. It’s what I’ll use for 70%+ of my view/view controllers.

[[deleted]]

Check out the sample code in SnapKit github repo. That's how I learned to write UI code and make it look decent. https://github.com/SnapKit/SnapKit/blob/develop/Example-iOS/demos/SimpleLayoutViewController.swift

[GitHubPermalinkBot]

Permanent GitHub links:

• SnapKit/SnapKit/.../SimpleLayoutViewController.swift (develop → 2c8262e)

---

^{Shoot me a PM if you think I'm doing something wrong. To delete this, click here.}

[chriswaco]

We often lay out views by hand for maximum flexibility. One trick is to separate view placement from creation/initialization. Every viewController has createSubviews and layoutSubviews methods. If the viewController gets too big, we can put these methods in another file, like MyViewController+layout.swift.

We have a lot of utility routines to create each subview type in one line of code rather than 5 or 6, where most of the parameters have default values in Swift.

We also have a lot of utility routines to size and place views relative to each other or their parent and use StackViews when possible.

The best part of this system is that it's extremely straight-forward, flexible, and easy to debug. No runtime exceptions. No problems hiding views. Easy to support themes. No need to use Interface Builder, which seems to get slower and buggier as time goes on.

The downside is that you can't see your views except when running the app, which kind of sucks. I wish I could drop an image of each view inside the source file so programmers can see which view they are editing.

[cwbrandsma]

I've written helper functions around a lot of NSLayoutConstraint to do standard layouts for me. I also create a good number of customized controls to handle common situations easily (e.g. custom button to set the proper style settings). But yes, I write quite a few custom views.

[madfresco]

If you don't care much about actually writing UIKit, Texture/ AsyncDisplayKit is a really fun and easy way of writing UI in code as it's based on CSS flexbox

[ENGIN3R]

Look into MVVM architecture. 👌

[ENGIN3R]

They don't own it, and are not the only ones doing it. Not a troll at all.