Before I updated to Xcode 13 the code below worked fine in another custom UIView created in Xcode 12.
I created this new custom view and the compiler gives the following contradictory errors with reference to the convenience init
Overriding declaration requires an 'override' keyword
'init(frame:)' has already been overridden
Why is Xcode 13 reporting this error in the new custom class but not the identical one created in Xcode 12?
class OptionsPanel: UIView {
override init(frame : CGRect) {
super.init(frame : frame)
}
convenience init(frame: CGRect) {
self.init(frame: frame)
}
required init?(coder: NSCoder) {
fatalError("init(coder:) has not been implemented")
}
}
That was the problem. In the other custom view I had other parameters in the convenience init convenience init(frame: CGRect, packages: [Purchases.Package], testing: Bool).
I did try other parameters in this one thinking it might be the problem but had all sorts of issues with the pods Xcode indexing forever until I created a new project and iPhone 13 simulators not showing up.... so it got lost in all that fire fighting!
Thank you Sweeper, Duncan C & Bhawin Ranpura.
I have been asked to edit by Community.
The problem as exactly as answer given -
The convenience init cannot be identical to init. ie
override init(frame : CGRect) {
super.init(frame : frame)
}
convenience init(frame: CGRect) {
self.init(frame: frame)
}
Is rejected by the compiler.
Related
Hey guys I created a new custom View Class and now I want to build a instance of it, I initialized it with the following code:
required init?(coder aCoder: NSCoder) {
super.init(coder: aCoder)
tapRecognizer = UITapGestureRecognizer(
target: self, action: #selector(handleBarTap))
addGestureRecognizer(tapRecognizer)
}
deinit {
removeGestureRecognizer(tapRecognizer)
}
And this is the instance, but what can I use as coder?
lazy var chartView = TutorialChartView(coder: )
Thanks in advance!
When you say View, do you mean UIView? The problem is that that's the wrong initializer. init(coder:) is not something you call; it's a process initiated by the storyboard when there is one of these things in the storyboard and you load that view controller.
The code UIView designated initializer is init(frame:). Implement that and call it, and you're all set.
(You may also have to provide an implementation of init(coder:) but it should just throw a fatalError, because you do not expect to be called this way.)
You should cannot use coder as initializer for creating class, use frame instead, here is your code written in frame-style initializing.
override init(frame: CGRect) {
super.init(frame: frame)
tapRecognizer = UITapGestureRecognizer(target: self, action: #selector(handleBarTap))
addGestureRecognizer(tapRecognizer)
}
required init?(coder: NSCoder) {
fatalError("init(coder:) has not been implemented")
}
Here is how you use it:
lazy var chartView = TutorialChartView(frame: CGRect(x: 0, y: 0, width: 200, height: 200)
This is my code:
override init(frame: CGRect) {
super.init(frame: frame)
commonInit()
}
required init?(coder: NSCoder) {
super.init(coder: coder)
commonInit()
}
func commonInit() {
let mainBundle = Bundle.main
mainBundle.loadNibNamed("iconView", owner: self, options: nil)
addSubview(contentView)
contentView.frame = self.bounds
contentView.autoresizingMask = [.flexibleWidth, .flexibleHeight]
}
I copied it from step 8 in this tutorial that I've seen (I only changed the name in the code to my xib file: "iconView").
But for some reason it fails:
I already tried all of the solutions in stackoverflow, but nothing helped me.
Here is my xib file:
I really don't know what to do.
I'm using Xcode 12 beta 6, iOS 14 beta 6
UPDATE
Okay, a lot of people saied in the comments of the tutorial that
This causes an infinite-loop calling commonInit().
So now I know what the issue is, but I still don't know how to solve it. Any ideas?
You probably have to remove Class from your View.
First select your View (in your case iconView):
and then clear whatever there is in the class field:
I setup UILabel appearance in my app delegate using:
UILabel.appearance().textColor = UIColor.white
I also have a custom UIView subclass that contains a UILabel along with some other elements (omitted here):
#IBDesignable
class CustomView: UIView {
private let descriptionLabel = HCLabel()
override init(frame: CGRect) {
super.init(frame: frame)
setup()
}
required init?(coder: NSCoder) {
super.init(coder: coder)
}
override func awakeFromNib() {
super.awakeFromNib()
self.setup()
}
private func setup() {
self.descriptionLabel.textColor = UIColor.black
// ... other things not related to descriptionLabel
}
}
If I instantiate CustomView in a storyboard, everything works just fine. If, however, I instantiate it in code, the descriptionLabel is white (appearance color), not black (the color I set). What's going on here? The way I understood it was that if I set a custom color, the appearance color will not be used.
What you're experiencing is simply a matter of the exact timing with which the UIAppearance proxy applies its settings to a new UIView. When are we to suppose it does this? It can't possibly do it before init, because init is the first thing that happens in the life of the UIView. Thus, the order of events is like this:
override init(frame: CGRect) {
super.init(frame: frame)
setup() // black
}
// and some time later, UIAppearance proxy comes along and sets it to white
So your goal is to call setup pretty early in the life of the label — and certainly before the user ever has a chance to see it — but not so early that the UIAppearance proxy acts later. Let's move the call to setup to a bit later in the life of the label:
// some time earlier, UIAppearance proxy sets it to white
override func didMoveToSuperview() {
setup() // black
}
Now we're acting after the appearance proxy has had a chance to act, and so your settings are the last to operate, and they win the day.
We remain in ignorance of how early we could move the call to setup and still come along after the appearance proxy setting has been obeyed. If you have time, you might like to experiment with that. For example, willMoveToSuperview is earlier; if you call setup there (and not in didMoveToSuperview), does that work? Play around and find out!
I am using this module to display an image:
https://github.com/huynguyencong/ImageScrollView/blob/master/Sources/ImageScrollView.swift
I have added it to my project using CocoaPods and I want to change the value of the var "maxScaleFromMinScale". I just cant figure out how.
First I tried to just override the var which is not possible.
I then tried to override the intializers by just copying and overriding the same ones that are overrided by the creator of the module.
override init(frame: CGRect) {
super.init(frame: frame)
}
required public init?(coder aDecoder: NSCoder) {
super.init(coder: aDecoder)
}
That does not work, it gives me an error on the top initializer saying that I am not overriding the designated initializer. It feels like I cannot override it since it is not public like the second one. Correct?
Last thing I tried was to make an extension:
extension ImageScrollView {
public func setMaxScale(scale: CGFloat) {
maxScaleFromMinScale = scale
}
}
That does not work either, maxScaleFromMinScale is an unresolved identifier. This also seems to be because it is an internal var and I do not have access to it (another module). Does this mean that my ONLY option is to copy the whole file and modify the source. Was hoping for a minimal and elegant solution.
If this is the case, why can you override the built in UIKit elements but not this one that I downloaded using CocoaPods.
Yes, you cannot override the variable/function because it's internal. That's the point of access modifiers.
Certain UIKit functions are public so you can override them.
Go to the pod file and unlock the file (It prompts to do that on editing), and change
var maxScaleFromMinScale: CGFloat = 3.0
to
public var maxScaleFromMinScale: CGFloat = 3.0
I'm porting some code from Objc to Swift. And struggling with Swift's initialization life cycle. From a simplified point of view, there are 4 players I'm trying to bring into play here:
An object called a Program. This is my main top level model object at this point. The remaining 3 players all want access to an instance of him.
A ProgramEditController, painted in my main Main.storyboard. He's responsible for instantiating an initial Program, which cannot be done directly as a property initializer.
A top level custom UIView subclass, called ProgramTimelineView. Painted in the Main.storyboard, manages a variety of specialized subviews. Linked to a property of my ViewController. Has properties for the it's subviews as well. It wants access to the Program, so it can do layout and pass it on to subviews.
A particular subview of ProgramTimelineView called ProgramGridView. These are not painted in the XCode canvas tool, but directly instantiated by the containing ProgramTimelineView. It wants access to the Program. Uses it to do his custom drawRect.
Here's the relevant code for my Controller:
class ProgramEditController: UIViewController {
// MARK: - Variables
#IBOutlet var timelineView:ProgramTimelinesView!
var site = Site()
var program:Program!
// MARK: - Initialize
override init(nibName nibNameOrNil: String?, bundle nibBundleOrNil: NSBundle?) {
super.init(nibName: nibNameOrNil, bundle: nibBundleOrNil)
// set up the new program
self.program = self.site.newProgram()
// get it into our top view before it starts drawing
self.timelineView.program = self.program
}
required init?(coder aDecoder: NSCoder) {
super.init(coder: aDecoder) // Why does Swift make me have a redundant thing here?
}
}
And for ProgramTimelinesView:
class ProgramTimelinesView: UIView {
// MARK: - Variables
var gridView = ProgramGridView()
var program:Program! {
didSet {
self.gridView.program = self.program
}
}
// MARK: - Initialization
func addGridView() {
self.gridView.alpha = 0.0
self.gridView.opaque = false
self.addSubview(self.gridView)
}
func commonInit() {
self.addGridView()
}
required init?(coder aDecoder: NSCoder) {
super.init(coder: aDecoder)
self.commonInit()
}
override init(frame: CGRect) {
super.init(frame: frame)
self.commonInit()
}
}
And finally for the ProgramGridView:
class ProgramGridView: TimeAxisView {
// MARK: - Variables
var program:Program!
override func drawRect(rect: CGRect) {
// access self.program in here
}
}
What I thought would happen:
ProgramEditController.init(nibName...) would fire first.
The super call would cause my ProgramTimelineView.init(coder) to fire.
ProgramTimelineView instance would first call the gridView initializer setting it to a new ProgramGridView view
The remainder of ProgramTimelineView.init(coder) would run, which would add the gridView into the view tree.
Control would return to the ProgramEditController.init(nibName) initializers. The controller's program property would be populated.
The bound timelineView would have its program property set.
ProgramTimelineView would in turn set the program property of the gridView.
What seems to happen though, between steps 4 and 5, is that a drawRect() happens. That causes a seg fault, because the gridView's program has not been set yet! But why is it issuing drawRect()'s at this point? I thought that wouldn't happen before all of the initializers had fired. But clearly some side affect is occurring. What is the correct pattern/idiom to employ to avoid this? I really would rather not turn all of the program! into program? and then put let/guards every where.
There turned out to be a faulty assumption in my original premises (usually the case).
UIViewController.init(nib...) is NOT called when creating from interface builder assets. But local variables linked in interface builder (implicitly wrapped) are not set/realized at the point of init(coder) either. The correct approach required two adjustments:
Move the setup of the program var to the init(coder) initializers:
e.g.
required init?(coder aDecoder: NSCoder) {
super.init(coder: aDecoder)
self.program = self.site.newProgram()
}
Forward that to the view in a viewDidLoad() override.
e.g.
override func viewDidLoad() {
super.viewDidLoad()
self.timelineView.program = self.program
}