Due to design Constraints I have to add an UiViewController to UITableViewController through
[controller addChildViewController:self];//self = uiviewcontroller controller = Instance of UITableViewController
[controller.view addSubview:self.view];
It adds it with a bit lag, but I get a warning in my console
"setting the first responder view of the table but we don't know its type (cell/header/footer)"
I guess it is because controller.view is tableview and not normal uiview, it throws this error both in iOS6 and iOS7
How can I add a ChildViewController to UITableViewController?
Short answer: Don't. UITableViewControllers can't really contain anything else but a table view. As rob says in his answer, it's better to have a parent view controller that has a container view with your table view controller in it, plus anything else you need, and perhaps other child view controllers if you need to.
Your quickest fix for the layout you're looking for is to have a parent view controller that includes both your table view controller and the child view controller with the UITextField.
Or just a view controller with a UITableView (with it's data source and delegate set to your view controller) and your child view controller added.
Related
I have three view controllers each under the same custom view controller class, and a page view controller. I want to be able to reuse these three view controllers but with different content on their subviews. However, when I try to instantiate one of these view controllers from the page view controller using [self.storyboard instantiateViewControllerWithIdentifier:identifier], with a method to find the subview by tag right after, the subview returned is null. Is there some way I can get the subview by tag right after instantiating the view controller programmatically?
A view controller's views don't get created until it is about to be displayed. They won't be created after the call to instantiateViewControllerWithIdentifier:
You should put code that accesses the view controllers views in viewDidLoad, viewWillAppear, or viewDidAppear.
You should not try to manipulate a view controller's views from an outside object. That violates the principle of encapsulation, an important principle of object-oriented design. (It also often doesn't work, as you found out.)
If you need do things to the views programmatically you should add one or more public methods to the view controller and call those methods to ask the view controller to make adjustments to its views.
Both the methods add the view as child of parentview and view can receive events. When to use which one?
It all depends on how you want to manage the new subview. If you want the new subview to be managed by the current view's view controller (e.g. you're adding something simple like a few UILabel objects), you simply call addSubview. If, on the other hand, the new subview has its own view controller (i.e. it's sufficiently complicated collection of views, with rich functionality, that you want to encapsulate all of this complexity with its own controller to manage everything this new subview does) then you call addChildViewController to add the new view controller, but then call addSubview, too.
So, note that addChildViewController, itself, does nothing with the views. You generally immediately follow it with calls that add its view, too, e.g. here is a slightly clarified example from the Implementing a Custom Container View Controller section of the View Controller Programming Guide for iOS:
[self addChildViewController:childViewController]; // add subview's view controller
childViewController.view.frame = ... // specify where you want the new subview
[self.view addSubview:childViewController.view]; // now you can add the child view controller's view
[childViewController didMoveToParentViewController:self]; // now tell the child view controller that the adding of it and its views is all done
So, it's not a question of addSubview vs addChildViewController, but rather addSubview vs addChildViewController+addSubview. If you call addChildViewController, you're doing so with the intent of calling addSubview for its view at some point.
Frankly, this question of addSubview vs. addChildViewController+addSubview is rarely how we think about this. A more logical way of thinking of this is determine whether this new view has its own view controller. If it does, you perform the addChildViewController sequence of calls. If not, you just call addSubview.
For a good introduction to view controller containment (e.g. the rationale for that API, the importance of keeping the view hierarchy synchronized with the view controller hierarchy, etc.), see WWDC 2011 video Implementing UIViewController Containment.
They are very different. addChildViewController associates a view controller with a parent container view controller, while addSubview adds a view to the view hierarchy of the view it is being added to. In the former case, the new child view controller will be responsible for handling events when it is the selected view controller of its parent. Think of a tab bar controller--each tab has its own associated "child" view controller that displays its view within the parent tab bar controller's content area and handles any user interaction within that view when its corresponding tab is selected in the tab bar. You should only use addChildViewController when you have a custom container view and want to add a new view controller to its childViewControllers property. If you just want to add a new view to the view hierarchy that can receive events, which is what it kind of sounds like, addSubview is the way to go. "Implementing a Container View Controller" section explains what addChildViewController is for.
addChildViewController is method in UIViewController class and
addSubview is in UIView class
Both have entirely different behavior.
addChildViewController just puts a view controller in front of the current one. You have to manage the flow of controllers. This method is only intended to be called by an implementation of a custom container view controller.
addSubview adds another view as sub view to the view of that object.
Knowing that MVC means Model-View-Controller:
If you only intend to add the view, then use addSubview. e.g. adding a label, button.
However if you intend to a d view + controller then you must use addChildViewController to add its controller and ALSO addSubView to add its view. e.g. adding another viewController, tableViewController.
In addition:
There are two categories of events that are forwarded to child view controllers:
1- Appearance Methods:
- viewWillAppear:
- viewDidAppear:
- viewWillDisappear:
- viewDidDisappear:
2- Rotation Methods:
- willRotateToInterfaceOrientation:duration:
- willAnimateRotationToInterfaceOrientation:duration:
- didRotateFromInterfaceOrientation:
An example of where you would run into an issue if you don't do such is here
For more information I strongly recommend to see answers on this question.
Available from iOS 5, the addChildViewController:
- (void)addChildViewController:(UIViewController *)childController NS_AVAILABLE_IOS(5_0);
method let you add any view controller as a child to some other view controller, but first it removes any parent from the childController and than add it as a child view controller to the specified controller.
The child controller is nothing but an instance of UIViewController and thus it will provide the functionality of view controller (i.e it will receive the events like -(void)viewWillAppear, -(void)viewWillDisappear, etc as a normal UIViewController does).
On the other hand
- (void)addSubview:(UIView *)view;
addSubview: will add any view as subview on any other view.
It's not the choice which to use when rather it's the type which asks to use specific method.
For Instance -
If you have an instance of UIViewController than you will definitely use addChildViewController: (also you can use presentModalViewController, pushViewController) and if you have an instance of UIView than definitely you have to use addSubview.
Note : You can also add view controller's view as a subview to any other view as well.
Based on some test, I found that: If child view controller is not added to parent view controller (supposing the parent view controller is under the root view controller), only child view controller's view is added to parent view controller's view, then:
the sub view controller can still receive messages directly related to view, such as - viewWillAppear:, - viewWillLayoutSubviews, etc.
But
the sub view can not receive some system messages, such as - willRotateToInterfaceOrientation:duration:
I can't give the messages list now, however.
addChildViewController is used to prevent the added sub view controller from releasing, in other word, the parent view controller will hold a strong reference to the sub view controller.
I am building a UIViewController with a XIB. In this XIB, I have placeholders (UIView objects in the XIB) in which I place other views, from other view controllers. (By the way, I could also add these views directly, without placeholders)
I am not buiding a container view controller: I mean it's not a UINavigationController. It's a just a "usual" view controller. Imagine for example that I have a small subview in my view for a "Facebook" logo and a counter. This "facebook view" is attached to another view controller that is called when the "Facebook view" is touched. So, the "Facebook controller" definitely needs to be a #property of my "main" view controller.
In this situation, should I really use addChildViewController: and all the mechanism? Or no?
Thanks!
You should not be using a UIViewController merely to "fish" into a .xib file for you to obtain the view. If that's all you want it for, don't do that. Just load the nib and pull out the view, directly:
NSArray* objects = [[UINib nibWithNibName: #"MyNib" bundle: nil]
instantiateWithOwner:nil options:nil];
UIView* v = (UIView*)[objects firstObject];
But if you are using a UIViewController in conjunction with this .xib file for some other reason, e.g. to keep it alive so that a button inside the .xib can send messages to this UIViewController, then absolutely you must make a proper parent-child relationship, as I describe in my book: http://www.apeth.com/iOSBook/ch19.html#_container_view_controllers
Yes, you should. By doing so, the containing view controller sends proper view controller lifecycle events to the child view controllers.
You say you aren't building a container view controller but you are. Adding the view of another view controller to another view controller is the definition of a container view controller.
See the "Implementing a Container View Controller" section of the docs for UIViewController on the proper sequence of method calls you should make. It's more than just calling addChildViewController.
You can instantiate your insider ViewController, and just add its view (myInsiderViewController.view) to your main viewController:
[mainViewController.view addSubView:myInsiderViewController.view];
I am testing out something I would like to have in my app. I have a UiViewController in a storyboard that has a UIScrollView - I now want to add other viewControllers to this scrollView and swipe between them.
I would like to add a view that I made in the storyboard into this UIScrollView. Is it possible?
I tried something along the lines of:
MYViewController *viewOne = [self.storyboard instantiateViewControllerWithIdentifier:#"myView"];
[self.scrollView addSubview:viewOne.view];
I've set the the scrollView size to be bigger than the screen and when the main view loads, I can see there is a scroll view (the scroll bars show) but my viewController is not inside it.
Anyone have any ideas?
The code you posted is still not right, on a couple of levels.
First, you should not use alloc/init for view controllers. You either need to use initWithNibName:bundle: (to create a view controller from a nib file) or instantiateViewControllerWithIdentifier: to load a view controller from a storyboard.
Second, you should not add a view controller's view as a subview of another view controller unless you use the parent/child view controller support that was added in iOS 5 and greatly improved in iOS 6. If you do what you are doing then all sorts of things won't work correctly: Auto-rotation, low memory warnings, background notifications etc. The list of things that can go wrong is unbounded.
The easiest way to do this is to add a container view as a frame to hold your child view controller, and then control-drag from your container view onto the scene that you want to set up as a child. This causes IB to set up and "Embed" segue. Embed segues do all the housekeeping you need to host one view controller's content inside another, with no code needed.
You could create a container view inside your scroll view's content view, and then it would just work fine.
I found the problem:
I was not allocating and initialising my viewController. Ooops.
This is the correct code:
BaseViewController *viewOne = [[BaseViewController alloc]init];
viewOne = [self.storyboard instantiateViewControllerWithIdentifier:#"myView"];
[self.scrollView addSubview:viewOne.view];
I have encapsulated all my table view logic on a UITableViewController that is linked to a view. This was done using storyboards.
I would like to embed this logic and view within another view controller / view (kind of like a header information with a scrollable table beneath.)
I have the following components:
CustomViewController which is linked to a UIView (dragged in from storyboard)
CustomTableViewController which is linked to a UITableView (dragged in from storyboard)
Essentially I am trying to mimic the scenario of the Stopwatch in the iOS clock app
What is the beast approach to this?
How is it done programatically?
Can this be done on the storyboard somehow?
Any help would be greatly appreciated. Thanks
Ok figured it out. This solution is iOS 5 specific since this feature was added there. This method works with storyboards.
Setup: The intention is to host one view controllers view and logic within another controller.
Since there is no intrinsic way to reference the child view controller in the storyboard, we need to give the view controller a name. This can be done by filling out the "Identifier" attribute on the controller in the storyboard. NOTE: Make sure you are giving the controller the identifier and not the controllers view.
Instantiate the controller you want to aggregate. This can be done from the hosting controller.
UIViewController *controller = [self.storyboard instantiateViewControllerWithIdentifier:#"ControllerIdentifier"];
Add the child controller to the parent controller
[self addChildViewController: controller];
Add the child controllers view to the parent controllers view. Note if you have a place holder view in the parent controller you wish to add the child view to, then this is where you do it. Here I add it the a UIView called stage in the parent controller.
[self clearStage];
[self.stageView addSubview:controller.view];
presentedController.view.frame = self.stageView.bounds;
And that is it. Pretty simple. I have used it successfully with switching controllers and view in a home made tab control. The sub controller enlists its views in the view lifecycle, so the viewDidLoad, etc all work as expected in this child view controller.
Hopes this helps someone.