I'm having some problems because I don't know how it can be done. Someone help me please.
Problem:
I have a project with a UIViewController class with created all time when I create a new project in Xcode. In this viewController, I have a xib file for designing in Xcode.
What I need is to create some views and design them in Interface Builder like this:
But I need these views to be UIViewControllers, not UIViews.
The project should look like:
So I don't know how I can do this in IB but I can do it from source code in ViewController.m
tab = [[TabBarController alloc] initWithNibName:#"mytestview" bundle:nil];
[tab.view setFrame:CGRectMake(100, 100, 400, 600)];
[self.view addSubview:tab.view];
But it's not my views it's a different object, and if I want to change position or size I must do it from code. How I can do same things in Interface Builder?
Let's consider following example based on Master-Detailed Application for iPhone only.
So, add new view controller in newly created project in Xcode:
I called it NewInsideViewController. Create it without xib:
Open DetailViewController.xib. Drag View Controller and View(*) objects from library to Objects area like this (I changed view's color to LightGray):
Choose this View Controller and change its Class from UIViewController to NewInsideController at the Identity Inspector:
Assign our View(*) to NewInsideController as a view:
Now all main actions in IB finished. We need to create instance of NewInsideController in our DetailViewController. You can do it by hand, but Xcode has a nice feature - drag-n-drop ;)
I called this property as myNewInsideController and DetailViewController.h looks like this:
#import <UIKit/UIKit.h>
#import "NewInsideController.h"
#interface DetailViewController : UIViewController
#property (strong, nonatomic) id detailItem;
#property (strong, nonatomic) IBOutlet NewInsideController *myNewInsideController;
#property (strong, nonatomic) IBOutlet UILabel *detailDescriptionLabel;
#end
Well, now our NewInsideController ready to work and manage its view. Let's add button and action to that view in order to verify this:
Write some code in IBAction in NewInsideController.
- (IBAction)insideButtonClick:(id)sender {
float rPart = arc4random()%100/100.0f;
float gPart = arc4random()%100/100.0f;
self.view.backgroundColor = [UIColor colorWithRed:rPart green:gPart blue:0.5f alpha:1.0f];
}
Run program.
If I understand the question clearly:
You have a parent view and controller, coming from a XIB.
You have placed subviews into the parent view.
You're wanting each subview placed into the parent view to have it's own (custom) controller, but you don't know how to add view controller's to your hierarchy (XCode will not let you drag view controllers into a view's canvas).
So, to answer the question succinctly: Let's assume you have a handful of custom UIViewController's in your project (each view controller consisting of a .h and a .m). Remember that you if you are laying these out in the context of the parent, they shouldn't have their own XIBs (you cannot nest XIBs in IB). What is important to note here is that you should only "layout" the interface in one location. If you want to have a XIB for each subview, this is not the correct approach. What you can (not should) do, however, is have several custom viewControllers, each connected to it's own view sitting within your parentView, and you can have the outlets of your sub view controller's set to objects in this parentView. Phew, kinda messy. The other thing you'd need to be aware of is that your parent view controller would need a reference to each of it's sub view controllers in order for you to be able to access those sub-controllers and their outlets programmatically, so for each sub view controller you add, you would also need to add an IBOutlet in your parent view controller pointing to each subviewController:
ParentViewController.h
#property (nonatomic, weak) IBOutlet CustomUIViewController *firstCustomController;
And then for example to set the background color on the view of your first custom subview/controller:
ParentViewController.m
[[[self firstCustomController] view] setBackgroundColor:[UIColor whiteColor]];
Open up your parent view controller in IB. If you look in your drawer of available objects, you'll find a generic UIViewController object. Drag this into your parent view controller (NOT onto it's views canvas, rather into the parent UIViewController object itself as seen in the left-column of IB builder). Select the generic view controller you've added and set it's class to your desired UIViewController subclass. Now, when your XIB loads, it will instantiate an instance of your custom view controller along with whatever you've added to it's canvas.
Finally, drag a generic UIView onto your canvas, placing it inside your existing controller's view (your screenshot already shows this as done). Right-click your custom view controller, and connect it's 'view' outlet to the view you added.
Now when you run, your custom view controller has a view that is on the screen that is the view of your custom controller subclass, and you didn't do any of it in code.
So now that you've done it, consider whether or not it is the best choice: Nested view controllers are messy to build (as you've seen) and aren't necessarily a good design decision: http://blog.carbonfive.com/2011/03/09/abusing-uiviewcontrollers/
Although iOS5 does support nested view controllers, personally I'd avoid using them. I value a best practice dictating one screen = one view controller.
You never, EVER, want to take views which are already under the control of a certain view controller, and make them subviews of another view controller's view.
View Controllers are the C part in the MVC design pattern - They are in charge of controlling a view (and its subviews). You can't take a view which is being managed by a controller, and stick it as a subview of a different controller's view - If you do that, it becomes ambigous who is responsible to manage this view.
Even though this "sticking" might be possible technically, it creates code which is hard to understand, hard to maintain, and most importantly - will cause bugs due to the unclarity of who is responsible to manage the view, and due to the fact that Apple's View/Controller framework doesn't support this.
For example: If the device is low on memory, Apple makes sure to unload views which are not currently displayed. Apple relies on the view controllers hierarchy to know when it can unload views. If you stick the view controller's view in another view controller's view, it's very likely that the view will never be unloaded even if it isn't visible.
Instead of breaking the view controller hierarchy, do one of the following:
Just add subviews to your view normally, either in interface builder, or in -viewDidLoad: to add them programatically, or (rarer) override -loadView.
Use view controller containment, either with Apple's ready-made ones (UINavigationController,UISplitViewController etc.) or with your own container view controllers (iOS>5).
Display view controllers modally.
The bad idea of breaking a view controller hierarchy is indeed very common and often seen in 3rd parties, probably because it's so easy and seemingly straightforward. Unfortunately this causes the aforementioned bugs :-(
I really recommend to everyone participating in this thread and comments to read Apple's View Controller Programming Guide, and watch WWDC 2011 "View Controller Containment" video.
I have a root view controller that subclasses UINavigationController. It loads in a child view with a UIButton. When that button is pressed I want to make a call from the child view's corresponding view controller (lets say ChildViewController) to the UINavigationController's pushViewController: method in the parent controller.
How is this possible without directly referencing the parent view controller? Is it achievable using a standard protocol method or do I have to create my own?
Every UIViewController has a property called navigationController. If a UIViewController is a part of a UINavigationController's stack, you can use the navigationController property in the following manner:
[self.navigationController pushViewController:yourNextViewController animated:YES];
There's no need to access the rootViewController only for pushing a new ViewController on the stack. This could get really awful if you had big navigation stacks.
By the way - Apple states that UINavigationController is not intended for subclassing. Usually, it is a good idea to listen to their warnings and directions, so you may want to revisit the subclassing approach again.
using a subclassed UIViewController which is loaded to the UINavigationController's stack may prove a better approach.
Hope this helps.
The child UIViewController that contains your child UIView and UIButton should have the parentViewController property. You can use that to get a weak reference to your UINavigationController where you can message pushViewController:animated:
In my appDelagate I have a UIViewController called "FrontPage" which is basically a log in screen. Once the login has authenticated it removes itself from the superview and creates a tabbarcontroller, navigationcontroller (inside tabbar), and various UIViewControllers in the NC and on their own in the tab bar. I then push my TabBarVC.view to the windows subView.
It works but I was hoping after I set the windows subview to TabBarVC.view I could release the TabBarViewController to dealloc it and the appdelagate would own the TabBarVC, but when I do it's crashing.
As I'm typing this I'm realizing I never pass the actual TabBarVC, just the view but is there a way to do this?
Also if I completely FUBAR'd this up let me know.
You should set the window's rootViewController property to your UITabBarController instance similar to this:
// set the tab bar controller as our root view controller
[self.window setRootViewController:tabBarController];
To clarify, this will add the TabBarController, its view and all of its subviews to the window's view hierarchy for you and I would recommend you use this method for your login view controller as well.
You could make your UITabBarController an IBOutlet to the app delegate (or just keep the code you have that generates it). Make it a retained property of the app delegate, synthesize the property, and either create the UITabBarController in the app delegate (self.tabBarController = ...) or if you use an xib make the IBOutlet connection from the UITabBarController to the app delegate in the xib.
You could add the UITabBarController to the app's window, and then add the FrontPage UIViewController on top of it. Once you remove the FrontPage from the window, the UITabBarController will already be present underneath it.
I created "New Project" -> Tab Bar Application.
Then i changed from #interface FirstViewController : UIViewController to #interface FirstViewController : UINavigationController.
Then i changed file's owner from UIViewController to UINavigationController in xib file.
Then i updated view. But i don't see any label on the screen. Why? (i have some labels on xib)
Why are you subclassing UINavigationController and what are you trying to accomplish? UINavigationController does not display a view of it's own, just the navigation bar over some other view controller's view. In addition UINavigationController was not designed to be subclasses, hence the "This class is not intended for subclassing." warning in its class reference.
If you want to display your view controller as part of a navigation stack you should create an instance of UINavigationController, set that navigation controller as the view controller for one of your tabs, and then push an instance of your FirstViewController onto the UINavigationController.
Please tell me which ViewControllers can be placed inside UINavigationViewContoller?
I.e. can I make a UINavigationViewController the root view for UITableViewController or UITabViewController?
Thank You
From the Apple docs:
initWithRootViewController:
Initializes and returns a newly
created navigation controller.
(id)initWithRootViewController:(UIViewController
*)rootViewController Parameters
rootViewController
The view controller that resides at the bottom of the navigation stack.
This object cannot be an instance of
the UITabBarController class.
So anything but an UITabBarController is fine