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.
Related
I'm trying to create an IOS app that has one navigation view controller with several bar buttons, where each button changes the content of the view itself. Most of my views are custom views anyway, so I won't really see any clear previews in the storyboard anyway.
I'm thinking about creating one navigation view controller, and several NIB files to represent each view. Each NIB will have its own class with all the IBOutlets and IBActions.
Then, when a button is clicked in the navigation view controller, just switch to a new view by clearing the old one (removeFromSuperview), and call loadNibNamed to load a new view.
Does this sound reasonable or will all this deserializing be expensive in terms of CPU? Would it be better to just create different viewcontrollers in the storyboard, with segues etc, and copy those nav bar buttons to each view controller?
The simplest solution:
ViewController->
View->
rootViewOne
rootViewTwo
rootViewThree
...
upon your bar button's action,set specific rootView's hidden property to true or false:
self.rootViewOne.hidden = currentIndex == 0
self.rootViewTwo.hidden = currentIndex == 1
self.rootViewThree.hidden = currentIndex == 2
You can add your other view controller/s as child view controller.
In this way, you will have code for different views in their respective view controllers and your main/parent view controller will not be messy.
To add child view controller:
// Get instance of your view controller
UIViewController *childViewController = [UIViewController new];
// Add your view controller as a child view controller
[self addChildViewController:self.loginView];
// Set frame for your childViewController's view
[childViewController.view setFrame:CGRectMake(0.0f, 0.0f, self.view.frame.size.width, self.view.frame.size.height)];
// Add childViewController's view as a subview to your viewcontroller's view
[self.view addSubview:childViewController.view];
// Notify your main/parent controller that a child view controller is being added
[childViewController didMoveToParentViewController:self];
To remove child view controller:
// Notify the childViewController that it will be removed
[childViewController willMoveToParentViewController:nil];
// Remove childViewController's view
[childViewController.view removeFromSuperview];
// Remove childViewController from your main/parent view controller
[childViewController removeFromParentViewController];
Hope this helps.
UPDATE - Embedded swapping by Sandmoose Software:
http://sandmoose.com/post/35714028270/storyboards-with-custom-container-view-controllers
Here's a snippet from the "how-it-works" section:
The segue between ViewController and ContainerViewController is an
embed segue. The segues between ContainerViewController and its two
child view controllers is a custom segue. This custom segue is named
Empty and is a subclass of UIStoryboardSegue. It contains an empty
perform method. The ContainerViewController will take care of moving
the child view controllers into and out of place. However, the fake
segues are needed to create the connections in the storyboard.
If you’re like me you cringe at the thought of having a fake/empty
class like this but the benefit is that it allows us to stay firmly in
the world of storyboard idioms without resorting to programmatically
loading isolated storyboard scenes. It’s one tiny bit of ugliness
which allows us to preserve the usefulness and elegance of
storyboards. The storyboard still visually represents the scenes and
their relationships accurately. We can still use segues to control
what happens.
---------- Old answer below (phfffft!) ------
You pose several different questions here: one regarding custom buttons in the nav bar of a nav controller, another about assigning multiple views to the nav controller, and one about placing the view in separate XIB files, while maintaining IBOutlet connections and such.
The first one calls for a tab bar controller, which you can customize to look in whatever way you deem fit, even like a nav bar (ADC has ready-to-use sample code, "UIKit Catalog (iOS): Creating and Customizing UIKit Controls", which fits your needs).
The second can be done easily in Interface Builder by following any number of instructions freely available on YouTube, at Apple, and elsewhere on the Internet; you'll find it an extremely intuitive process. If you can drag-connect a tab bar controller to a view controller, you can intuit the rest. Otherwise, Apple has sample code for customizing the navigation or transition between views in a single view controller interface. "State Restoration of Child View Controllers" provides the best structure for what you want (just pull out the restoration-related code, and use the rest).
The third is not intuitive at all; and, as far as I know, there are only a couple of sets of instructions that exist for separating views (or other view controllers and their views) from a parent or top-level view controller. Here's one I haven't tried yet, so I'll be interested to hear how it worked for you:
http://digginginswift.com/2015/08/30/making-reusable-views-in-separate-xibs
The technique I use involves creating a storyboard with a single view controller to start, followed by a new view controller embedded in a container view for each of your intended views; then, deleting the view in each of the child view controllers, which leaves place for the views you set up in separate XIBs. They are connected by setting the File's Owner to the parent view controller. I can send you sample code, if you'd like to try a different approach than the aforementioned website offers.
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.
Can any one explain when should we add a UIViewController as ChildViewController?
What is the benefits of adding it as ChildViewController instead of subView?
Please help me to understand the purpose of ChildViewController.
When you add a view controller as child view controller, the parent view controller will hold a strong pointer to the child view controller so it doesn't get released instantly. This does not automatically add child's view to parent's view. So you will have to call them both.
I only used it when I needed to create multiple view controllers to be inserted in another view controller and didn't need to directly access it.
its all about UI and code management if you are using subview to achieve what you want to implement inside your app you need to code for your view inside same viewcontrollers class but something interesting i found by creating childviewcontrollers.
empowered to work on a seprate viewcontroller will invoked along with its parent viewcontroller along with its seprate class.
infinite controllers that will be updated tapping a button.
Creation of childViewControllers can be achived by implementing containerView.
or you must have a look of this link hope its helpful to understand.
I know there is the common practice in iOS development of having one UIViewController presented on the screen whose view is loaded from a XIB which will contain all the UIView subclasses in it.
While I was working on a pretty complex widget for an app, I decided to make the widget subclass a UIViewController instead of a UIView. This was because I thought a UIViewController was essentially a UIView with some helper methods around it. Then I could create a XIB for it (I know UIViews can have their own XIBs too), load the views it contains, place ITS view in the presented parent VC's view, and lay it out.
This works fine so far, but I'm wondering if this is bad practice and if I should just subclass a UIView instead and give it a normal NSObject controller. I am seeing some problems with this and I was wondering if anybody could address concerns I have with this approach?
EDIT NOTE: The widget VC does NOT relate to the VC view it is in and is reusable on ANY screen. So the answer is not subclassing the widget VC with the parent VC. The widget is INSIDE the parent VC, but it is NOT a parent VC.
EDIT NOTE 2: I am NOT using Storyboard. Only Autolayout, XIBs, and ARC.
Why can't we have VC's in VC's?
1) Can VC's be simply dropped into ANOTHER VC's XIB and be loaded easily as a subview?
2) I read here: When to use a UIView vs. a UIViewController on the iPhone?
The top answer explains how the VC controls rotation of the screen and laying out the subviews again, so if you add another VC, then the system will automatically think that THAT is the main VC and will attempt to rotate it instead, causing problems. Is this true? Or is he just talking about if you somehow got into a state where 2 VC's were "presented"? I wasn't sure if his answer applied to VC views that were SUBVIEWS of other VC views.
3) In general is this good practice? It certainly seemed more reasonable as it made loading the subview VC's view much easier.
Thanks!
It's absolutely fine. The answer to your problem is ContainerView.
Container View defines a region within a view controller's view subgraph that can include a child view controller. Create an embed segue from the container view to the child view controller in the storyboard.
You almost got it right. Yes, it's good to make a view controller for what you needed. But you shouldn't just add it's view to the parent view, you should also add the view controller as a child view controller of the first view.
You can add many views controllers as child view controllers of a view controller.
You can learn more about this here.
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];