Home IOS Development iOS Auto Format tutorial programmatically

iOS Auto Format tutorial programmatically

0
iOS Auto Format tutorial programmatically

[ad_1]

Rotation help

In case your software goes to help a number of system orientations, you need 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 possibly can change the return values to help not simply portrait, however panorama mode as properly. That is fairly simple, nonetheless in case your controller is embedded inside a navigation or a tab bar controller the rotation stops working. On this case, it’s a must to subclass the UINavigationController, and it’s a must 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 in case you have a UITabBarController, however as an alternative of the highest view controller, it’s a must 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 should use this technique to vary the standing bar fashion.

Constraints

With the intention 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

Bear 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 set measurement canvas is totally 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 measurement: CGFloat = 64
        return CGRect(
            x: midX-size/2, 
            y: midY-size/2, 
            width: measurement, 
            top: measurement
        )
    }

    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 technique it is tremendous handy to help rotation, I simply should re-calculate the body of the view each time if the bounding rectangle modifications. You would possibly suppose hey, that is simple, however what occurs if it’s a must to help plenty of system sizes?

Do the mathematics!

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

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

Other than the joke, it was the start of a brand new period, increasingly more units had been born, and with Auto Format constraints it was tremendous simple 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 possibly can see we needn’t manually calculate the body of the view, nonetheless creating constraints programmatically will not be 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 possibly can see we undoubtedly have an issue with constraints. Creating all of your constraints sucks, a minimum of it may price many many strains of code. After all you should use the magical interface builder, however the place’s the enjoyable if you happen to simply drag strains?

Creating constraints programmatically isn’t any higher than calculating frames, it’s going to lead you to the identical stage of complexity and even worse, this is the reason so many third occasion frameworks got here alive and finally Apple issued the issue as properly.

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

Anchors

Anchors had 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 the event you take a look at the present state of built-in apps supplied by Apple, you possibly can see that solely a few of them are responsive / adaptive. Basically, apps that utilizing assortment views are easier to adapt for greater screens, or completely different system orientations.

At all times use assortment views, besides if it is only one view on the middle of the display screen, you need to construct up your person interfaces utilizing assortment views. It gives you reusability, decrease reminiscence overhead, scrolling and plenty of extra advantages. You do not even should calculate the silly index paths if you’re utilizing my CollectionView micro framework.

Auto Format with layers

Auto Format is nice, however typically it’s a must to work with layers instantly. Now on this scenario, you continue to should do some calculations. You possibly can simply override the bounds property and replace frames within the didSet block if you’re coping with a view subclass.

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

Another choice is to override the viewDidLayoutSubviews technique 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
}

You too can use plain outdated Key-Worth Observing to watch an objet’s bounds property and replace the body of the layer in response to 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

To begin with if you wish to animate a view whereas utilizing constraint based mostly layouts, it’s a must 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 possibly can at all times use the normal means, and set the cornerRadius property of the layer on a bounds change.

However, we have 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 possibly can even apply a cornerMask to spherical simply a few of the corners. The layer based mostly structure examples are contained in the supplied supply code for the article alongside with a whole pattern for every Auto Format approach. You possibly can obtain or clone it from the The.Swift.Dev tutorials repository.

[ad_2]

LEAVE A REPLY

Please enter your comment!
Please enter your name here