Rotation help
In case your software goes to help a number of system 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 help 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 right 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 important to use the selectedIndex, and return the properties primarily based 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 way in which you should utilize this methodology to alter the standing bar type.
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 to rule all of them! 320x480, no constraints, no adaptivity, simply frames and bounds. Positioning views on a set dimension 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 dimension: CGFloat = 64
return CGRect(
x: midX-size/2,
y: midY-size/2,
width: dimension,
top: 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 help rotation, I simply must re-calculate the body of the view each time if the bounding rectangle modifications. You would possibly suppose hey, that is straightforward, however what occurs if it’s important to help a number of system sizes?
Do the mathematics!
For one single object it is really easy to make the calculations, however often you’ve gotten multiple view on display. These views can have relations to one another, and a simple arithmetic trick can lead you to a whole 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 format applied sciences. It was the proper successor of the earlier system. Everybody adopted it quick, that is why Apple engineers utterly eliminated body primarily based format APIs within the subsequent launch… #justkidding
Aside from the joke, it was the start of a brand new period, increasingly more units 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 format 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 needn’t manually calculate the body of the view, nevertheless creating constraints programmatically just isn’t so handy. That is why Apple made the constraint Visible Format Language.
VFL = WTF?
Truly this VFL is so dangerous 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, not less than it’ll value many many strains of code. In fact you should utilize the magical interface builder, however the place’s the enjoyable for those who simply drag strains?
Creating constraints programmatically is not any higher than calculating frames, it is 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 nicely.
I’ve a tremendous article about mastering Auto Format anchors, I extremely advocate studying it if you wish to get aware of anchors. 📖
Anchors
Anchors have been born as a result of Auto Format had some development flaws.
The NSLayoutAnchor class is a manufacturing facility class for creating NSLayoutConstraint objects utilizing a fluent API. Use these constraints to programmatically outline your format 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 one of the best ways of utilizing for Auto Format constraints.
Adaptive format
When you take a look at the present state of built-in apps offered by Apple, you’ll be able to see that solely a few of them are responsive / adaptive. Typically, apps that utilizing assortment views are simpler to adapt for greater screens, or completely different system orientations.
All the time use assortment views, besides if it is only one view on the middle of the display, it is best to construct up your consumer interfaces utilizing assortment views. It provides you with reusability, decrease reminiscence overhead, scrolling and lots of extra advantages. You do not even must calculate the silly index paths if you’re utilizing my CollectionView micro framework.
Auto Format with layers
Auto Format is nice, however generally it’s important to work with layers instantly. Now on this state of affairs, you continue to must do some calculations. You’ll be able to 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
}
}An alternative choice is to override the viewDidLayoutSubviews methodology contained in the view controller, and set the body of the layer primarily based 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 line with 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 start with if you wish to animate a view whereas utilizing constraint primarily based 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 all the time use the standard 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’ll be able to even apply a cornerMask to spherical simply among the corners. The layer primarily based format examples are contained in the offered supply code for the article alongside with a whole pattern for every Auto Format method. You’ll be able to obtain or clone it from the The.Swift.Dev tutorials repository.
