iOS Auto Format tutorial programmatically


Rotation assist

In case your utility goes to assist a number of machine orientations, it is best to implement the next strategies inside your view controller.

class ViewController: UIViewController {

    override var shouldAutorotate: Bool {
        return false
    }

    override var supportedInterfaceOrientations: UIInterfaceOrientationMask {
        return .portrait
    }

    override var preferredInterfaceOrientationForPresentation: UIInterfaceOrientation {
        return .portrait
    }
}

Clearly you’ll be able to change the return values to assist not simply portrait, however panorama mode as nicely. That is fairly straightforward, nevertheless in case your controller is embedded inside a navigation or a tab bar controller the rotation stops working. On this case, it’s important to subclass the UINavigationController, and it’s important to return the proper values from the highest view controller.

class NavigationController: UINavigationController {

    override var shouldAutorotate: Bool {
        if let shouldRotate = topViewController?.shouldAutorotate {
            return shouldRotate
        }
        return tremendous.shouldAutorotate
    }

    override var supportedInterfaceOrientations: UIInterfaceOrientationMask {
        if let orientation = topViewController?.supportedInterfaceOrientations {
            return orientation
        }
        return tremendous.supportedInterfaceOrientations
    }

    override var preferredInterfaceOrientationForPresentation: UIInterfaceOrientation {
        if let orientation = topViewController?.preferredInterfaceOrientationForPresentation {
            return orientation
        }
        return tremendous.preferredInterfaceOrientationForPresentation
    }
}

The identical logic applies when you’ve got a UITabBarController, however as an alternative of the highest view controller, it’s important to use the selectedIndex, and return the properties based mostly on the chosen view controller.

class TabBarController: UITabBarController {

    override var shouldAutorotate: Bool {
        if let viewController = viewControllers?[selectedIndex] {
            return viewController.shouldAutorotate
        }
        return tremendous.shouldAutorotate
    }

    override var supportedInterfaceOrientations: UIInterfaceOrientationMask {
        if let viewController = viewControllers?[selectedIndex] {
            return viewController.supportedInterfaceOrientations
        }
        return tremendous.supportedInterfaceOrientations
    }

    override var preferredInterfaceOrientationForPresentation: UIInterfaceOrientation {
        if  let viewController = viewControllers?[selectedIndex] {
            return viewController.preferredInterfaceOrientationForPresentation
        }
        return tremendous.preferredInterfaceOrientationForPresentation
    }
}

This fashion your embedded controller can management the supported orientations. Oh, by the best way you need to use this methodology to alter the standing bar fashion.

Constraints

So as to perceive constraints and the present state of the Auto Format engine, we must always return to in time and begin the story from the start.

Springs and struts

Keep in mind the primary iPhone? One display screen to rule all of them! 320x480, no constraints, no adaptivity, simply frames and bounds. Positioning views on a hard and fast dimension canvas is completely a no brainer, right here is an instance.

class ViewController: UIViewController {

    weak var sq.: UIView!

    var squareFrame: CGRect {
        let midX = view.bounds.midX
        let midY = view.bounds.midY
        let dimension: CGFloat = 64
        return CGRect(
            x: midX-size/2, 
            y: midY-size/2, 
            width: dimension, 
            peak: dimension
        )
    }

    override func loadView() {
        tremendous.loadView()

        let sq. = UIView()
        view.addSubview(sq.)
        sq. = sq.
    }

    override func viewDidLoad() {
        tremendous.viewDidLoad()

        sq..backgroundColor = .yellow
    }

    override func viewDidLayoutSubviews() {
        tremendous.viewDidLayoutSubviews()

        sq..body = squareFrame
    }
}

With the viewDidLayoutSubviews methodology it is tremendous handy to assist rotation, I simply need to re-calculate the body of the view each time if the bounding rectangle adjustments. You would possibly suppose hey, that is straightforward, however what occurs if it’s important to assist plenty of machine sizes?

Do the maths!

For one single object it is really easy to make the calculations, however normally you will have a couple of view on display screen. These views can have relations to one another, and a simple arithmetic trick can lead you to an entire chaos of body calculations, do you even like arithmetic? There have to be a greater method!

Auto Format

With iOS6 Apple introduced us the holy grail of structure applied sciences. It was the proper successor of the earlier system. Everybody adopted it quick, that is why Apple engineers utterly eliminated body based mostly structure APIs within the subsequent launch… #justkidding

Aside from the joke, it was the start of a brand new period, increasingly gadgets have been born, and with Auto Format constraints it was tremendous straightforward to keep up views. Now we must always refactor the earlier instance with structure constraints.

class ViewController: UIViewController {

    weak var sq.: UIView!

    override func loadView() {
        tremendous.loadView()

        let sq. = UIView()
        view.addSubview(sq.)
        sq..translatesAutoresizingMaskIntoConstraints = false
        view.addConstraints([
            NSLayoutConstraint(
                item: square, 
                attribute: .width, 
                relatedBy: .equal, 
                toItem: nil, 
                attribute: .width, 
                multiplier: 1.0, 
                constant: 64
            ),
            NSLayoutConstraint(
                item: square, 
                attribute: .height, 
                relatedBy: .equal, 
                toItem: nil, 
                attribute: .height, 
                multiplier: 1.0, 
                constant: 64
            ),
            NSLayoutConstraint(
                item: square,
                 attribute: .centerX, 
                 relatedBy: .equal, 
                 toItem: view, 
                 attribute: .centerX, 
                 multiplier: 1.0, 
                 constant: 0
            ),
            NSLayoutConstraint(
                item: square, 
                attribute: .centerY, 
                relatedBy: .equal, 
                toItem: view, 
                attribute: .centerY,
                multiplier: 1.0, 
                constant: 0
            ),
        ])
        self.sq. = sq.
    }

    override func viewDidLoad() {
        tremendous.viewDidLoad()

        sq..backgroundColor = .yellow
    }
}

As you’ll be able to see we need not manually calculate the body of the view, nevertheless creating constraints programmatically isn’t so handy. That is why Apple made the constraint Visible Format Language.

VFL = WTF?

Really this VFL is so unhealthy that I do not even need to demo it, however anyway…

class ViewController: UIViewController {

    weak var sq.: UIView!

    override func loadView() {
        tremendous.loadView()

        let sq. = UIView()
        view.addSubview(sq.)
        sq..translatesAutoresizingMaskIntoConstraints = false

        let views: [String:Any] = [
            "view": view, 
            "subview": square
        ]
        let vertical = NSLayoutConstraint.constraints(
            withVisualFormat: "V:[view]-(<=1)-[subview(==64)]", 
            choices: .alignAllCenterX, 
            metrics: nil, 
            views: views
        )

        let horizontal = NSLayoutConstraint.constraints(
            withVisualFormat: "H:[view]-(<=1)-[subview(==64)]",
            choices: .alignAllCenterY, 
            metrics: nil, 
            views: views
        )
        view.addConstraints(vertical)
        view.addConstraints(horizontal)
        self.sq. = sq.
    }

    override func viewDidLoad() {
        tremendous.viewDidLoad()

        sq..backgroundColor = .yellow
    }
}

God forbid the engineer who invented this black magic. 😅

In order you’ll be able to see we positively have an issue with constraints. Creating all of your constraints sucks, no less than it may price many many traces of code. In fact you need to use the magical interface builder, however the place’s the enjoyable for those who simply drag traces?

Creating constraints programmatically is not any higher than calculating frames, it is going to lead you to the identical degree of complexity and even worse, this is the reason so many third social gathering frameworks got here alive and finally Apple issued the issue as nicely.

I’ve a tremendous article about mastering Auto Format anchors, I extremely advocate studying it if you wish to get accustomed to anchors. 📖

Anchors

Anchors have been born as a result of Auto Format had some development flaws.

The NSLayoutAnchor class is a manufacturing unit class for creating NSLayoutConstraint objects utilizing a fluent API. Use these constraints to programmatically outline your structure utilizing Auto Format.

class ViewController: UIViewController {

    weak var sq.: UIView!

    override func loadView() {
        tremendous.loadView()

        let sq. = UIView()
        view.addSubview(sq.)
        sq..translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            square.widthAnchor.constraint(equalToConstant: 64),
            square.heightAnchor.constraint(equalToConstant: 64),
            square.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            square.centerYAnchor.constraint(equalTo: view.centerYAnchor),
        ])
        self.sq. = sq.
    }

    override func viewDidLoad() {
        tremendous.viewDidLoad()

        sq..backgroundColor = .yellow
    }
}

See, completely rocks! Anchors are the easiest way of utilizing for Auto Format constraints.

Adaptive structure

In case you have a look at the present state of built-in apps supplied by Apple, you’ll be able to see that solely a few of them are responsive / adaptive. Generally, apps that utilizing assortment views are less difficult to adapt for greater screens, or completely different machine orientations.

At all times use assortment views, besides if it is only one view on the middle of the display screen, it is best to construct up your consumer interfaces utilizing assortment views. It will provide you with reusability, decrease reminiscence overhead, scrolling and lots of extra advantages. You do not even need to calculate the silly index paths in case you are utilizing my CollectionView micro framework.

Auto Format with layers

Auto Format is nice, however generally it’s important to work with layers immediately. Now on this scenario, you continue to need to do some calculations. You’ll be able to simply override the bounds property and replace frames within the didSet block in case you are coping with a view subclass.

override var bounds: CGRect {
    didSet {
        gradientLayer.body = bounds
    }
}

An alternative choice is to override the viewDidLayoutSubviews methodology contained in the view controller, and set the body of the layer based mostly on the brand new bounds.

override func viewDidLayoutSubviews() {
    tremendous.viewDidLayoutSubviews()

    gradientView.gradientLayer.body = gradientView.bounds
}

It’s also possible to use plain previous Key-Worth Observing to watch an objet’s bounds property and replace the body of the layer based on that.


addObserver(
    self, 
    forKeyPath: "bounds", 
    choices: .new, 
    context: nil
)

override func observeValue(
    forKeyPath keyPath: String?, 
    of object: Any?, 
    change: [NSKeyValueChangeKey : Any]?, 
    context: UnsafeMutableRawPointer?
) {
    guard keyPath == "bounds" else {
        return tremendous.observeValue(
            forKeyPath: keyPath, 
            of: object, 
            change: change, 
            context: context
        )
    }
    gradientLayer.body = bounds
}

deinit {
    removeObserver(self, forKeyPath: "bounds")
}

Animating nook radius

Initially if you wish to animate a view whereas utilizing constraint based mostly layouts, it’s important to do one thing like this.

widthConstraint.fixed = 64
UIView.animate(withDuration: 0.5, animations: {
    view.layoutIfNeeded()
}, completion: nil)

Now if you wish to animate the nook radius of a view, you’ll be able to at all times use the standard method, and set the cornerRadius property of the layer on a bounds change.

However, we have got this fancy new UIViewPropertyAnimator API since iOS 10.

self.imageView.layer.cornerRadius = 16
UIViewPropertyAnimator(length: 2.5, curve: .easeInOut) {
    self.imageView.layer.cornerRadius = 32
}.startAnimation()

It is fairly easy, you’ll be able to even apply a cornerMask to spherical simply a number of the corners. The layer based mostly structure examples are contained in the supplied supply code for the article alongside with an entire pattern for every Auto Format approach. You’ll be able to obtain or clone it from the The.Swift.Dev tutorials repository.

Recent Articles

Related Stories

Leave A Reply

Please enter your comment!
Please enter your name here

Stay on op - Ge the daily news in your inbox