How NOT to construct kinds for iOS apps?
Let’s begin with an sincere assertion: I tousled with this tutorial (loads):
Constructing enter kinds for iOS apps
The factor is that this way constructing methodology solely works if the cells are all the time seen on display screen, which is kind of a uncommon case. I found this problem whereas I used to be engaged on my present undertaking and a few fields had been continuously disappearing and transferring the cursor to the following enter subject stopped working when the cell was out of body.
Reusability & reminiscence effectivity shouldn’t be all the time what you need.
Looks like UICollectionView shouldn’t be the most effective answer for making enter kinds, as a result of the fixed cell reusability will mess up a few of the anticipated conduct. It is nonetheless good for lists with “a thousand components”, however for an enter kind I might not suggest this method anymore. Yep, my mistake, sorry about it… 😬
Studying by making errors
Lengthy story quick, I made a mistake and possibly you will additionally make loads throughout your developer profession. Does this make you a nasty programmer? In no way. We’re human, we’re continuously making smaller or greater errors, however…
(Stay and) flip it into energy
Your errors will all the time stick with you, however you possibly can be taught from them loads. The issue solely begins if you happen to hold doing the identical errors many times, or you do not even understand that you just’re doing one thing flawed. It is actually exhausting to take one step again and see the issue from an even bigger perspective. Generally you merely want another person to level out the difficulty for you, however damaging suggestions can be painful.
Anyway, I do not wish to be an excessive amount of philosophical, this can be a Swift developer weblog ffs.
A number of issues that I realized:
- my concepts usually are not all the time working, so do not belief me 100% (haha) 🤣
- it is all the time higher to code/work in pair with another person
- typically the “padawan” will educate the “grasp” 😉
- an expert qa group can prevent a variety of time
- VIPER is my architectural “silver bullet”, not assortment views
- UICollectionView based mostly kind constructing shouldn’t be working…
- …however the assortment view framework nonetheless rocks for complicated interfaces
- have some devoted time for code cosmetics & refactor
- use view subclasses programmatically (or SwiftUI sooner or later)
So the final level is essentially the most fascinating one, let me clarify why.
Customized view subclasses from code solely
Making a UIView subclass programmatically is a comparatively straightforward job. You possibly can load a nib file or you are able to do it straight from code. A number of weeks in the past I’ve realized a brand new trick, that was bugging me on a regular basis I made a brand new subclass in Swift:
Why the hell do I’ve to implement
init(coder:)if I am not utilizing IB in any respect?
Additionally what the heck is happening with init(body:), I do not wish to cope with these two init strategies anymore, since I am utilizing auto format and I am fully making an attempt to disregard interface builder with the tousled storyboards and nibs as nicely.
class View: UIView {
@accessible(*, unavailable)
override init(body: CGRect) {
tremendous.init(body: body)
self.initialize()
}
@accessible(*, unavailable)
required init?(coder aDecoder: NSCoder) {
tremendous.init(coder: aDecoder)
self.initialize()
}
init() {
tremendous.init(body: .zero)
self.initialize()
}
func initialize() {
self.translatesAutoresizingMaskIntoConstraints = false
}
}The answer: mark these silly init capabilities as unavailable, so no-one can use them anymore. The one supply of fact can be your personal init technique, which is kind of a aid if you happen to had been so irritated concerning the tousled initialization course of like I used to be. 😤
Now you’ve your personal base class that you need to use as a mother or father to your future views. After all you will have to do the identical factor for nearly each UI aspect, like labels, buttons, textual content fields, and so on. That is a variety of work, however on a long run it’s very value it.
import UIKit
class TitleLabel: Label {
override func initialize() {
tremendous.initialize()
self.textAlignment = .heart
self.font = UIFont.preferredFont(forTextStyle: .largeTitle)
self.textColor = .systemBlue
}
func constraints(in view: UIView, padding: CGFloat = 8) -> [NSLayoutConstraint] {
[
self.topAnchor.constraint(equalTo: view.topAnchor, constant: padding),
self.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: padding),
self.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -1 * padding),
]
}
}An excellent observe might be to have subclass for every customized consumer interface part, like the first button, secondary button, title label, header label, and so on. This fashion you do not have to configure your views within the view controller, plus you possibly can put your regularly used constraints into the subclass utilizing some helper strategies.
Additionally you possibly can have some good extensions, these might help you with view configurations. You understand, similar to modifiers in SwiftUI. You possibly can even recreate the very same syntax. The underlying conduct will not be the identical, however that is one other story. 📚
What concerning the kind new builder in iOS?
Oh, yeah virtually forgot. I’ve a model new, however nonetheless very related answer. I am utilizing view subclasses as a substitute of assortment view elements, plus the gathering view have been changed with a UIScrollView + UIStackView mixture. 🐐
class ViewController: UIViewController {
weak var scrollView: ScrollView!
weak var stackView: VerticalStackView!
override func loadView() {
tremendous.loadView()
let scrollView = ScrollView()
self.view.addSubview(scrollView)
self.scrollView = scrollView
NSLayoutConstraint.activate([])
let stackView = VerticalStackView()
self.scrollView.addSubview(stackView)
self.stackView = stackView
NSLayoutConstraint.activate([])
}
override func viewDidLoad() {
tremendous.viewDidLoad()
self.title = "StackForm"
self.navigationController?.navigationBar.prefersLargeTitles = true
let electronic mail = EmailTextField(id: "email-input", placeholder: "E mail")
self.stackView.addArrangedSubview(electronic mail)
let password = PasswordTextField(id: "password-input", placeholder: "Password")
self.stackView.addArrangedSubview(password)
let submit = SubmitButton(id: "submit-button", title: "Submit")
.onTouch { [weak self] _ in self?.submit() }
self.stackView.addArrangedSubview(submit)
}
func submit() {
guard
let electronic mail = (self.view.view(withId: "email-input") as? UITextField)?.textual content,
let password = (self.view.view(withId: "password-input") as? UITextField)?.textual content
else {
return
}
print("Account: (electronic mail) - (password)")
}
}As you possibly can see I am nonetheless utilizing the identical view identification method, plus I nonetheless desire to have the SwiftUI-like .onTouch motion handlers. You would possibly ask although:
Why do not you merely go along with SwiftUI?
Effectively, the factor is that SwiftUI is iOS 13 solely, which is barely round ~55% adoption these days, that is one of many fundamental causes, but additionally SwiftUI is type of incomplete.
I am making an attempt to get as shut as I can to SwiftUI, so the transition can be much less ache within the ass when the time comes. SwiftUI can be superb, however nonetheless it is a big leap ahead. Generally I imagine that Apple is speeding issues simply due to advertising and marketing / developer wants (yeah, we’re very impatient animals). Perhaps a easy wrapper framework round UIKit / AppKit with out the entire declarative syntax would have been a greater thought as a primary step… who is aware of… CoreKit -> AppleKit? 🤔
Anyway, you possibly can obtain a working instance of my newest kind constructing answer in Swift 5 from GitHub. Simply search for the StackForm folder contained in the repository.