I learned a very painful lesson about how to ensure your outlets are nil on a view controller's viewDidLoad, and that's by writing an initWith... method of your own.
-(id)initWithDoohickey:(SomeDoohickey*)doohickey
{
self = [super init];
if (self)
{
theDoohickey = doohickey;
}
return nil;
}
Now when you call this method, instead of initWithNibName, or simply init, your view outlets will be nil, and you'll run into all kinds of debugging nightmares.
So I see two solutions here...
(1) Call init or initWithNibName and let it do it's thing, and follow that with a classInQuestion configureWithDoohickey:(SomeDoohickey*)doohickey
or (2)
figure out how to properly write an initWith... method that actually loads the nib properly, while also allowing me to pass in whatever config variables I want in the same call.
I'd like to know how to do (2).
Simply replace your call to [super init]; with a call to [super initWithNibName:...];.
Obviously you need to pass in the correct arguments.
The problem you have is that you didn't properly chain the initializers. A subclass's initialization process must (eventually) call its superclass's designated initializer. The designated initializer ensures that all of a class's data is correctly set up.
If you don't call the superclass's DI, it's not able to set the properties that were defined in the superclass.
The simple init that you're using is not UIViewController's designated intializer; initWithNibName:bundle: is. As rmaddy said, that is the method you should use in your subclass's own designated intializer.
Initializers in the subclass can use each other, as long as one of them eventually passes up to the superclass's DI.
(As an aside, this relationship has been formalized in Swift. Initializer chaining is actually part of the language, rather than just a convention. This can be confusing, but interestingly, the way you wrote initWithDoohickey: would not have even compiled in Swift.)
Related
In earlier versions of Xcode, when I create a new subclass of UIView the code below is automatically generated in the implementation file:
- (id)initWithFrame:(CGRect)frame
{
self = [super initWithFrame:frame];
if (self) {
// Initialization code...
}
return self;
}
I'm trying to reacquaint myself with it again and now it seems it's not automatically generated anymore. Is there a reason for that? Is this not the proper way of doing it anymore?
Thanks!
...now it seems it's not automatically generated anymore. Is there a reason for that? Is this not the proper way of doing it anymore?
The "generated" code really just comes from a template file, and all that has happened is that the template file changed at some point. -initWithFrame: and -iniWithCoder: are still both valid default initializers for UIView, and you should override one or both of them in your class if they're needed.
I don't know the actual reason behind the change to the template, but perhaps it was because there's nothing particularly special about the initializer methods compared to the various other methods in UIView that can be overridden. Nearly every UIView subclass needs to override -drawRect:, so it makes sense to include that in the template, but that's not true for -initWithFrame: or -initWithCoder:.
I do not think that there is a "hard" reason. Keep in mind that such autogenerated code is for convenience.
However, there might be two reasons:
A. You cannot say whether this is an useful initializer for your view subclass. That's guessing. Typically it is a good idea to give the initializer as much properties as possible.
B. If you have an initializer with more args, this is typically the designated initializer. In such a case the generated code is simply wrong, because -initWithFrame: becomes a secondary initializer and has to execute the designated initializer. It is no good idea to generate wrong code.
But this is guessing, too.
I'm just curious, when it comes to initializing UIViews; I notice that when I call the instance constructor -(id)initWithFrame:(CGRect)frame, the primitive constructor -(id)init is never actually called, meaning that I would have to initialize instance variables in both constructors. Is this meant to be an optimization strategy such that calling -(id)initWithFrame:(CGRect)frame is computationally "faster" (encourage better performance) than calling UIView *view = [UIView new]; view.frame = frame;? Is the initWithFrame option quicker than creating a new instance and assigning its frame manually? I actually prefer to do the latter to maintain programmatic consistency.
No it's simply that initWithFrame is the designated initializer of UIView (from the class reference):
Discussion
The new view object must be inserted into the view
hierarchy of a window before it can be used. If you create a view
object programmatically, this method is the designated initializer for
the UIView class. Subclasses can override this method to perform any
custom initialization but must call super at the beginning of their
implementation.
This question already has answers here:
Is it possible to make the -init method private in Objective-C?
(9 answers)
how to block a superclass method to be called to a subclass
(5 answers)
Closed 9 years ago.
Suppose you have a UIView subclass. You define an init method "myInitWithFrame: ... andWhatNot:...". You know you won't be using the init method inherited from UIView ever and your custom init method does some vital custom initialising so that you want to force client classes to never use the inherited initWithFrame method.
Is it possible to hide the standard initWithFrame method that was inherited from UIView?
Actually, you can get compile-time warnings about calling a method on a subclass. Use the __attribute((deprecated)) attribute. If you want people to use -initWithPizza: instead of -initWithFrame:, do this:
#interface MyView : UIView
- (id)initWithPizza:(MyPizza *)pizza;
#end
#interface MyView (Deprecations)
- (id)initWithFrame:(CGRect)frame __attribute((deprecated("Use initWithPizza: instead")));
#end
Putting the -initWithFrame: declaration in a separate category is necessary to avoid Xcode complaining that you declared the method in the header but didn't implement it. Since you're just inheriting it from the superclass, that's fine; you don't have to implement it at all. But if you want to implement it to throw an exception, or call through to -initWithPizza: with a default argument, that's fine.
Of course, this won't stop UIKit from calling -initWithFrame: if it was already going to do so. But if you can guarantee that won't happen, then you're fine.
Actually, you CAN restrict with a subclass. You can override whichever methods you want to block in your subclass's .h file. You can make initWithFrame unavailable by placing the following in your .h file.
- (id) initWithFrame:(CGRect) frame __attribute__((unavailable("message")));
This will make the initWithFrame: method unavailable to anyone using your subclass.
To keep other code form calling this method, you can further restrict by putting this in your .m file.
- (id) initWithFrame:(CGRect) frame
{
return nil;
}
No. You can't prevent the users of your subclass from calling the methods of a superclass. You could override them and throw an exception inside, but that would just produce a broken subclass.
Remember that inheritance works as an "is a" extension, that is, instances of your subclasses should behave normally in any context that doesn't know about this particular subclass but knows about its superclass. It's only in places that have explicit knowledge about your subclass that you can benefit from adding extra initialization and other methods.
For example, UIKit has no knowledge of your subclass. So if you want to make your UIView subclass available from a NIB, you need to use the initialization methods that will be called by the NIB loading system, namely initWithCoder:. You can simply call your own initialization methods inside initWithCoder:. But if there are any additional parameters you would like to pass to the init method, you'll have to provide a way to configure them after initialization.
My initial view controller is loaded, and I need an NSArray to be init'd, should I take care of this in an awakeFromNib method or an initWithCoder: method? awakeFromNib seems to work nicer, as I don't need to return anything, but it works as nib files were what used to be used right? I don't want to use a method that will break soon.
And would initWithCoder: just look like:
- (id)initWithCoder:(NSCoder *)decoder {
if (self = [super initWithCoder:decoder]) {
self.articles = [[NSMutableArray alloc] init];
}
return self;
}
The point of -awakeFromNib is so that you can do init stuff when you can be sure that all your connections to other objects in the nib have been established.
The nib-loading infrastructure sends an awakeFromNib message to each
object recreated from a nib archive, but only after all the objects in
the archive have been loaded and initialized. When an object receives
an awakeFromNib message, it is guaranteed to have all its outlet and
action connections already established.
Don't forget to call super.
It is unlikely to go away any time soon, and if it did so much code uses it that the transition period would be long. Yes its name comes from the old "nib" file format but this stack overflow question clears up the differences in the file extensions.
So in summary either method will work for you as you are setting an internal instance variable for the class. Note that inside init methods (including -initWithCoder) it may not be safe to use your setter methods in case setters rely on the class being fully initialised (source WWDC 2012 video moving to modern objective-c). An example would be setting a property that references another object in the nib file.
In UIViewController subclasses -initWithCoder is only called when loading from a storyboard. As -awakeFromNib is called whether you use storyboards or not it might make more sense to use that.
Another pattern you could consider is the lazy-getter:
- (NSMutableArray *)articles{
if (_articles){
return _articles;
}
_articles = [[NSMutableArray alloc] init];
return _articles;
}
The benefit of this approach is that if you wanted to do further setup to the array you can easily discard the array when you don't need it anymore and the next time you access the property you have a fresh one again.
I am converting an iPhone app to a Universal app. I have a NIB view which I want to use on the iPad as is but resized and positioned. On the iPhone I am initializing normally with initWithNibName...
EventEditViewController *eventEditViewController = [[EventEditViewController alloc] initWithNibName:#"EventEditViewController" bundle:nil];
I found that this did not work well for me on the iPad for various reasons. So I created my own initialization method to call instead when running on the iPad...
EventEditViewController *eventEditViewControllerForIPad = [[EventEditViewController alloc] initWithFrame:iPadFrame eventDate:longDate event:eventName delegate:self];
This solved a couple of problems. One how to resize and position the view where I wanted it and how to properly initialize certain variables. I am actually passing more variables than you see here.
It works really well, but I just now noticed that, unlike initWithNibName viewDidLoad fires before my initWithFrame method. I only found this out because a variable I was trying to access in viewDidLoad was showing up as a zombie and I thought I was initializing it in my initWithFrame method.
I was surprised by this behavior. Is it normal? It doesn't make sense to me that the view would be loaded before the named initMethod in the alloc/init call.
I am now wondering if what I am doing might not be a good thing. Like I said it works really well, but should I not use my own initialization method here?
If it's ok to do it this way, maybe someone can explain why the view loads before the init method.
Thanks,
John
If your -initWithFrame:... method is accessing the view controller's view property, -viewDidLoad will be called before the init method completes because the view accessor will cause the view to be loaded.
As for whether it's okay to use your own method, it should be fine provided that your init method calls the designated initializer for the class.
Initializing member variables should be done in viewDidLoad or awakeFromNib.
awakeFromNib is the first method that gets called when a view comes to life from a Xib.
It's preferred to use viewDidLoad for allocating memory for huge arrays since you can deallocate them in viewDidUnload.
Both navigation controller and tab bar controller uses view loading methods to unload views when other views demand more memory.
Allocating in anyother methods should be avoided as far as possible.
From Apple's PageControl source code
// load the view nib and initialize the pageNumber ivar
- (id)initWithPageNumber:(int)page
{
if (self = [super initWithNibName:#"MyView" bundle:nil])
{
pageNumber = page;
}
return self;
}
You can have your own custom init method defined in that EventEditViewController and you can use a custom method like above to initialize your viewController and set as many member variables as you want like iPadFrame, longDate, eventName etc in your case.
Just make sure you call it exactly as above as it's important to call super implementation in such custom init methods.
Also just to shed more light on where you should release arrays you created in viewDidLoad method, it's the dealloc method first in addition to viewDidUnload. The reason behind this is viewDidUnload method doesn't always get called. It gets called only when application starts receiving memory warnings. As compared to this, the method dealloc gets automatically called always when you release the initialized viewController and it's retain count reaches 0. You should release the arrays you initialized viewDidLoad method and your other retain properties in dealloc method.
Also keep in mind that when the app receives memory warning, it's actually a chance to free up additional memory. Also the viewDidUnload method gets called for all the viewControllers in memory except visible one at that time.