I am attempting to connect two UINavigationControllers, representing different tabs in a tab bar application, towards a single UICollectionViewController. The collection view controller will be populated by different data based on which navigation controller is the parent. When both navigation controllers are connected, navigating to the second tab displays a black screen and the viewWillAppear() code in the controller for the collection view does not fire. When navigating to the first tab, everything fires and is displayed correctly with data populated.
The storyboard setup looks like this:
The navigation controllers are connected to the collection view controller as seen here:
If I disconnect either one of the two navigation controller connections, the remaining connection to the collection view works and collection items are displayed as expected.
Is this the correct way to reuse the collection view? Is there something missing from how I am connecting the two navigation controllers with segues to the single UICollectionView?
I see this is almost a year old, so I'm not sure if you found an answer or not, but I thought I'd help answer if needed. Without knowing too much of your project, can I ask why you want a tabBarController to point both of its view controllers to the same one? Makes me wonder why tabBarController is necessary.
Setting up a test project, I witnessed the same you did. The only thing I can think of is that when a view controller is instantiated via the Storyboard, it creates an instance of it and is stored in the tabBarController's viewControllers[i] property, which the other tab may not have access to in the hierarchy. It would be best to just copy the view controller object from the Storyboard and paste it onto another area of the storyboard, and have the tabBarController instantiate a new instance of the same view controller object. That way, in your viewDidLoad method, you can tell what the selectedIndex is, and know how to load data, alter interface, etc. Copying/pasting the Storyboard view controller should keep intact any outlets/actions you've set up.
Hope that helps...
Related
I have this problem and I can't seem to find the answer so I asked here. I need to overlap 2 UIViewControllers. It is in a navigation controller. Each Controllers is using xib files as view since I am not using storyboard. It needs to be overlapped since the first controller is on live feed and I cannot afford to use a screenshot for background to make the live feed stay on while the user is navigating on the second controller. Any Ideas?
try content views doc tutorial
and the VC which you want to overlap, you will not keep it in you navigation stack, you will have to make overlapping VC, child of the VC on which you want to present it, after making child you will add child VC's view as a subview to parent's view. in that way both view controllers will appear to be overlapping
Difference between navigation controller and viewcontroller?
I mean how can we decide when to use navigation controller or a normal view controller?
Just my two cents:
A UIViewController represents a single view and you can put buttons in this view controller to segue to another UIViewController. If you want to segue back to the first UIViewController, you will have to worry about putting a button in the second view controller that leads back to the first. If you are drilling down into view controllers, this can be tedious having to remember to give the user a way back to a previous view controller.
A UINavigationController does a lot of this tedious work for you. As mentioned, it contains a stack of UIViewControllers. It will create a navigation bar at the top that will allow you to easily go back up the hierarchy of view controllers.
In short, if you have a hierarchy of view controllers that you want the user to easily navigate around, inbed your UIViewControllers into a UINavigation controller.
UINavigation Controller is a combination of 2 or more view controllers,those are connected through "segue" feature of "Ios". Benefit of using Navigation Controller is that we can navigate between different screens easily with default "Back" button on each screen . We don't need to give any individual button to move back onto previous screen.
Whereas a ViewController provides a single screen & we can connect more screen using "segue" but we also have to design a "Back" button to navigate onto previous screen.
We should use Navigation Controller , in case where one option resides into another one.Like in an iPhone settings ->Mobile Data Options->Voice->4G or 3G or 2G. It's a hierarchy of menus so here navigation Controller is better option than using UIController.
We should use UiController with "segue " , in case where
we have to choose one option among multiple.Like -
Photos ->There are many folders in which , any one is selected, that are Favourites or People or Places .
Here's a very brief, high-level overview.
Whereas a UIViewController can be thought of as representing a single 'screen', UINavigationController, as the name implies, is used as a means of being able to navigate multiple 'screens'.
From the documentation:
The UINavigationController class implements a specialized view controller that manages the navigation of hierarchical content. This navigation interface makes it possible to present your data efficiently and makes it easier for the user to navigate that content. You generally use this class as-is but in iOS 6 and later you may subclass to customize the class behavior.
Please see the rest of the UINavigationController documentation here: https://developer.apple.com/library/ios/documentation/UIKit/Reference/UINavigationController_Class/index.html
Okay, Thank you everyone for helping me to find out a clear answer on this.
Navigation Controller consists of navigation bar and tool bar to move in and out from view controllers present in navigation stack.Therefore there can be many view controllers in Navigation Controller.
In view controller we don't have this facility and it represents a single screen view.
Please correct me If I am wrong.
See the Navigation Controller discussion in the View Controller Catalog.
Bottom line, a navigation controller actually is a view controller, but it just happens to be one that presents and navigates between other view controllers.
Whenever my app launches one of 3 possible screens will be displayed depending upon the state.
I was going to model this in a storyboard by having the starting view controller as a navigation view controller, then have a segue from it to each of the three other VCs.
Then on app launch the appropriate VC would get pushed depending upon the app's stored state.
However IB will not permit me to make multiple connections from the navigation controller.
If I make an initial segue from the NVC to any of the VCs, say A. Then when I attempt to add another segue from the NVC to another of the VC, B, then instead IB creates a connection between A and B.
First of all is the approach of having a Navigation Controller as a starting RVC and pushing different VCs onto depending on state an incorrect approach? If not, then how to model it with storyboards? Why will IB not let me drag and drop the segue to the other controller?
I don't think the navigation controller is the way to go. IB won't let you connect more than one, because that first connection is the root view controller, and there is only one of those.
There a many different ways you could get what you want depending on where you go after one of those 3 initial views. Do they all go to the same view next? All different view? Some the same, some different? It's hard to advise you without more detail.
You could start off with a tab bar controller, with the tab bar hidden, if you don't want that look. Or, you could have logic in the viewDidAppear method of a common initial controller, and have it switch the root view controller of the window to on of your three screens.
I am creating a iPad App and it has several views to load data,but for one view i need to add split view. I dont need split views in other views. They are just detail pages. I search Through the net and found lots of tutorials based on iPad split view. But the problem is they all are creating a project as Split view project or they create a window base app and add slipt view to the delegate. I dont need to do that, I need to implement this split view only for one view. Is There any way to overcome this problem?
You can add the split view inside a Navigation Controller.
Even if the Split View is a container view controller and Apple recommends in the documentation that all containers should not be embedded in other containers, adding a split view inside a navigation controller works correctly and I never noticed any side effect in doing it.
Basically what you should do is:
- in the app delegate create a UINavigationController and use it as root view of your application window
- hide the navigation controller navigation bar if you don't want to see it (showing a split view with a main navbar on top is not nice looking...)
- then add your view controllers inside the navigation bar.
Example: imagine you have this application views sequence:
FIRST VIEW (full view = detail page)
SECOND VIEW (split view)
THIRD VIEW (full = detail page)
So you can represent FIRST and THIRD as standard view controllers (full screen), while SECOND will be a split view. Your app will be initialized by creating the main navigation controller, adding FIRST on it as top controller and using the main navigation controller as window's root view.
Than use the navigation controller push, pop methods to switch between these views or change the navigation controller "viewControllers" array directly if you don't want the recommended push/pop methods.
If you need to add special behavior to the navigation controller based on the type of view on top, just register your app delegate as navigation controller delegate (or a "main controller" object dedicated to this if you don't want to complicate your app delegate).
I am not 100% sure, but it seems to me that you can't use a SplitView just somewhere in your view hierarchy.
The Apple intended way is to use the SplitViewController as the top level controller. The left side of it can include a drill down mechanism with a navigation controller so you are ably to drill down hierarchies and the right side will present details for the item you select on the left side.
If you need a view with some kind of split mechanism in it, you probably have to code it yourself. Or even better: find some other mechanism you can use in your UI.
How are you switching your view hierarchies now? Maybe you could integrate your existing UI into a SplitViewController?
I understand that view controllers help control multiple views in an application, but I have trouble understanding when to use them.
If I have an application with a main page, several views with a "hierarchy" structure, and an about page not connected with the hierarchy, what files should my application have? An appdelegate, navigation controller and view controller? More than one view controller? Just a navigation controller?
Also, should they all be contained in one .xib file, or multiple .xib files?
Any help would be greatly appreciated.
Thanks.
A good habit is to have a UIViewController for each page you want to show. If I get the structure of your app you should have a main page (with many other UIViews inside it) and another page (about page). If that's true I suggest two UIViewControllers.
The UINavigationController is a subclass of UIViewController that lets you "navigate" among the pages. It's not strictly necessary but suggested (you can also implement your self a custom navigation system, but it's easier to exploit the one Apple offers you). Another navigation system is the one based on UITabBarController, if you want to take a look.
Assuming I get the structure of your app you should need two .xib file, one for each page you have.
The app delegate is conceptually different from a view controller, you'll have just a single app delegate, automatically created by Xcode (you can, of course, modify it to fit your needs).
Each "screenful of content" (Apple uses this term) should be handled by it's UIViewController or more likely a subclass of it. The point of view controller is to handle view appearing or disappearing (going on/offscreen), device rotation, memory management, navigating to other view controllers and so on. If you are creating your UI with IB, then each of those view controllers would most likely have it's own .xib file.
Each view controller has one view (it's view property) that acts as main view for each "screenful of content" to which you then add your subviews.
UINavigationController and UITabBarcontroller are there to help you control the hierarchy of your app. They only act as containers for other view controllers and don't contain any UI except navigation bar or tab bar. Using tab bar controller you can have multiple view controllers which act exactly like browser tabs. Using navigation controller you can have a stack-like navigation where new view controllers are pushed from right to left and are popped from left to right when user goes back to previous view controller. You can even have a view controller inside navigation controller inside a tab bar controller.
If you don't want to use tab bar or navigation controller, you can navigate through your view controllers by presenting them modally using presentModalViewController:animated: and dismissing by dismissModalViewControllerAnimated:. If you send YES for animated parameter of these methods, you will get an animation specified by the modalTransitionStyle property of view controller being presented or dismissed. Possible animations are slide in from bottom (default), horizontal flip of entire screen, fade in/out and half-page curl.
There are also some Apple-provided subclasses of UIViewController that help you setup your UI quicker like UITableViewController which is basically a view controller that contains a table as it's main view and conforms to 'UITableViewdataSourceanddelegate` protocols which are required to define how each cell looks and what it contains.
On iPad there is one additional container controller UISplitViewController and one additional way to present new view controllers using UIPopover.