I want to use generally the old .xib files in my iPhone application. But when it comes to tableViewController storyboard is a lot more convenient in order to make custom cells etc. Is it possible to make a .xib based application and in the middle of it, to use a storyboard for a UITableViewController and its DetailedViewController only?
You can use a storyboard for any part of a program. Storyboards are not an all or nothing concept. You can have just one view controller in a storyboard, or a small network that just represents a subsection of your app.
To use just one view controller from a storyboard:
Add a new storyboard to your existing project.
Add a single view controller to the storyboard.
Assign an identifier to the view controller in the inspector.
Use the UIStoryboard class to load the storyboard resource
Use -[UIStoryboard instantiateViewControllerWithIdentifier:] to create a new instance of that view controller.
Install the view controller some place in your app by doing something like pushing it on to a navigation controller, or run it modally.
Both can work fine together (Storyboards and Nib files). In the TVC that is part of your storyboard, just instantiate the destination VC in code and use the usual initWithNibName method to load the nib file.
You can add a storyboard to any project, but the point of storyboards is to centralize your XIB files into one location rather than having 10 XIB files you can have 1 .storyboard file that contains 10 scenes representing your views. This shows your connections to other scenes, and you can manage all the seques and transitions of each scene. So is it possible, yes you could add a storyboard to your project, but I would recommend you design you entire application in a storyboard if you want to use them.
Related
I want to know when to use xib and when to use UIContainerView?
I didn't find any article related to this topic in the web. What are the differences and what are the usage of each of them?
Let's first talk definitions:
A XIB file is a graphical representation of a screen/view.
A UIContainerView is exactly what it says, it's a view that will contain child view controllers.
So based on that it is clear that they will not be used in the same way.
A XIB file is a base file you create in Xcode, link to a UIViewController and in which you can drag and drop elements to design your screens.
UIViewContainer is one of those draggable elements and is simply meant to be a reserved space in your xib (or storyboard if you use that instead) in which you can easily "embed" another UIViewController.
Do you sometimes add a child UIViewController to your main UIViewController? You'd do something like this in code:
Instantiate second controller
Add second controller's view as subview in main controller
Add second controller as child of main controller
Create constraints so that view shows exactly where intended
Well the UIContainerView is here to do exactly this, only now you don't have to do it in code, you can drag a UIContainerView in you XIB/Storyboard and link the second controller there directly!
You can use .xib design file for a standalone View (like custom datePickerView, CustomAlertView, customViews etc). Use can use this class where every you want.
But ContainerView, you can design with a UIViewController on storyboard and its automatically generate its own view for you.
This is embedded with a single ViewController.
I have a "container" viewController, that hold a few container views using storyboard.
each of that container view has a link to an embedded viewcontroller's view.
Since im working on a big project, it turns out that the storyboard file is massive and contains a lot of "child" viecontrollers view layout. it will be a problem working on that file when a few people needs to be working simultaneously on it. and thats not good for me.
i would like to know if theres a way to load into each container view a viewcontroller's xib file, and still be using storyboard.
Meaning, creating .xib files for each viewcontroller instead of holding them in the storyboard itself, and link them to the container views in the storyboard.
thanks,
You can move your view controller layout into a separate xib. As you say, this is a very convenient way to share layouts across storyboards.
When setting up a container view in your storyboard, make sure you delete the provided view in the embedded ViewController. Set the custom class for the ViewController to your class name. Name the xib to match the class (e.g. FooViewController.xib so it can be found when FooViewController.m is loaded.)
If you don't delete the View in the storyboard view controller layout, you'll see that empty view instead. Your viewDidLoad method in your view controller won't be called, because the View is the default Storyboard View.
I'm using Xcode 6.1 for iOS 8 on a pre-iOS 7 project.
Yes, you can. A few observations:
All you need to do is to put in the sort of code that we used to use when using NIBs. In the case of containers, that means the typical container methods. If you've not done containment via code, see Creating Custom Container View Controllers in the View Controller Programming Guide. Bottom line, as you transition to a non-storyboard scene (or add a non-storyboard child view controller), just code it like you always used to in the NIB-based environment. You cannot represent this NIB-based scene in the storyboard. But you just get the controller like you always do with NIBs:
SecondViewController *controller = [[SecondViewController alloc] initWithNibName:nil bundle:nil];
You obviously lose many of the benefits of using storyboards (e.g. sizing the child scene on the basis of the container view in the parent scene), but you're no worse off than you were in a NIB environment. But in answer to your question as to whether you can "link them to the container views in the storyboard", you cannot represent this relationship in the storyboard itself, but rather you link them up programmatically.
If your separate teams are working in single-scene environments, you can use this NIB approach. You should also contemplate, though, just having multiple storyboards, one for each logical team. You'll still have to resort to code as you transition between storyboards, just like you do in this NIB approach, but if one of your teams has multiple scenes to deal with, they can enjoy storyboard benefits within their portion of the project. When you want to get to the first scene in the next storyboard, you can:
UIStoryboard *secondaryStoryboard = [UIStoryboard storyboardWithName:#"SecondStoryboard" bundle:nil];
SecondViewController *controller = [secondaryStoryboard instantiateInitialViewController];
If your child needs to transition to a new scene on your storyboard, I find it useful to add my own parentStoryboard property to my child controller, which it can then useful if you need to do something like instantiateViewControllerWithIdentifier. Obviously, if you're not transitioning to new controllers, you may not need to do that, but if you are, having a UIStoryboard property can be useful.
I have some UIViewControllers from my old iOS4 project, they are using .xib, created in interface builder.
My new project, built for iOS5, uses storyboards.
I'm trying to add a UIViewController to the storyboard, but have it use a custom XIB that I already have. I've set the controller's identity in the indentity inspector (in interface builder), but am not sure how to ask that controller to load a custom .xib.
Any help is appreciated!
PS. Up to date I was able to get around this by creating a "wrapper" class for the storyboard purposes, and have that class have another UIViewController. But this kinda defeats the whole point of a storyboard.
You could copy the contents of the xib into the storyboard and then instantiate it using:
- (id)instantiateViewControllerWithIdentifier:(NSString *)identifier
after setting the identifier on it. If you need the instance of the storyboard you can get it this way:
[UIStoryboard storyboardWithName:#"MainStoryboard" bundle:nil];
Mike K's answer is false.
While mixing XIBs and Storyboards doesn't really solve Alex's problem, it is quite possible to do within the same project.
See: https://stackoverflow.com/a/8516479/1309238 re: loading a second storyboard.
I'm not sure if including a "Main Storyboard" in your Target Summary is advisable if you plan to do this, but if you've loaded a XIB instead of a storyboard to begin with, you can modify the code linked above to load the storyboard after the XIB.
I'm not sure if you can jump into the middle of a storyboard from a XIB, which may have been what Mike meant.
You cannot mix xibs and storyboards in your project -- it's one of the other, I'm afraid.
In a navigation based application, when I want to create and use other uiviews and uitableviews I need to create their controller and views. in an example I saw that I can simply create a new controller with .xib file, design it, and just call that xib file from my navigationcontroller.
In another example, some stuff was going on also in the mainwindow.xib and some new controllers and navigation items were added from the mainwindow.xib.
What is the difference between these methods? when and why I should need to open and edit the mainwindow.xib file to add a controller?
The mainwindow.xib is your UIWindow component which you can see as a representation of your iphone screen, it will always be there no matter what. In your examples when you are showing your view controller dirrctly that is because the controller is already a subview of your UIWindow which is the mainwindow.xib in the Interface Builder.
There really is no difference between the 2 methods, in the first one you are adding your controller as a subview progrmatically using:
[window addsubview:mynavcontroller]
And in the second one youbare doing it thru interface builder, you may use whichever method you feel more comfortable with.
You do not really need a controller to show a view, however they can be handy if you want to do any extra stuff such as rotating your view or loading certain data when the view is loading. That being said you could add your view as a subview of your window and it would still work.
I have a mainwindow.xib file with a UITabBarController as the base view controller of the app. So inside the UITabBarController I've added about 10 sub UIViewController objects as tabs. Most of them are just a UITableViewController subclass or a UINavigationController containing a UITableViewController subclass.
In this design, each UIViewController is fully loaded on app startup, including calling the viewDidLoad method of each view controller. Is there any way to get around that? Since the view controllers are just UITableViewControllers with no other outlets, it seems excessive to create a NIB for each tab (which I assume would allow the viewDidLoad to only get called when the user first switches to the tab? Or am I wrong on that?)
Anyway, my question mainly, is: how is it conventionally done? If you have 10 different view controllers on one UITabBarController, do you put them all in mainwindow.xib? If so, should each have its own NIB, and if not, where do you put them, and how do you add them to the tab bar?
What you want to do is to define the UIViewController views in a different xib file for each view - the reason they all get instantiated is that when the xib loads, all objects held in the xib load - and that means all your views and view controllers since you have defined them there.
In MainWindow.xib where you have the tab bar defined, you can still set within each tab the view controller type that will be called and also the XIB file to use for that type (create a new project with the "TabBar application" template and the second default view will be like this).
Then as you press tabs the view controllers will be instantiated from the different XIB files you have defined.
Note that this means if you are using IB to add buttons to the navigation bar, you have to do that back in the TabBar xib and not in the xib you use to define the view. You can still link actions to the view controller definition within the tab.
The way Apple suggests doing it for pure NIB files is how you say: Each sub-view in its own NIB file.
Instead of doing this, I would create the UITabBarController programmatically. That way you can define all your simple views in code, and still load complex views from NIB files.
Personally, I prefer creating as many of my views programatically as possible. The compiled code has a smaller footprint than the NIB files and I feel like I have more control. I mostly use Interface Builder to mock up applications.