Mandatory init override in Swift UINavigationController subclass - swift

I'm currently subclassing a UINavigationController for a framework that serves a view controller flow (in a way, like UIImagePickerController do)
Here's an example of my implementation, reduced to be as simple as possible, that can be run in a playground.
import UIKit
public class MyNavigationController: UINavigationController {
public var anyVar: Int?
public init(anyVar: Int) {
let viewController = UIViewController()
super.init(rootViewController: viewController)
self.anyVar = anyVar
}
required public init?(coder aDecoder: NSCoder) {
super.init(coder: aDecoder)
}
}
let navigationController = MyNavigationController(anyVar: 42)
The last line is crashing, with a EXC_BAD_INSTRUCTION. When I run in Xcode, it's tells me at runtime that init(nibName nibNameOrNil: String?, bundle nibBundleOrNil: NSBundle?) was missing.
And if I override the method:
public override init(nibName nibNameOrNil: String?, bundle nibBundleOrNil: NSBundle?) {
super.init(nibName: nibNameOrNil, bundle: nibBundleOrNil)
}
...everything works well: you can try with your own playground.
I can't understand why. It doesn't sounds logic to me.
The UIViewController documentation says:
If you subclass UIViewController, you must call the super implementation of this
method, even if you aren't using a NIB. (As a convenience, the default init method will do this for you,
and specify nil for both of this methods arguments.)
But my init(nibName nibNameOrNil: String?, bundle nibBundleOrNil: NSBundle?) override gets called, from super.init(rootViewController: viewController) initialization!
Without overriding it, I guess the UIViewController's init(nibName:bundle:) should be called, but not.
I still cannot understand why overriding the method and calling super make the program works better. IMO, overriding a method while only calling super.thisMethod is totally useless, it only adds a method call in the call stack.
I must missing something essentials about Swift init methods, but I can't figure out what.

This is happening because of the way how Swift inherits initializers. If you don't declare any of initializers in current class the compiler will inherit all of the initializers from the parent class. But if you override/add new initializers (and you do it with init(anyVar:)) Swift will not automatically inherit initializers from parent classes, so they are not accessible from subclass which is leading to runtime crash.
If you are interested in reasons beyond this behavior you can check out Intermediate Swift section and WWDC 2014 (somewhere around 34-minute mark they are talking about initializers inheritance)

You can assign root after you initiated super class
public class MyNavigationController: UINavigationController {
public var anyVar: Int?
public init(anyVar: Int) {
super.init(nibName: nil, bundle: nil)
viewControllers = [UIViewController()]
self.anyVar = anyVar
}
required public init?(coder aDecoder: NSCoder) {
super.init(coder: aDecoder)
}
}

Related

Why do these NSView swift subclesses allow initialisation to run twice

In the Swift subclasses below, when ChildView(dummy: NSObject()) is called, two different designated initializers for ParentView will be invoked, and the myLayer ivar of ParentView will be initialized twice.
Not that this will not happen in a Playground - that will correctly report that error: MyPlayground.playground:5:31: error: must call a designated initializer of the superclass 'NSView'
However, in an Xcode project (e.g. a Command Line Tool), this will compile and run fine.
I understand a lot of what's going on, and how to prevent this problem. But I'd love to understand why the compiler is not erroring, or at least warning me about this code (and preventing the double initialisation)
This code compiles cleanly under Swift 4.2, and in the debugger, I can see exactly what's happening:
When ChildView(dummy:) is called, it invokes ParentView(dummy:)
That's a designated initialiser, do the ParentView ivars are also initialised (myLayer)
Then ParentView(dummy:) calls super.init(), which is NSView.init()
The implementation of NSView.init() calls initWithFrame, so ChildView.init(frame:) gets invoked, and invokes ParentView.init(frame:). That's also a designated initialiser, so
myLayer gets initialised a second time.
To demonstrate this, given the classes below, invoke
let _ = ChildView(dummy: NSObject)
>>>> creating layer will get printed twice.
The way to avoid this would be to have ParentView(dummy:) call super.init(frame:), and then the problem goes away.
My question is really, how could this ever happen in the first place?
import Cocoa
class ParentView: NSView {
private var myLayer: CALayer = {
print(">>>> creating layer")
return CALayer()
}()
override init(frame frameRect: NSRect) { super.init(frame: frameRect) }
required init?(coder decoder: NSCoder) { super.init(coder: decoder) }
init(dummy: AnyObject?) { self.init() }
}
class ChildView: ParentView {
override init(frame frameRect: NSRect) { super.init(frame: frameRect) }
required init?(coder decoder: NSCoder) { super.init(coder: decoder) }
override init(dummy: AnyObject?) { super.init(dummy: dummy) }
}
This should generate a compile time error, as it does in a Playground.
I can't seem to construct a similar non-NSView class hierarchy that gives the same behaviour. No matter how I tweak the hierarchy, constructors, etc., Swift always gives compiler errors when I try to this with new objects (even when I mix Objective-C and Swift, to be analagous to NSView.
I can't find any public declaration for NSView.init() either, although I can see it executing in the debugger.

What initializer called in convenience init of UIViewController?

I often use convenience init in UIViewController to make custom initializer.
But I don't know what existing initializer of UIViewController being called when self.init().
Is it public init(nibName nibNameOrNil: String?, bundle nibBundleOrNil: Bundle?)?
What is called when self.init() in convenience init of UIViewController?
final class SampleViewController: UIViewController {
private var component: Component?
convenience init(component: Component) { // Custom initializer
self.init() // What is this initializer?
self.component = component
}
override func viewDidLoad() {
...
}
...
}
UIViewController.init calls UIViewController.init(nibName: nil, bundle: nil). That means that the nibName will be equal to the name of the class and bundle will be the main bundle.
UIViewController.init is just a convenience initializer. In swift this could be implemented using default parameters UIViewController.init(nibName: String? = nil, bundle: NSBundle? = nil) but this is an old Objective-C API and Objective-C does not have default parameters and that's why there is a separate convenience init().
It depends on how the UIViewController is instantiated.
It could be init(nibName: String?, bundle: Bundle?) when that is called directly through code or init?(coder: NSCoder) if instantiated through Interface Builder mechanisms (Storyboard Segue, Main View Controller, etc.)

NSWindowController designated initializer puzzle

I'm trying to make this code work:
class MyWindowController: NSWindowController
{
let thing: Thing
convenience init(thing: Thing)
{
self.thing = thing
super.init(windowNibName: NSNib.Name(rawValue: "MyNib"))
}
}
The problem, of course, is that a convenience initializer can't call init from a superclass. So how do I initialize my thing and still be able to call init(windowNibName:), which is itself a convenience initializer? I'd rather not have to re-implement the nib loading myself, but how do I avoid it if I can only use designated initializers?
According to the NSWindowController documentation:
You can also implement an NSWindowController subclass to avoid requiring client code to get the corresponding nib's filename and pass it to init(windowNibName:) or init(windowNibName:owner:) when instantiating the window controller. The best way to do this is to override windowNibName to return the nib's filename and instantiate the window controller by passing nil to init(window:). Using the init(window:) designated initializer simplifies compliance with Swift initializer requirements.
You can implement your class as:
class MyWindowController: NSWindowController
{
let thing: Thing
override var windowNibName: NSNib.Name? {
return NSNib.Name(rawValue: "MyNib")
}
init(thing: Thing) {
self.thing = thing
super.init(window: nil)
}
required init?(coder: NSCoder) {
fatalError("init(coder:) has not been implemented")
}
}

Idiomatic pattern to initialize UIViews in Swift

In Objective-C I had evolved the pattern of having both an awakeFromNib and initWithFrame: method which invoked their super's and then called a _commonInit where I put all my own code. E.g.
- (void)_commonInit {
// Initialize stuff here
}
- (id)initWithFrame:(CGRect)frame
{
self = [super initWithFrame:frame];
if (self) {
[self _commonInit];
}
return self;
}
- (void)awakeFromNib {
[super awakeFromNib];
[self _commonInit];
}
So I'm trying to reuse this pattern in my UIView subclasses that I'm porting to Swift:
func _commonInit() {
// initialize code here
}
override init(frame:CGRect) {
super.init(frame:frame)
self._commonInit()
}
required init(coder aDecoder: NSCoder) {
super.init(coder: aDecoder)
}
override func awakeFromNib() {
super.awakeFromNib()
self._commonInit()
}
Is this the right way to do it? I'm curious why the init(coder...) is required. Especially when all I do is call the super version. I seem to recall that the reason I used awakeFromNib in the Objc version was because any changes applied from nib restoration didn't happen until sometime later than initFromCoder:.
Having a commonInit method that gets called from your initializers is a perfectly fine pattern for cases where you have more than one designated (or required) initializer. It's not the only pattern, though.
To address each of your doubts in turn (and add some related points)...
init(coder:) is required because you're subclassing a class that declares conformance to the NSCoding protocol. That protocol demands that all instances of all subclasses be able to initialize from an archive.
You don't actually have to do anything in init(coder:) unless you save state in encodeWithCoder(_:), though. But because it's possible for a subclass to have encodable state that's not inherited, initialization safety requires that the subclass be responsible for this initializer (even if all it does is call super).
You use awakeFromNib() in any custom class loaded from a nib/storyboard to take care of initialization that needs to happen only after an object's outlets and actions have been hooked up.
When Cocoa (Touch) loads a nib, it first initializes each object (with init(coder:)), then after all the objects are "live", it connects all the IBOutlet variables and the targets for all of the IBActions sent by controls. After all that's done, it calls awakeFromNib().
There's a caveat—a paradox, even—to using the commonInit pattern in Swift: You must initialize properties (aka instance variables) before calling super.init(), and you can't access self (including to call methods on self) until after calling super.init(). So you can't have a commonInit method that sets the initial values of properties.
You can have properties whose types are implicitly unwrapped optionals. Those are automatically initialized to nil, and then you can set a "real" initial value in your commonInit method:
var name: String!
init(frame: CGRect) {
super.init(frame: frame)
self.commonInit()
}
init(coder: NSCoder) {
super.init(coder: coder)
self.commonInit()
}
private func commonInit() {
name = // something...
}
An alternative pattern that gets around this issue is to supply initializers (or even lazy initializers) for each of your properties. If you do this, you don't need a commonInit method, because the property initializers will be implicitly called from whichever init actually gets used (or in the case of lazy initializers, when the property is first accessed).
class MyView: UIView {
let fileManager = NSFileManager.defaultManager()
let appDelegate = UIApplication.sharedApplication().delegate as! MyAppDelegate
lazy var name: String = { /* compute here */ }()
init(frame: CGRect) { super.init(frame: frame) }
init(coder: NSCoder) { super.init(coder: coder) }
// ...
}
Finally, if you do provide a commonInit (or similar) method, you don't need to mangle the name with an initial underscore or anything—Swift has built-in access control, so any methods you don't want exposed to callers outside of a class can simply be marked private.

Instantiating and pushing view controller programmatically with custom initializer swift

I want to present a detail view controller in swift like so
let detailController = MyDetailUIViewController(nibName: "MyDetailUIViewController", bundle: NSBundle.mainBundle(), data:myData)
self.navigationController?.pushViewController(detailController, animated:true)
The issue I am having is how to write my initializer for MyDetailViewController:
class MyDetailUIViewController: UIViewController {
private var data: MyData
init(nibName nibNameOrNil: String!, bundle nibBundleOrNil: NSBundle!, data:MyData) {
self.data = data
super.init(nibName: nibNameOrNil, bundle: nibBundleOrNil)
}
required init(coder aDecoder: NSCoder) {
super.init(coder: aDecoder)
}
I am getting an error that my data property is not initialized at super.init call. Can anyone explain how I can accomplish this? I am sure I could make my data property optional and pass that in after initialization, but surely there is a way to make this work.
If you declare your data variable to be non-optional, you have to make sure that all init methods initialize it. This is not the case in your class, since
required init(coder aDecoder: NSCoder) {
super.init(coder: aDecoder)
}
does not initalize your data.
If your declare your initialize as convenience init() then you will not have to declare an implementation for init(coder:) this may solve your problem as well.