Ran into something interesting, want to know if I'm doing something wrong or if this is the correct behavior.
I have a custom UITableViewController. I ASSUMED (first mistake) that if you initialize as such:
[[CustomTableController alloc] init];
it would automatically load from a XIB of the same name, CustomTableController.xib, if it is in the same directory and such.
HOWEVER
This does not work; doesn't load the XIB. BUT, if I change the parent class of my controller from 'UITableViewController' to 'UIViewController', EVERYHTING WORKS FINE!
Calling:
[[CustomTableController alloc] init];
loads the controller and view from my xib.
Am I doing something wrong? Is this a bug? Expected behavior?
Most of the classes in Cocoa Touch list a "designated initializer" that you're supposed to call from your init methods when you subclass them. When you create your own custom class, it's a good idea to check the documentation to find the designated initializer for your superclass. When you initialize the class using some other initializer from a more general superclass (which you're doing by calling - [NSObject init] in this case), you rob your direct superclass of its opportunity to properly initialize its state. Sometimes you can get away with this. Often you can't.
UIViewController's documentation states that its designated initializer is -initWithNibName:bundle:. If you call this method with a nil nibName, it will look for a nib that matches your class name. The behavior of -init is undocumented for UIViewController. Based on the behavior you're seeing, it seems like it may be calling [self initWithNibName:nil bundle:nil], but it would be safer to call initWithNibName:bundle: directly rather than relying on this undocumented behavior.
UITableViewController only defines a single initializer, -initWithStyle: (although it doesn't specify this method as the designated initializer). This method initializes your UITableViewController without using a nib, which is usually fine. Since you don't add subviews to a UITableView, there usually isn't much to be gained by configuring your UITableViewController via a nib.
If decide you want to configure your UITableViewController via a nib anyway, the documentation tells us that we can safely bypass -initWithStyle: and call UIViewController's initWithNibName:bundle: method. Here is what the documentation tells us about how our UITableView and its controller will be initialized in each case:
If a nib file is specified via the initWithNibName:bundle: method (which is declared by the superclass UIViewController), UITableViewController loads the table view archived in the nib file. Otherwise, it creates an unconfigured UITableView object with the correct dimensions and autoresize mask. You can access this view through the tableView property.
If a nib file containing the table view is loaded, the data source and delegate become those objects defined in the nib file (if any). If no nib file is specified or if the nib file defines no data source or delegate, UITableViewController sets the data source and the delegate of the table view to self.
In summary, the documentation for most Cocoa Touch classes either specify a single designated initializer or a handful of initializers that you can call safely from your subclasses. Always refer to the documentation for your superclass to figure out which initializer your subclass should call.
Related
I have a main window which has the UITabViewController as its root controller. I am using a nib file for this. In Interface Builder, two of the tabs have been wired to Controller_A, Nib_A and Controller_B, Nib_B but the 3rd tab only knows about Controller_C.
I assumed that this would mean that the loadView method of Controller_C would be automatically called since I haven't bothered to specify the NIB file. I want to lay this piece out programmatically. And it DOES indeed get called as I've confirmed by placing a breakpoint inside this method.
BUT when I switched over to Controller_C in the simulator, it comes up empty!
Here's what the loadView of Controller_C looks like:
- (void)loadView
{
[super loadView];
...
[self setTableView:formTableView];
[view addSubview:formTableView];
[self setView:view];
}
Any tips? What am I ignoring?
Looks like you are searching for:
-(void)viewDidLoad {
Here are the main things to check.
Click on your Controller_C in interface builder. In the Identity Inspector, make sure that the Class field is set to Controller_C.
In the Attributes Inspector, make sure the NIB Name field is blank.
If you have an existing Controller_C.xib laying around in your project, remove and delete it. The default implementation of loadView loads this file even if
Remove [super loadView]. Since you're building your view hierarchy in code, you shouldn't invoke the default implementation. You should explicitly allocate the controller's view as a local variable in loadView and set it using setView:.
Also, your comment on the other answer suggests that you may be confused about when/why loadView and initWithNibName:bundle: get called, so let me clarify:
loadView gets called to lazy load your controller's view the first time its view property gets accessed. This is true whether your view controller was constructed as an object in a NIB, or whether you constructed it yourself in code using initWithNibName:bundle:. The default implementation of loadView loads the NIB that was specified in initWithNibName:bundle: or in the NIB Name property in IB. If a NIB name wasn't specified, the default implementation looks for any NIB in the bundle that has the same name as your class and loads that NIB if one is found. If no appropriate NIB is found, then the default implementation of loadView just creates an empty view and sets that as your controller's view. When we build our own view hierarchy explicitly in loadView, we don't want any of these default behaviors, so we don't call [super loadView].
It seems loadView works as expected, the reason that my view was blank is because the datasource for my tableview was actually NIL. Earlier, I did not consider this scenario as I thought that it would at least present an empty table in such a case but apparently that was an incorrect assumption on my part. All this mistakenly led me to believe that the view wasn't being initialized properly.
#cduhn: Thanks, I had been following steps 1-3 already and it was really good to hear someone else give the same advice. The rest of what you said was educational for me as well.
Thanks Everyone.
I have a UIView subclass which currently assembles itself completely programatically. It has a custom initWithFrame:bundle: initializer which is necessary because it uses the bundle passed in to load image resources.
I want to make this view a subview in a larger nib file, but then initWithCoder will be called when the nib loading code gets to it instead of my custom initializer. Is there any way I can place this view in a nib and still have my custom initialization occur?
Yes, you can override initWithCoder: too if your bundle is known ahead of time (read: You don't need it passed in as a parameter). Otherwise, nope.
If you can wait until awakeFromNib, you can do your initialization in there. You still have the problem of not being able to pass the bundle into the method, though. Since awakeFromNib is called after initialization and setup of all outlets and actions, it might be too late for you. Maybe it's better to redesign around the nib-loading system anyway?
I am loading a UIView from a NIB file with outlets and I want to change the properties of these outlets. I am wondering when I should do that because in the init method the outlets are nil and that make sense and in the drawRect method I can change the properties of my outlets but I'm not sure it's the proper way to do that.
Is there a method called after the init method and the drawRect method where I could do what I want ?
Thank you.
There's layoutSubviews - this will definitely be called before the first call to drawRect?
The UIViewController method viewDidLoad is called after a nib has been loaded and after loadView is called. (loadView allows you to load a view programmatically instead of using a nib. However, nibs are much better so it's best to pretend that loadView doesn't exist.)
NSObject implements awakeFromNib. awakeFromNib is called after an object has been loaded from a nib. Here's a quote from the docs:
Typically, you implement awakeFromNib for objects that require additional set up that cannot be done at design time. For example, you might use this method to customize the default configuration of any controls to match user preferences or the values in other controls. You might also use it to restore individual controls to some previous state of your application.
drawRect: is a UIView method, only use it if you need to do Quartz drawing. Using layers and Core Animation is more efficient. If you want to configure a custom UIView (i.e. you've subclassed UIView instead of configuring a view within a UIViewController) then you should use initWithCoder:.
If you want to use IBOutlets in your initialization code for a UIView - override awakeFromNib. This is the first method called after outlets have been configured.
With regard to UIViewController - viewDidLoad and viewDidAppear are often convenient locations to put your initialization code in but beware: autolayout has not happened at this stage which means strange autoresizing effects can cause you bother. The better solution is to put your code in viewDidLayoutSubviews which is the first lifecycle method called after autolayout.
Can anyone please explain me about when to use the initWithNibName and when to use initWithCoder?
initWithNibName: is usually used with a view controller object. The idea is that you have a NIB file (or XIB, same thing) that has a UIView (or NSView) you've already designed in Interface Builder. When your view controller launches, it has a view property and outlet that you would have to draw yourself -- except that you've already designed it in IB. So this constructor allows you to fire up the new controller object and tells it in which NIB file to look for its view. Discussion of wiring your NIB itself to make sure this is successful is a little beyond the topic here.
initWithCoder: has another task altogether. When you have serialized an object using encodeWithCoder:, you will eventually need to unserialize (or, "decode") that data to turn it back into an object of your class.
Anyway, to recap: You would implement encodeWithCoder: and initWithCoder: on your class only if you wanted your object to support the NSCoding protocol. You use initWithNibName: (typically you don't implement it yourself) when you want to fire up an object that can initialize its properties with objects archived in a NIB file.
There's a really great over-view of NSCoding over here.
Storyboard
You should prefer -initWithCoder: to -initWithNibName since only the former is invoked when loading a view from Storyboard.
From Apple's Documentation:
InitWithCoder encodes an object for archiving. A coder instructs the object to do so by invoking encodeWithCoder: or initWithCoder:. encodeWithCoder: instructs the object to encode its instance variables to the coder provided...
InitWithNibName Returns an NSNib object initialized to the nib file in the specified bundle. After the nib file has been loaded, the NSNib object uses the bundle’s resource map to locate additional resources referenced by the nib. If you specified nil for the bundle parameter, the NSNib object looks for those resources in the bundle associated with the class of the nib file’s owner instead. If the nib file does not have an owner, the NSNib object looks for additional resources in the application’s main bundle.
The former is used for encoding individual objects in your code, the latter is used to retrieve a NSNib file containing resource objects.
I've created a view controller and the associated view using the interface builder. I'm trying to call a function that I added to the UIView from the UIViewController. I'm not sure how to call that function though.
I've tried
[self.view myFunction]
but that just makes my program crash.
Did you declare your IB outlets and connect the method to it?
Your view (more accurately nib)'s file owner should be set to your viewController class.
Unless your calling drawing functions and methods you shouldn't call anything on the view. You just don't need to.
Edit: grammar corrections.
How is the view getting initialized? Is it a custom view type? If your view is being initialized from a nib, make sure that the class on the view type is the class that has the method implemented.
It is probably crashing because UIView does not have a method named myFunction. In order to add myFunction to a UIView object, you need to subclass it.
I assume you have subclassed your UIView, and called it something like MyView. You also probably have subclassed your UIViewController and called it MyUIViewController. Therefore you may have:
#interface MyViewController : UIViewController {
MyView *myView;
....
}
Now you can call [self.myView myFunction];
That's one way. Another way may be:
[(MyView *)self.view myFunction];
This depends on whether myView is the first view in the hierarchy (or should be set up in your NIB files).